[MMUSIC] AW: Comment on draft-ietf-mmusic-securityprecondition-00.txt
Stach Thomas <thomas.stach@siemens.com> Fri, 01 July 2005 08:33 UTC
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06837 for <mmusic-archive@ietf.org>; Fri, 1 Jul 2005 04:33:13 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoHNT-0000z9-DD for mmusic-archive@ietf.org; Fri, 01 Jul 2005 05:00:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoGwV-0007Qx-9y; Fri, 01 Jul 2005 04:32:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoGwT-0007Qs-Jl for mmusic@megatron.ietf.org; Fri, 01 Jul 2005 04:32:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06802 for <mmusic@ietf.org>; Fri, 1 Jul 2005 04:32:05 -0400 (EDT)
Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoHM7-0000x9-Jm for mmusic@ietf.org; Fri, 01 Jul 2005 04:58:55 -0400
Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id j618VSMr016217 for <mmusic@ietf.org>; Fri, 1 Jul 2005 10:31:28 +0200
Received: from vies141a.sie.siemens.at ([158.226.129.97]) by vies1kbx.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j618VRgG010167 for <mmusic@ietf.org>; Fri, 1 Jul 2005 10:31:28 +0200
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2655.55) id <M55ZCLV2>; Fri, 1 Jul 2005 10:33:22 +0200
Message-ID: <B517DF063D33D611A2F20800060DA3268EB340@vieg127a.gud.siemens.at>
From: Stach Thomas <thomas.stach@siemens.com>
To: 'Flemming Andreasen' <fandreas@cisco.com>
Date: Fri, 01 Jul 2005 10:28:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: quoted-printable
Cc: "'mmusic@ietf.org'" <mmusic@ietf.org>, "'dwing@cisco.com'" <dwing@cisco.com>
Subject: [MMUSIC] AW: Comment on draft-ietf-mmusic-securityprecondition-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Content-Transfer-Encoding: quoted-printable
Fleming, thank you for clarifying. I overlooked the text in RFC3262 that allows another offer in the PRACK in case that the provisional response contained an SDP answer. So, in fact the UPDATE is not necessary in this case. Maybe you want to consider giving this little hint to the readers. This might avoid that others ask the same question again and again. Kind Regards Thomas > -----Ursprüngliche Nachricht----- > Von: Flemming Andreasen [mailto:fandreas@cisco.com] > Gesendet: Donnerstag, 30. Juni 2005 18:55 > An: Stach Thomas > Cc: 'dwing@cisco.com'; 'mmusic@ietf.org' > Betreff: Re: Comment on draft-ietf-mmusic-securityprecondition-00.txt > > > > Stach Thomas wrote: > > > Fleming, Dan, > > > > I think the draft in general is quite clear. > > Is a WGLC planned for the near future? > > > I'll defer to the WG chairs, but as far as I know, all comments and > outstanding issues have been addressed and I believe it is > ready for WGLC. > > > > Nevertheless, I propose to change the example call flows in > Figure 1 > > and 2 to show usage of the UPDATE method for the second SDP > > offer/answer exchange. > > > An earlier version of the document did that and it was > pointed out that > you save the UPDATE because you already have the necesssary > information > available at the time you want to send the PRACK, so it was > removed. We > could change one of the examples to include UPDATE if the WG wants to. > > > It could look like this > > > > A B > > > > | | > > |-------------(1) INVITE SDP1--------------->| > > | | > > |<------(2) 183 Session Progress SDP2--------| > > | | > > |----------------(3) PRACK ----------------->| > > | | > > |<-----------(4) 200 OK (PRACK) -------------| > > | | > > |---------------(5) UPDATE SDP3------------->| > > | | > > |<----------(6) 200 OK (UDATE) SDP4 ---------| > > | | > > |<-------------(7) 180 Ringing---------------| > > | | > > | | > > | | > > > > And of course a normative reference to RFC 3262 for PRACK > and RFC3311 > > for the UPDATE method should be added. > > > They are effectively there already because RFC 3312 makes it > mandatory > for you to support them, so I don't think we need to add them > to the list. > > -- Flemming > > > Kind Regards > > > > Thomas > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] AW: Comment on draft-ietf-mmusic-securit… Stach Thomas