[MMUSIC] RE: alternate RTP profiles in SDP offer/answer
"Dan Wing" <dwing@cisco.com> Mon, 30 October 2006 22:58 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geg5N-0003cm-Fr; Mon, 30 Oct 2006 17:58:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geg5M-0003ch-JQ for mmusic@ietf.org; Mon, 30 Oct 2006 17:58:28 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geg57-0008Qf-OC for mmusic@ietf.org; Mon, 30 Oct 2006 17:58:28 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2006 14:58:12 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UMw9HW022180; Mon, 30 Oct 2006 14:58:09 -0800
Received: from dwingwxp ([10.32.130.99]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9UMw8W4016431; Mon, 30 Oct 2006 14:58:08 -0800 (PST)
From: Dan Wing <dwing@cisco.com>
To: 'Joerg Ott' <jo@netlab.tkk.fi>
Date: Mon, 30 Oct 2006 14:58:08 -0800
Keywords: direct-to-dwing
Message-ID: <564501c6fc76$de9c8d20$5b82200a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <45431294.8060507@netlab.hut.fi>
Thread-Index: Acb6ac+20tzo+Eq7SjOMGB6Vbm4jqgAPyFuw
DKIM-Signature: a=rsa-sha1; q=dns; l=5051; t=1162249092; x=1163113092; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:RE=3A=20alternate=20RTP=20profiles=20in=20SDP=20offer/answer; X=v=3Dcisco.com=3B=20h=3DZD7nVjcVFat1K54Z7ztdU6OfYko=3D; b=fE4OSsEPdF9GvVMjeZMDAPo36An3wX2GM/ypUtuDUOMGHNOCTtkSnO1DzOa7XLxafSrgeTd+ J2ZyFMV8B+idpgNUp3RqjfDFBMRFXq4lrWg0vlec/wNIKZsqUA3MZCJ7;
Authentication-Results: sj-dkim-3.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: ietf-rtpsec@imc.org, mmusic@ietf.org, carrara@kth.se, 'Francois Audet' <audet@nortel.com>, 'Flemming Andreasen' <fandreas@cisco.com>, 'Joerg Ott' <jo@acm.org>
Subject: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer
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>
Errors-To: mmusic-bounces@ietf.org
> what you claim to be a problem here has been removed from the SAVPF > spec for this very reason. -08 had -- by accident -- some remnants > in that were taken out in -09. Should there be an oversight left in, > then please be precise of what you mean and we will be happy to > fix this. Thanks. I'm sorry for not noticing, until now, this AVT document was normatively specifying SDP behavior for SAVPF. Here are my comments about the MUSTs in the document that may interfere with the I-Ds on best-effort SRTP: ----- 1. Section 3.3.1 says: If supported, the answerer SHOULD prefer a secure profile over non-secure ones. and later says: If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected. Based on -savpf-09's defintion of "media session", this means the entire RFC3388 group has to be rejected. This means an RFC3388-grouped offer with SAVPF and SAVP, sent to an answerer that understands RFC3388 and SAVP (but the answerer doesn't implement SAVPF), would have to be rejected by the answerer. I don't believe this is your intent. I suggest deleting: If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected. otherwise, we'll not be able to use SDP grouping. ----- 2. Section 3.3.2: To offer two or more alternative RTP profiles for a particular media stream, the SDP description MUST contain exactly one m= line for this media stream for each profile and all the same transport address (IP address and port number). This requirement makes sense if you're using grouping (RFC3388), so prefixing this with "If using RFC3388, ..." seems suitable. However, note that section 7.5.3 RFC3388 explitictly prohibits using the same transport address. ----- 3. Section 3.3.4, titled "Describing Alternative Session Profiles", which I assume is talking about SDP (which describes sessions): SAVP and SAVPF entities MAY be mixed in the same RTP session (see also section 4) and so MAY AVP and AVPF entities. Other combinations -- i.e. between secure and insecure profiles -- in the same RTP session are incompatible and MUST NOT be used together. The MUST NOT in that last sentence prohibits using RFC3388 grouping to mix AVPF and SAVPF. That MUST NOT should be removed from -savpf, as it is a stronger requirement than SAVP's own registration (RFC3711), which is counter to a sentence in draft-ietf-avt-profile-savpf's security considerations section which says that draft-ietf-avt-profile-savpf doesn't increase or decrease security compared to SAVP itself. 4. Also, in that paragraph, I believe the first sentence should read: SAVP and SAVPF entities MAY be mixed in the same media session ^^^^^ (see also section 4) and so MAY AVP and AVPF entities. ----- 5. Example 4: A client inquires a media description from a server using DESCRIBE and obtains a static SDP description without any keying parameters but the media description shows that both secure and non-secure media sessions using (S)AVPF are available. However, the SDP is: v=0 o=alice 3203093520 3203093520 IN IP4 movies.example.com s=Media with feedback t=0 0 c=IN IP4 0.0.0.0 m=video 49170 RTP/SAVPF 96 a=rtpmap:96 H263-2000/90000 a=rtcp-fb:96 nack m=video 49172 RTP/AVPF 96 a=rtpmap:96 H263-2000/90000 a=rtcp-fb:96 nack which isn't for one video stream but rather is for two separate video streams -- one encrypted, the other unencrypted. I see that the port numbers were modified between -07 and -09 (likely a result of my complaints about -07), but the text introducing the example wasn't changed. Is it useful to just show SAVPF in the SDP, and not show alternative grouping? ----- Editorial nits: Section 3.3.1, OLD: setting the port number in the respect m= line to 0. NEW: setting the port number in the respective m= line to 0. ^^^ Section 5: OLD: The SAVP profile does not add, nor take away, any security services compared to SAVP. NEW: The SAVPF profile does not add, nor take away, ^^^^^ any security services compared to SAVP. > From the mere authorship of the spec, it should become clear that > there is a close interaction with what MMUSIC does. > > I must admit that I am somehwat surprised and not particularly > amused about your seocnd-guessing below. Please accept my apologies for not reviewing this document until now. I hope my suggested changes improve the document and assist with its forward progress. I do hope there is time on the MMUSIC agenda to discuss grouping and its merits for negotiating RTP profiles along with the other two approaches that are on the MMUSIC agenda. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] alternate RTP profiles in SDP offer/answ… Dan Wing
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Francois Audet
- [MMUSIC] Re: alternate RTP profiles in SDP offer/… Joerg Ott
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Francois Audet
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Dan Wing
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Dan Wing
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Desineni, Harikishan
- [MMUSIC] Re: alternate RTP profiles in SDP offer/… Randell Jesup
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Dan Wing
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Dan Wing
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Desineni, Harikishan
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Dan Wing
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Francois Audet
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Desineni, Harikishan
- Re: [MMUSIC] RE: alternate RTP profiles in SDP of… Joerg Ott
- [MMUSIC] Re: alternate RTP profiles in SDP offer/… Joerg Ott
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Francois Audet
- Re: [MMUSIC] RE: alternate RTP profiles in SDP of… Joerg Ott
- [MMUSIC] Re: alternate RTP profiles in SDP offer/… Joerg Ott
- [MMUSIC] Re: alternate RTP profiles in SDP offer/… Joerg Ott
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Dan Wing
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Francois Audet
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Desineni, Harikishan
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Dan Wing
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Desineni, Harikishan
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Dan Wing
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Francois Audet
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Desineni, Harikishan
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Dan Wing
- RE: [MMUSIC] RE: alternate RTP profiles in SDP of… Desineni, Harikishan
- [MMUSIC] Re: alternate RTP profiles in SDP offer/… Joerg Ott
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Dan Wing
- Re: [MMUSIC] RE: alternate RTP profiles in SDP of… Joerg Ott
- [MMUSIC] RE: alternate RTP profiles in SDP offer/… Desineni, Harikishan
- [MMUSIC] Re: alternate RTP profiles in SDP offer/… Flemming Andreasen