From mmusic-bounces@ietf.org Mon Jan 01 23:02:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1aqD-0007Ye-MY; Mon, 01 Jan 2007 23:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1aqB-0007Wq-Qg for mmusic@ietf.org; Mon, 01 Jan 2007 23:01:31 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1aq9-0003Mz-EC for mmusic@ietf.org; Mon, 01 Jan 2007 23:01:31 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Jan 2007 20:01:29 -0800 X-IronPort-AV: i="4.12,224,1165219200"; d="scan'208"; a="97053239:sNHT45078165" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0241SnA028182 for ; Mon, 1 Jan 2007 20:01:28 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0241OPp006494 for ; Mon, 1 Jan 2007 20:01:28 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 20:01:28 -0800 Received: from [10.21.121.207] ([10.21.121.207]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jan 2007 20:01:28 -0800 Message-ID: <4599D915.2010903@cisco.com> Date: Mon, 01 Jan 2007 23:01:25 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jan 2007 04:01:28.0504 (UTC) FILETIME=[ADEC0380:01C72E22] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3664; t=1167710488; x=1168574488; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotation=3A=20Minutes=20of=2012/19/06=20 conference=20call |Sender:=20; bh=ZTknXUil/s3wrYhZavF5EhC8TQeFA6NXoNngCBu2qS4=; b=1w+RlVtM5n73rdfJk5K/wHYkWmqcVTntT8pwc0NaRmEHTnSgwvTaq90BtbWX0dildQpoG4CA tQIUvJF9yGRSOxSD/PfVTRlBD7OIdUaROOAzs22N2f4pbTVb/iIAz5Te; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [MMUSIC] SDP Capability Negotation: Minutes of 12/19/06 conference call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Greetings The SDP Capability Negotiation Design team held its first conference call on 12/12/06. The attendees were: Cullen Jennings Flemming Andreasen Thomas Stach Roni Even Bob Gilman Colin Perkins The items discussed were 1) Feedback on the open issues posted to the list (REQ-50, 150, and 160) ---------------------------------------------------------------------------- The design team had already discussed these on the last call and were in general agreement with those requirements as stated in the current requirements document. So far, there has not been any feedback on any of these on the mailing list. Roni Even furthermore noted that alternatives between media streams are not used in current products (which argues for keeping REQ-160 optional). 2) Review updated requirements (85, 121, 122, 301 and 302) --------------------------------------------------------------- There was consensus within the design team on the updated requirements (85, 121, 122, 301 and 302), however REQ-85 generated a bit of discussion around whether we should make a distinction between SIP B2BUAs and SIP proxies as middle-boxes and impose different requirements on them. It was suggested that B2BUAs should not pass anything in the SDP that they do not understand, as that might interfere with correct operation. Conversely, such a requirement does not allow for transparency and even proxies may need to understand the extensions in certain middle-box scenarios. The design team agreed it was best to stay silent on this from a requirements point of view, but that we should add a couple of informative statements around middle-boxes (proxies versus B2BUAs) and how the new capability negotiation extensions may affect them if they pass them through without understanding them (and e.g. they process media). 3) Should we have some security requirements, and if so, what are they ? ------------------------------------------------------------------------- SDP capability negotiation introduces a new set of security issues, and the question was whether the requirements document should try and address those by identifying specific security requirements. Cullen did not see a need for specific security requirements in the document and the team agreed with that. We will however be making certain security assumptions, and those need to be documented. More specifically: - Whatever is carrying the SDP is assumed to provide integrity (but not confidentiality), and from there we need to protect against downgrade attacks. - We do not provide the security solution for "whatever is carrying the SDP" - We will have to describe our trust model (e.g. end-to-end and using "identity", or trusted with hop-by-hop signaling) We will only provide the security assumptions in the requirements document. All the "real" security considerations (and assumptions) of course need to go in the solutions document. One security consideration that will eventually need to be described is the playing out of early media prior to receiving an answer (or other indication of the answerers chosen configuration). 4) Next call and plan forward ------------------------------ An updated requirements document in accordance with the above will be published soon. Once that is done, the plan is to issue a WGLC to ensure working group consensus on the requirements An updated solution document will be published by 1/2/07. We will not have a call on 1/2/07. The next call will be on 1/9/07, where the updated solution document will be discussed. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 02 06:07:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hTL-0000eY-MR; Tue, 02 Jan 2007 06:06:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hTJ-0000cp-V8 for mmusic@ietf.org; Tue, 02 Jan 2007 06:06:21 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hTH-0000tV-Gu for mmusic@ietf.org; Tue, 02 Jan 2007 06:06:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 1D5211E01E2 for ; Tue, 2 Jan 2007 06:06:16 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20379-08 for ; Tue, 2 Jan 2007 06:06:11 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 2 Jan 2007 06:06:11 -0500 (EST) Received: from EXCHINDIA2.starentnetworks.com ([10.4.2.4]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 06:06:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] question regarding presentation with aggregate control Date: Tue, 2 Jan 2007 16:36:07 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] question regarding presentation with aggregate control Thread-Index: AcclrHyJPOLEogKHQl6E5LuldXwgyQIrTOug From: "Patankar, Sujay" To: "mmusic (E-mail)" X-OriginalArrivalTime: 02 Jan 2007 11:06:11.0027 (UTC) FILETIME=[02B07230:01C72E5E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, In the following excerpt from RFC 2326: " Presentation: A set of one or more streams presented to the client as a complete media feed, using a presentation description as defined below. In most cases in the RTSP context, this implies aggregate control of those streams, but does not have to." Does it mean that there can be a presentation with more than one streams, and still non-aggregate control? The draft 2326bis-14 uses the wording: " Presentations with more than one media stream are *often* handled in RTSP under aggregate control." (emphasis on 'often' is mine) is it 'often' or is it 'always'? If it is indeed 'often', then can anyone please give me an example of a presentation with more than one media, but no aggregate control? Thanks, Sujay. -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, 22 Dec, 2006 15:02 To: Kylin Wei Cc: Patankar, Sujay; 'mmusic (E-mail)' Subject: Re: [MMUSIC] question regarding aggregate control Hi, Sujay, I would recommend that you read the spec once more. I would also=20 suggest that you have a look on how the RTSP 2.0 draft proposes to=20 clarify things: http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rfc2326bis/ However the answer to your question is actually in the parts you removed in the email. In 14.2 of RFC 2326 the two media streams are set up in=20 aggregate control. Thus a single teardown on the aggregate control URI=20 will remove all state for both media streams. Cheers Magnus Kylin Wei skrev: > 11.6 TEARDOWN >=20 > The TEARDOWN client to server request stops the stream delivery for > the given URI, freeing the resources associated with it. A TEARDOWN > request MAY be performed on either an aggregated or a media control > URI. However some restrictions apply depending on the current state. > The TEARDOWN request SHALL contain a Session header indicating what > session the request applies to. >=20 > A TEARDOWN using the aggregated control URI or the media URI in a > session under non-aggregated control (single media session) MAY be > done in any state (Ready, and Play). A successful request SHALL > result in that media delivery is immediately halted and the session > state is destroyed. This SHALL be indicated through the lack of a > Session header in the response. >=20 > A TEARDOWN using a media URI in an aggregated session MAY only be > done in Ready state. Such a request only removes the indicated media > stream and associated resources from the session. This may result in > that a session returns to non-aggregated control, due to that it only > contains a single media after the requests completion. A session > that will exist after the processing of the TEARDOWN request SHALL in > the response to that TEARDOWN request contain a Session header. Thus > the presence of the Session header indicates to the receiver of the > response if the session is still existing or has been removed. >=20 > Kylin Wei=20 >> -----Original Message----- >> From: Patankar, Sujay [mailto:spatankar@starentnetworks.com] >> Sent: Friday, December 22, 2006 12:05 PM >> To: mmusic (E-mail) >> Subject: [MMUSIC] question regarding aggregate control >> >> Hi, >> In section 14.2 of RFC 2326, we see that a session under aggregate >> control is being setup. >> There is a single DESCRIBE request >> DESCRIBE rtsp://foo/twister RTSP/1.0 >> >> And two separate SETUP requests: >> SETUP rtsp://foo/twister/audio RTSP/1.0 >> SETUP rtsp://foo/twister/video RTSP/1.0 >> >> Will the client have to send a single TEARDOWN like the DESCRIBE, or >> will it have to send two separate TEARDOWNs, or is it for the client to >> decide? >> Thanks, >> Sujay. >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 02 06:55:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1iF7-00044o-Vw; Tue, 02 Jan 2007 06:55:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1iF6-00044E-C3; Tue, 02 Jan 2007 06:55:44 -0500 Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1iF4-0005Za-P6; Tue, 02 Jan 2007 06:55:44 -0500 Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 5ED8A1D88F7B; Tue, 2 Jan 2007 12:55:39 +0100 (CET) Received: from mailgw1.hhi.de (mailgw1.hhi.de [192.168.20.43]) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id EE5821D88F53; Tue, 2 Jan 2007 12:55:37 +0100 (CET) Received: from mail.hhi.fraunhofer.de (unknown [192.168.20.45]) by mailgw1.hhi.de (Postfix) with ESMTP id CD4AC13C8300; Tue, 2 Jan 2007 12:55:37 +0100 (CET) Received: from ipam040189 (unknown [172.19.40.189]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id BC9261D88F53; Tue, 2 Jan 2007 12:55:37 +0100 (CET) From: "Thomas Schierl" To: , Date: Tue, 2 Jan 2007 12:55:38 +0100 Organization: HHI/FhG Message-ID: <000d01c72e64$eb7aa840$bd2813ac@ipam040189> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01C72E6D.4D3F1040" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accrix7EZT44huXmSZiS6Ml3dak7LAC2D08g X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de X-Spam-Level: X-Spam-Status: No, hits=-104.7 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64 X-alterMIME: Yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Subject: [MMUSIC] FW: I-D ACTION:draft-schierl-mmusic-layered-codec-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C72E6D.4D3F1040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi and a Happy New Year, A new version of draft-schierl-mmusic-layered-codec on "Signaling media decoding dependency in Session Description Protocol (SDP)" is available. Please read the draft, Thomas > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, December 29, 2006 9:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-schierl-mmusic-layered-codec-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Signaling media decoding dependency in Session > Description Protocol (SDP) > Author(s) : S. Wenger, T. Schierl > Filename : draft-schierl-mmusic-layered-codec-02.txt > Pages : 14 > Date : 2006-12-29 > > This memo defines semantics that allow for signaling the decoding > dependency of different media descriptions with the same media type in > the Session Description Protocol (SDP). This is required, for example, > if media data is separated and transported in different network streams > as a result of the use of a layered or multiple descriptive media coding > process. > A new grouping type "DDP" -- decoding dependency -- is defined, to be > used in conjunction with RFC 3388 entitled "Grouping of Media Lines in > the Session Description Protocol". In addition, an attribute is > specified describing the relationship of the media streams in a "DDP" > group. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-schierl-mmusic-layered-codec- > 02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-schierl-mmusic-layered-codec-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schierl-mmusic-layered-codec-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_000E_01C72E6D.4D3F1040 Content-Type: Message/External-body; name="ATT00004.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00004.dat" Content-Type: text/plain Content-ID: <2006-12-29102324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schierl-mmusic-layered-codec-02.txt ------=_NextPart_000_000E_01C72E6D.4D3F1040 Content-Type: Message/External-body; name="draft-schierl-mmusic-layered-codec-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-schierl-mmusic-layered-codec-02.txt" Content-Type: text/plain Content-ID: <2006-12-29102324.I-D@ietf.org> ------=_NextPart_000_000E_01C72E6D.4D3F1040 Content-Type: text/plain; name="ATT00007.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00007.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_000E_01C72E6D.4D3F1040 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_000E_01C72E6D.4D3F1040-- From mmusic-bounces@ietf.org Tue Jan 02 09:54:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1l1n-0004nX-3y; Tue, 02 Jan 2007 09:54:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1l1l-0004kk-Lg for mmusic@ietf.org; Tue, 02 Jan 2007 09:54:09 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1l1k-0006SA-6h for mmusic@ietf.org; Tue, 02 Jan 2007 09:54:09 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 02 Jan 2007 06:54:07 -0800 X-IronPort-AV: i="4.12,227,1165219200"; d="scan'208"; a="454624116:sNHT64821512" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l02Es7Jv013734 for ; Tue, 2 Jan 2007 06:54:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l02Es7nc022122 for ; Tue, 2 Jan 2007 06:54:07 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 06:54:07 -0800 Received: from [10.21.121.207] ([10.21.121.207]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 06:54:07 -0800 Message-ID: <459A720D.8080209@cisco.com> Date: Tue, 02 Jan 2007 09:54:05 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDP Capability Negotation: Minutes of 12/19/06 conference call References: <4599D915.2010903@cisco.com> In-Reply-To: <4599D915.2010903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jan 2007 14:54:07.0131 (UTC) FILETIME=[DA484EB0:01C72E7D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4136; t=1167749647; x=1168613647; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotation=3A=20Minutes =20of=2012/19/06=20conference=0A=20call |Sender:=20; bh=OLiGa0Tz5q7BCN16FeXIOWJaF6JtBcwJLE+3YZyYje4=; b=oLfKNDD/0FMkpNUOtnmVvrRbEfmOMVvF6hdEGyUsIpDi2LegSgcWA4NfO8Y6VgUeDKKZ55lT e0Fankdz/KUtU7Uv5+V9YYnNykE929BR6Iptul8u8vZd5jutYDdPcF8K; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Flemming Andreasen wrote: > Greetings > > The SDP Capability Negotiation Design team held its first conference > call on 12/12/06. Oops - that should obviously have said: The SDP Capability Negotiation Design team held its second conference call on 12/19/06. > The attendees were: > > Cullen Jennings > Flemming Andreasen > Thomas Stach > Roni Even > Bob Gilman > Colin Perkins > > The items discussed were > > 1) Feedback on the open issues posted to the list (REQ-50, 150, and 160) > ---------------------------------------------------------------------------- > > The design team had already discussed these on the last call and were > in general agreement with those requirements as stated in the current > requirements document. So far, there has not been any feedback on any > of these on the mailing list. Roni Even furthermore noted that > alternatives between media streams are not used in current products > (which argues for keeping REQ-160 optional). > > > 2) Review updated requirements (85, 121, 122, 301 and 302) > --------------------------------------------------------------- > There was consensus within the design team on the updated requirements > (85, 121, 122, 301 and 302), however REQ-85 generated a bit of > discussion around whether we should make a distinction between SIP > B2BUAs and SIP proxies as middle-boxes and impose different > requirements on them. It was suggested that B2BUAs should not pass > anything in the SDP that they do not understand, as that might > interfere with correct operation. Conversely, such a requirement does > not allow for transparency and even proxies may need to understand the > extensions in certain middle-box scenarios. The design team agreed it > was best to stay silent on this from a requirements point of view, but > that we should add a couple of informative statements around > middle-boxes (proxies versus B2BUAs) and how the new capability > negotiation extensions may affect them if they pass them through > without understanding them (and e.g. they process media). > > > 3) Should we have some security requirements, and if so, what are they ? > ------------------------------------------------------------------------- > SDP capability negotiation introduces a new set of security issues, > and the question was whether the requirements document should try and > address those by identifying specific security requirements. Cullen > did not see a need for specific security requirements in the document > and the team agreed with that. We will however be making certain > security assumptions, and those need to be documented. More specifically: > - Whatever is carrying the SDP is assumed to provide integrity (but > not confidentiality), and from there we need to protect against > downgrade attacks. > - We do not provide the security solution for "whatever is carrying > the SDP" > - We will have to describe our trust model (e.g. end-to-end and using > "identity", or trusted with hop-by-hop signaling) > > We will only provide the security assumptions in the requirements > document. All the "real" security considerations (and assumptions) of > course need to go in the solutions document. One security > consideration that will eventually need to be described is the playing > out of early media prior to receiving an answer (or other indication > of the answerers chosen configuration). > > > 4) Next call and plan forward > ------------------------------ > An updated requirements document in accordance with the above will be > published soon. Once that is done, the plan is to issue a WGLC to > ensure working group consensus on the requirements > An updated solution document will be published by 1/2/07. > We will not have a call on 1/2/07. The next call will be on 1/9/07, > where the updated solution document will be discussed. > > Thanks > > -- Flemming > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 02 13:46:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1odi-0001AJ-KU; Tue, 02 Jan 2007 13:45:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1odh-0001AA-Jt for mmusic@ietf.org; Tue, 02 Jan 2007 13:45:33 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1odg-0008Sx-AM for mmusic@ietf.org; Tue, 02 Jan 2007 13:45:33 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 02 Jan 2007 10:45:31 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l02IjVnH014877 for ; Tue, 2 Jan 2007 10:45:31 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l02IjOQF010752 for ; Tue, 2 Jan 2007 10:45:31 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 10:45:30 -0800 Received: from [10.21.121.207] ([10.21.121.207]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 10:45:30 -0800 Message-ID: <459AA849.6080308@cisco.com> Date: Tue, 02 Jan 2007 13:45:29 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jan 2007 18:45:30.0418 (UTC) FILETIME=[2D5DC920:01C72E9E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=856; t=1167763531; x=1168627531; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotiation=3A=20Solution=20Document=20 |Sender:=20; bh=9hs7+z1AOZoxEec50N76/Y9VrA79DxynUegKvWqyVow=; b=gU1UW1GtOgDQkdmd1rFS79lY/WhefEruhTDX9CzBUZnDYvpk+8hI9GEnpBNs9Fe0xJ2rdXj0 79YaXq3SdYcMcXWnKuAcn5IqXQE/2SVHkIKi7c/jhEn6Eav7RA5tScOn; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [MMUSIC] SDP Capability Negotiation: Solution Document X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Greetings Based on our updated requirements for SDP capability negotiation, I have just submitted an updated solution document as draft-ietf-mmusic-sdp-capability-negotiation-00.txt, which you can retrieve from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-00.txt until it appears in the archives. We will discuss this document on our next SDP Capability Negotiation design team call (1/9/07). Note that there are some open issues in the document currently (look for "Editor's note"), in particular in the area of supporting media capabilities at both the session level and the media level, which is not terribly elegant or even clear in the current document. Comments, suggestions, and other feedback on this as well as the rest of the document is hereby solicited. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 02 17:10:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rqA-0004Sd-49; Tue, 02 Jan 2007 17:10:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1rq8-0004RA-Qc for mmusic@ietf.org; Tue, 02 Jan 2007 17:10:36 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1rq6-0003Vu-GM for mmusic@ietf.org; Tue, 02 Jan 2007 17:10:36 -0500 Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l02MAXFf006079 for ; Tue, 2 Jan 2007 15:10:33 -0700 (MST) Received: from kealia.sfbay.sun.com (kealia.SFBay.Sun.COM [10.6.186.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id l02MAXIX022182 for ; Tue, 2 Jan 2007 14:10:33 -0800 (PST) Received: from [129.146.99.94] (d-mpk14-99-94.SFBay.Sun.COM [129.146.99.94]) by kealia.sfbay.sun.com (Postfix) with ESMTP id 7EB96BCAB for ; Tue, 2 Jan 2007 14:10:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mmusic@ietf.org From: Joe Pallas Date: Tue, 2 Jan 2007 14:10:31 -0800 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [MMUSIC] draft-ietf-mmusic-rfc2326bis-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org A few remarks on the changes in this draft: Section 2.2 doesn't have any major changes, but, to complement the change to the description of "Live" in section 1.4, it may be useful to add something about seekable live content, such as: In some cases, the server providing live content may be saving some or all of the material to allow clients to pause the stream and resume it from the paused point, or to "rewind" and play continuously from a point earlier than the live point. Hence, this use case does not necessarily exclude playing from other than the live point of the stream, playing with scales other than 1.0, etc. Section 2.5 seems to mostly say that RTSP 2.0 is not likely to be useful in this case without extensions. Perhaps it shouldn't say much more than that. Section C.1.5 on SDP attributes sendrecv, recvonly, and sendonly is confusing. In particular, the mention of '"PLAY" mode' is odd, since RECORD mode is explicitly undefined, so PLAY mode is the only mode defined. For that matter, why isn't "RECORD" removed from the grammar for mode -- is there some value to making it reserved but undefined? Also, section 13.4.2 mentions the RECORD request, which no longer exists. Section F introduces new language on the interpretation of CR and LF for backward compatibility. The language in RFC2326 was a bad idea, since it can be paraphrased as "Receivers should be prepared for senders to violate this specification." While this is always true, putting it into the specification itself is unwise, as it appears to give license to violators. That said, the language that was added to section F uses the word "should" in a dangerous way. The new instruction raises doubts about the correct interpretation of sequences like CR LF LF, LF CR, and CR CR LF. If there are, in fact, any RTSP 1.0 clients still extant that take such liberties, maybe it would be best to pretend they don't exist. Hope this is useful. joe _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 02 19:03:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1tbF-000262-7I; Tue, 02 Jan 2007 19:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1tbE-0001wr-4q for mmusic@ietf.org; Tue, 02 Jan 2007 19:03:20 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1tXH-0008JE-HY for mmusic@ietf.org; Tue, 02 Jan 2007 18:59:18 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Jan 2007 15:59:15 -0800 X-IronPort-AV: i="4.12,228,1165219200"; d="scan'208"; a="97379888:sNHT51133536" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l02NxEZV023180 for ; Tue, 2 Jan 2007 15:59:14 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l02NxE4g004859 for ; Tue, 2 Jan 2007 15:59:14 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 15:59:14 -0800 Received: from [192.168.0.10] ([10.21.90.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 15:59:14 -0800 In-Reply-To: <459AA849.6080308@cisco.com> References: <459AA849.6080308@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] SDP Capability Negotiation: Solution Document Date: Tue, 2 Jan 2007 15:59:12 -0800 To: Flemming Andreasen X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Jan 2007 23:59:14.0501 (UTC) FILETIME=[0164E750:01C72ECA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2533; t=1167782354; x=1168646354; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Soluti on=20Document=20 |Sender:=20; bh=2lhwttfKhBncV4sqYkue+KeV7XDiq7Zo0x4LFSvOuUA=; b=HH9fNKNA+cDTNMaP8MB1gm3FKOgKOy7mLFeQwzM4F4SJRswc9IgHlijcndqQYp1JrZo94y/A RTvuutEHRkcD4pTD8+es9OJqA/x2LQtcqkFpX6SOj3qXVHHIZZYsI46S; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Flemming, > ... Another issue here is that > payload type numbers, which really have only media-level > scope, are > ill-suited to be used at the session-level or across > multiple media > streams (as is being done here). However, an alternative > (and more > proper) solution seems to involve significantly more work > and > deviations from the current SDP framework. This in turn > makes it > more difficult to automatically use new media types, > formats, > protocols, etc. defined elsewhere within this framework, > and that > is a major disadvantage. Another option is to forgo the > session- > level media capabilities as well as the ability to > reference across > media streams - it will make the solution less efficient > though and > difficult to express latent capabilities for media > streams not > included in the offer or answer.] It is noted in a few places in your document that session-level scoping of the attributes are in certain cases confusing or not suitable. I recall going through the exercise of trying to put security descriptions at the session level and deciding that it added too much complexity. Is there a compelling need to even have a session-level scope for your attributes? Mark On Jan 2, 2007, at 10:45 AM, Flemming Andreasen wrote: > Greetings > > Based on our updated requirements for SDP capability negotiation, I > have just submitted an updated solution document as draft-ietf- > mmusic-sdp-capability-negotiation-00.txt, which you can retrieve > from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp- > capability-negotiation-00.txt until it appears in the archives. > > We will discuss this document on our next SDP Capability > Negotiation design team call (1/9/07). Note that there are some > open issues in the document currently (look for "Editor's note"), > in particular in the area of supporting media capabilities at both > the session level and the media level, which is not terribly > elegant or even clear in the current document. Comments, > suggestions, and other feedback on this as well as the rest of the > document is hereby solicited. > > Thanks > > -- Flemming > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 10:42:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28FK-0004k4-7v; Wed, 03 Jan 2007 10:41:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H28FI-0004jt-Bv for mmusic@ietf.org; Wed, 03 Jan 2007 10:41:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H28FG-00053j-Uz for mmusic@ietf.org; Wed, 03 Jan 2007 10:41:40 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 03 Jan 2007 07:41:38 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l03Ffcg2023816 for ; Wed, 3 Jan 2007 07:41:38 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l03FfaIr003057 for ; Wed, 3 Jan 2007 07:41:38 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 10:41:25 -0500 Received: from [10.86.242.124] ([10.86.242.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 10:41:25 -0500 Message-ID: <459BCEA4.4030501@cisco.com> Date: Wed, 03 Jan 2007 10:41:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MMUSIC] SDP Capability Negotiation: Solution Document References: <459AA849.6080308@cisco.com> <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> In-Reply-To: <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jan 2007 15:41:25.0352 (UTC) FILETIME=[A0683680:01C72F4D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3551; t=1167838898; x=1168702898; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Soluti on=20Document |Sender:=20; bh=EJT5LhjGj9ZVGPUZE2nW2iN5VHzfjGPJZ+VV2vn0e58=; b=YbF7OLWxQOne7zD70qngG+fKNOmvROZ3AgfRcnAG9R1kHjm+IIUn8AYvBwPw3igyhO1lXzJq Ryx3KUBvnxGPDTYeE9J595s/UbYNiBPsJcqB1EPJDwwedpwmsEYIjIr7; Authentication-Results: sj-dkim-6; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Flemming Andreasen , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I don't understand why anyone wants to *ban* the use of at attribute at session level. Session level attributes can be understood as simply defaults when there is no media stream level attribute for a media stream. As long as viewed that way, I don't see the issue with using *any* attribute at session level. It may of course be the case that the semantics of a particular attribute are such that applying it to more than one media stream makes no sense. In that case there won't be any benefit to using the attribute at session level, but it doesn't require that using the attribute at session level be banned. The challenge is defining attributes in such a way that there *is* some benefit to using it at session level. That clearly isn't possible for all attributes. Paul Mark Baugher wrote: > Flemming, > >> ... Another issue here is that >> payload type numbers, which really have only media-level >> scope, are >> ill-suited to be used at the session-level or across >> multiple media >> streams (as is being done here). However, an alternative >> (and more >> proper) solution seems to involve significantly more work and >> deviations from the current SDP framework. This in turn >> makes it >> more difficult to automatically use new media types, formats, >> protocols, etc. defined elsewhere within this framework, and >> that >> is a major disadvantage. Another option is to forgo the >> session- >> level media capabilities as well as the ability to reference >> across >> media streams - it will make the solution less efficient >> though and >> difficult to express latent capabilities for media streams not >> included in the offer or answer.] > > It is noted in a few places in your document that session-level scoping > of the attributes are in certain cases confusing or not suitable. I > recall going through the exercise of trying to put security descriptions > at the session level and deciding that it added too much complexity. Is > there a compelling need to even have a session-level scope for your > attributes? > > Mark > > On Jan 2, 2007, at 10:45 AM, Flemming Andreasen wrote: > >> Greetings >> >> Based on our updated requirements for SDP capability negotiation, I >> have just submitted an updated solution document as >> draft-ietf-mmusic-sdp-capability-negotiation-00.txt, which you can >> retrieve from >> http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-00.txt >> until it appears in the archives. >> >> We will discuss this document on our next SDP Capability Negotiation >> design team call (1/9/07). Note that there are some open issues in the >> document currently (look for "Editor's note"), in particular in the >> area of supporting media capabilities at both the session level and >> the media level, which is not terribly elegant or even clear in the >> current document. Comments, suggestions, and other feedback on this as >> well as the rest of the document is hereby solicited. >> >> Thanks >> >> -- Flemming >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 11:36:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H294h-0004ZY-8u; Wed, 03 Jan 2007 11:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H294f-0004ZO-5D for mmusic@ietf.org; Wed, 03 Jan 2007 11:34:46 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H294d-0002YG-MV for mmusic@ietf.org; Wed, 03 Jan 2007 11:34:45 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2007 08:34:43 -0800 X-IronPort-AV: i="4.12,233,1165219200"; d="scan'208"; a="454855220:sNHT50559732" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03GYhgX002939 for ; Wed, 3 Jan 2007 08:34:43 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l03GYhZH017835 for ; Wed, 3 Jan 2007 08:34:43 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 08:34:42 -0800 Received: from [192.168.0.10] ([10.21.122.222]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 08:34:42 -0800 In-Reply-To: <459BCEA4.4030501@cisco.com> References: <459AA849.6080308@cisco.com> <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> <459BCEA4.4030501@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <217F5F04-68FB-4EE2-B487-99595E761170@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] SDP Capability Negotiation: Solution Document Date: Wed, 3 Jan 2007 08:34:38 -0800 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Jan 2007 16:34:42.0742 (UTC) FILETIME=[12333560:01C72F55] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3834; t=1167842083; x=1168706083; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Soluti on=20Document |Sender:=20; bh=pN97BkDuvwTjCkcDr2MbWDGU000so30F24w9XTJbIf8=; b=d2IRxUxUZ+p+x17v4YagfjfrHpvD4E7wYb6Dh62xM3u7VqLHa95kKTdtmVL7ObKRcnRdIG5c voL9AmZnlasSBlJrMrHHs79TxvVtnqIVuBfmiV3v32JFhRKRZJ6TGrJw; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Flemming Andreasen , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I did not say anything about banning session-level attributes. You should read my note again. Mark On Jan 3, 2007, at 7:41 AM, Paul Kyzivat wrote: > I don't understand why anyone wants to *ban* the use of at > attribute at session level. Session level attributes can be > understood as simply defaults when there is no media stream level > attribute for a media stream. As long as viewed that way, I don't > see the issue with using *any* attribute at session level. > > It may of course be the case that the semantics of a particular > attribute are such that applying it to more than one media stream > makes no sense. In that case there won't be any benefit to using > the attribute at session level, but it doesn't require that using > the attribute at session level be banned. > > The challenge is defining attributes in such a way that there *is* > some benefit to using it at session level. That clearly isn't > possible for all attributes. > > Paul > > Mark Baugher wrote: >> Flemming, >>> ... Another issue here is that >>> payload type numbers, which really have only media- >>> level scope, are >>> ill-suited to be used at the session-level or across >>> multiple media >>> streams (as is being done here). However, an >>> alternative (and more >>> proper) solution seems to involve significantly more >>> work and >>> deviations from the current SDP framework. This in turn >>> makes it >>> more difficult to automatically use new media types, >>> formats, >>> protocols, etc. defined elsewhere within this >>> framework, and that >>> is a major disadvantage. Another option is to forgo the >>> session- >>> level media capabilities as well as the ability to >>> reference across >>> media streams - it will make the solution less >>> efficient though and >>> difficult to express latent capabilities for media >>> streams not >>> included in the offer or answer.] >> It is noted in a few places in your document that session-level >> scoping of the attributes are in certain cases confusing or not >> suitable. I recall going through the exercise of trying to put >> security descriptions at the session level and deciding that it >> added too much complexity. Is there a compelling need to even >> have a session-level scope for your attributes? >> Mark >> On Jan 2, 2007, at 10:45 AM, Flemming Andreasen wrote: >>> Greetings >>> >>> Based on our updated requirements for SDP capability negotiation, >>> I have just submitted an updated solution document as draft-ietf- >>> mmusic-sdp-capability-negotiation-00.txt, which you can retrieve >>> from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp- >>> capability-negotiation-00.txt until it appears in the archives. >>> >>> We will discuss this document on our next SDP Capability >>> Negotiation design team call (1/9/07). Note that there are some >>> open issues in the document currently (look for "Editor's note"), >>> in particular in the area of supporting media capabilities at >>> both the session level and the media level, which is not terribly >>> elegant or even clear in the current document. Comments, >>> suggestions, and other feedback on this as well as the rest of >>> the document is hereby solicited. >>> >>> Thanks >>> >>> -- Flemming >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 13:15:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2AeC-0000ob-Cr; Wed, 03 Jan 2007 13:15:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ae5-0000hI-99 for mmusic@ietf.org; Wed, 03 Jan 2007 13:15:25 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Aaf-0002xf-61 for mmusic@ietf.org; Wed, 03 Jan 2007 13:11:54 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l03IBcR29148; Wed, 3 Jan 2007 13:11:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Wed, 3 Jan 2007 12:11:37 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA05@zrc2hxm2.corp.nortel.com> In-Reply-To: <457896E8.6080105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: AccaUDZNWsJnubQiQF6T9eNU4OAdDAVEbViw From: "Brian Stucker" To: "Paul Kyzivat" , "Christer Holmberg \(JO/LMF\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Miguel Garcia , "Gonzalo Camarillo \(JO/LMF\)" , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Use UPDATE if PRACK isn't supported. I don't think we should allow an ICE SDP offer to occur on the 200 OK because, quite honestly, I don't think anyone should be generating an SDP offer on 200. It makes no sense... You've agreed to take a call that you're not sure you're going to agree on the media for? We have TCP, UPDATE, and PRACK. Since ICE is new, why not use these new tools and depricate this obviously problematic offer/answer exchange for ICE? Is anyone out there really going to design something to send an SDP offer on the 200 OK with ICE candidate addresses knowing that they may wind up with a call failure or horrible clipping problems? Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, December 07, 2006 4:34 PM > To: Christer Holmberg (JO/LMF) > Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic > Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >=20 > Well then, how *can* ICE work with an offerless INVITE or=20 > reINVITE if PRACK is not used? >=20 > Paul >=20 > Christer Holmberg (JO/LMF) wrote: > >>> But that would only work when both UAs support PRACK. > >> Since ICE is new functionality anyway, would it be such a=20 > burden to=20 > >> require implementors of ICE to support PRACK? > >=20 > > Isn't that what I propsed when we discussed the 18x retransmission=20 > > "hack" that ICE uses? > >=20 > > The message at that point was that it people did NOT want=20 > to require=20 > > PRACK in order to support ICE... > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >> Paul > >> > >>> Gonzalo > >>> > >>> Paul Kyzivat wrote: > >>>> When a UAS has received an offerless INVITE, and wants=20 > to use ICE,=20 > >>>> wouldn't it be better for it to return an offer in a 1xx > >> rather than > >>>> a 200, in order to sidestep this issue? > >>>> > >>>> Paul > >>>> > >>>> Gonzalo Camarillo wrote: > >>>> > Hi, > >>>> > > >>>> >> With respect your proposal to delay the ACK with the > >> SDP answer... > >>>> >> Isn't it so that delaying the ACK will generate > >> retransmissions > >>>> of >> the 200 OK response? I think we need to be careful > >> with this > >>>>>> behavior. Is it possible to generate the ACK with the > >> SDP answer, > >>>>>> gather the candidate addresses, and then do a re-INVITE with an > >>>> SDP >> offer? > >>>> > > >>>> > the way it is usually specified (e.g., in 3pcc or session > >>>> policies) is > that we recommend to, in principle,=20 > delay the ACK=20 > >>>> because the operation > that needs to be done between the > >> 200 OK and > >>>> the ACK usually completes > very quickly. However, > >> endpoints need to > >>>> also be prepared for that > operation not to complete so > >> quickly. In > >>>> such a case, the endpoint needs > to send the ACK with=20 > as good an=20 > >>>> answer it can generate and UPDATE or > re-INVITE at a > >> later point, > >>>> as you suggested. > >>>> > > >>>> > Cheers, > >>>> > > >>>> > Gonzalo > >>>> > > >>>> > _______________________________________________ > >>>> > mmusic mailing list > >>>> > mmusic@ietf.org > >>>> > https://www1.ietf.org/mailman/listinfo/mmusic > >>>> > > >>>> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 14:13:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BXX-0008IG-PZ; Wed, 03 Jan 2007 14:12:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2BXW-0008Gb-Lk for mmusic@ietf.org; Wed, 03 Jan 2007 14:12:42 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2BXV-0004Rn-8q for mmusic@ietf.org; Wed, 03 Jan 2007 14:12:42 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Jan 2007 14:12:41 -0500 X-IronPort-AV: i="4.12,233,1165208400"; d="scan'208"; a="110805327:sNHT52532472" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l03JCfDc028900; Wed, 3 Jan 2007 14:12:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03JCa7x020786; Wed, 3 Jan 2007 14:12:40 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 14:12:34 -0500 Received: from [10.86.242.124] ([10.86.242.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 14:12:34 -0500 Message-ID: <459C0020.4070101@cisco.com> Date: Wed, 03 Jan 2007 14:12:32 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE References: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA05@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA05@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jan 2007 19:12:34.0111 (UTC) FILETIME=[1F936CF0:01C72F6B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4399; t=1167851561; x=1168715561; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20Offer=20in=20a=20200=20(OK)=20and=20ICE |Sender:=20 |To:=20Brian=20Stucker=20; bh=7k2SMf3jA3uq7J2MtWsMUv8j+1TfNk3DkeVljVFweqY=; b=PyLVqmEdVmlFKPO+JsUg4VAZq45LVstJcqBBQi36uHhd3f/3avYv98sBcZ7YID//SiheTMbX 1Acu6hk/vgyTE4sDLK9SYzWOA51DwWYtSWKwt/+4KHg865+mqY8b4PP2; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Miguel Garcia , mmusic , "Gonzalo Camarillo \(JO/LMF\)" , "Christer Holmberg \(JO/LMF\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I just went back and reviewed this thread because its continued over a long time. It appears that everybody is pretty much agreeing on the general principles. Namely that if you are using ICE then you need to deliver the initial offer, with ICE, reliably *before* the 200. I don't think UPDATE will work here, because I don't think it is appropriate to use UPDATE for the first offer, before any other offer has been sent in the invite dialog usage. (I guess this is debatable, but it isn't permitted according to the agreements codified in the offeranswer draft.) If the UAC doesn't provide an offer and doesn't support PRACK then I think the UAS simply can't use ICE. If that means it must reject the call then so be it. Paul Brian Stucker wrote: > Use UPDATE if PRACK isn't supported. > > I don't think we should allow an ICE SDP offer to occur on the 200 OK > because, quite honestly, I don't think anyone should be generating an > SDP offer on 200. It makes no sense... You've agreed to take a call that > you're not sure you're going to agree on the media for? > > We have TCP, UPDATE, and PRACK. Since ICE is new, why not use these new > tools and depricate this obviously problematic offer/answer exchange for > ICE? > > Is anyone out there really going to design something to send an SDP > offer on the 200 OK with ICE candidate addresses knowing that they may > wind up with a call failure or horrible clipping problems? > > Regards, > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, December 07, 2006 4:34 PM >> To: Christer Holmberg (JO/LMF) >> Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic >> Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >> >> Well then, how *can* ICE work with an offerless INVITE or >> reINVITE if PRACK is not used? >> >> Paul >> >> Christer Holmberg (JO/LMF) wrote: >>>>> But that would only work when both UAs support PRACK. >>>> Since ICE is new functionality anyway, would it be such a >> burden to >>>> require implementors of ICE to support PRACK? >>> Isn't that what I propsed when we discussed the 18x retransmission >>> "hack" that ICE uses? >>> >>> The message at that point was that it people did NOT want >> to require >>> PRACK in order to support ICE... >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>>> Paul >>>> >>>>> Gonzalo >>>>> >>>>> Paul Kyzivat wrote: >>>>>> When a UAS has received an offerless INVITE, and wants >> to use ICE, >>>>>> wouldn't it be better for it to return an offer in a 1xx >>>> rather than >>>>>> a 200, in order to sidestep this issue? >>>>>> >>>>>> Paul >>>>>> >>>>>> Gonzalo Camarillo wrote: >>>>>> > Hi, >>>>>> > >>>>>> >> With respect your proposal to delay the ACK with the >>>> SDP answer... >>>>>> >> Isn't it so that delaying the ACK will generate >>>> retransmissions >>>>>> of >> the 200 OK response? I think we need to be careful >>>> with this >>>>>>>> behavior. Is it possible to generate the ACK with the >>>> SDP answer, >>>>>>>> gather the candidate addresses, and then do a re-INVITE with an >>>>>> SDP >> offer? >>>>>> > >>>>>> > the way it is usually specified (e.g., in 3pcc or session >>>>>> policies) is > that we recommend to, in principle, >> delay the ACK >>>>>> because the operation > that needs to be done between the >>>> 200 OK and >>>>>> the ACK usually completes > very quickly. However, >>>> endpoints need to >>>>>> also be prepared for that > operation not to complete so >>>> quickly. In >>>>>> such a case, the endpoint needs > to send the ACK with >> as good an >>>>>> answer it can generate and UPDATE or > re-INVITE at a >>>> later point, >>>>>> as you suggested. >>>>>> > >>>>>> > Cheers, >>>>>> > >>>>>> > Gonzalo >>>>>> > >>>>>> > _______________________________________________ >>>>>> > mmusic mailing list >>>>>> > mmusic@ietf.org >>>>>> > https://www1.ietf.org/mailman/listinfo/mmusic >>>>>> > >>>>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 14:56:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2CDE-0006OD-Ne; Wed, 03 Jan 2007 14:55:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2CDD-0006Nt-8S for mmusic@ietf.org; Wed, 03 Jan 2007 14:55:47 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2CDB-000482-U5 for mmusic@ietf.org; Wed, 03 Jan 2007 14:55:47 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jan 2007 14:55:47 -0500 X-IronPort-AV: i="4.12,233,1165208400"; d="scan'208"; a="110809713:sNHT62591884" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l03Jtjed012864 for ; Wed, 3 Jan 2007 14:55:45 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03Jtj7f003712 for ; Wed, 3 Jan 2007 14:55:45 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 14:55:45 -0500 Received: from [10.86.242.124] ([10.86.242.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 14:55:45 -0500 Message-ID: <459C0A3F.9050603@cisco.com> Date: Wed, 03 Jan 2007 14:55:43 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MMUSIC] SDP Capability Negotiation: Solution Document References: <459AA849.6080308@cisco.com> <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> <459BCEA4.4030501@cisco.com> <217F5F04-68FB-4EE2-B487-99595E761170@cisco.com> In-Reply-To: <217F5F04-68FB-4EE2-B487-99595E761170@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jan 2007 19:55:45.0178 (UTC) FILETIME=[27F8DFA0:01C72F71] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3880; t=1167854145; x=1168718145; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Soluti on=20Document |Sender:=20 |To:=20Mark=20Baugher=20; bh=19HrRBJ5cLWSuCOn+OyjlzmjnczPvKu89RvmTIwGZUs=; b=euFRDKEk4o2DHyTXmSgHPAdDdiVAi3QQdZKiONNmv6UsBaSI7Nxi4Mep01fefR4pAIffLzvC ywhFdbik5B9LsFzRn2Mji0YKuFh1LFDcUgzhF75s/2Aj4lSKFRsgRbAC; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Flemming Andreasen , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Mark Baugher wrote: > I did not say anything about banning session-level attributes. You > should read my note again. Sorry, I guess I wasn't clear. You seem to be recommending that in some cases it might not be feasible or worth the trouble to define a session level attribute - that the attribute could instead be defined only for media level. My point is that I don't understand why it is ever necessary to specify that an attribute be usable only at media level. (Though RFC 4566 defines several that are.) The real issue is to identify those cases where the same attribute definition cannot meaningfully appear in more than one media field - either by being repeated or by by being defaulted into more than one media field from session level. For example, a=rtpmap is defined as only media level, but it could be quite useful in some cases to use it as a session level attribute. E.g. (some lines omitted) m=audio 49001 RTP/AVP 96 97 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 m=audio 49002 RTP/AVP 96 97 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 could be written as follows if a=rtpmap were allowed as a session level attribute: a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 m=audio 49001 RTP/AVP 96 97 m=audio 49002 RTP/AVP 96 97 Even in cases where the same attribute value doesn't make sense in multiple media fields, there would be no real harm in allowing the attribute at session level. For example, the following would be equivalent: m=audio 49001 RTP/AVP 96 97 a=label:english m=audio 49002 RTP/AVP 96 97 a=label:spanish a=label:english m=audio 49001 RTP/AVP 96 97 m=audio 49002 RTP/AVP 96 97 a=label:spanish Conversely the following both have the same nonsensical meaning: m=audio 49001 RTP/AVP 96 97 a=label:english m=audio 49002 RTP/AVP 96 97 a=label:english a=label:english m=audio 49001 RTP/AVP 96 97 m=audio 49002 RTP/AVP 96 97 Its too late now to state that existing attribute definitions that specified to be only media level, for reasons of backward compatibility. But I think it would make sense to stop defining *new* attributes that are only valid at media level. Paul > Mark > > On Jan 3, 2007, at 7:41 AM, Paul Kyzivat wrote: > >> I don't understand why anyone wants to *ban* the use of at attribute >> at session level. Session level attributes can be understood as simply >> defaults when there is no media stream level attribute for a media >> stream. As long as viewed that way, I don't see the issue with using >> *any* attribute at session level. >> >> It may of course be the case that the semantics of a particular >> attribute are such that applying it to more than one media stream >> makes no sense. In that case there won't be any benefit to using the >> attribute at session level, but it doesn't require that using the >> attribute at session level be banned. >> >> The challenge is defining attributes in such a way that there *is* >> some benefit to using it at session level. That clearly isn't possible >> for all attributes. >> >> Paul >> >> Mark Baugher wrote: [snip] >>> It is noted in a few places in your document that session-level >>> scoping of the attributes are in certain cases confusing or not >>> suitable. I recall going through the exercise of trying to put >>> security descriptions at the session level and deciding that it added >>> too much complexity. Is there a compelling need to even have a >>> session-level scope for your attributes? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 15:50:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D3t-0003Ux-2J; Wed, 03 Jan 2007 15:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D3j-0003PJ-AP; Wed, 03 Jan 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2D3i-00053V-2D; Wed, 03 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0A4483294A; Wed, 3 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2D3h-0001mI-U1; Wed, 03 Jan 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 03 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP Capability Negotiation Author(s) : F. Andreasen Filename : draft-ietf-mmusic-sdp-capability-negotiation-00.txt Pages : 30 Date : 2007-1-3 The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-capability-negotiation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-3131903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-capability-negotiation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-3131903.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Wed Jan 03 15:57:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DAV-00040O-P6; Wed, 03 Jan 2007 15:57:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DAT-0003xZ-KI for mmusic@ietf.org; Wed, 03 Jan 2007 15:57:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2DAL-0005oi-0H for mmusic@ietf.org; Wed, 03 Jan 2007 15:57:01 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2007 12:55:52 -0800 X-IronPort-AV: i="4.12,233,1165219200"; d="scan'208"; a="454922835:sNHT54036204" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l03KtqRg025512 for ; Wed, 3 Jan 2007 12:55:52 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03Ktl06000109 for ; Wed, 3 Jan 2007 12:55:52 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 12:55:49 -0800 Received: from [192.168.0.10] ([10.21.122.222]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 12:55:49 -0800 In-Reply-To: <459C0A3F.9050603@cisco.com> References: <459AA849.6080308@cisco.com> <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> <459BCEA4.4030501@cisco.com> <217F5F04-68FB-4EE2-B487-99595E761170@cisco.com> <459C0A3F.9050603@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4243F021-8D98-4971-A2BC-B896EF172660@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MMUSIC] SDP Capability Negotiation: Solution Document Date: Wed, 3 Jan 2007 12:55:48 -0800 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Jan 2007 20:55:49.0560 (UTC) FILETIME=[8C59EB80:01C72F79] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5236; t=1167857752; x=1168721752; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Soluti on=20Document |Sender:=20; bh=hvSlf7BYI+TdBvsnObgwMM2+1v+yGXrNMeslSnxsNxc=; b=czg3gaq2Bi5oDJdjy7gw8/LUefrHDm8MvD583sHsDR2js31GX32Sl8kIcl+2+omFgqDKmcEa AWWD+LGhPWdyOAu77j+0AwUlvggw+P/hczvdmRRA3XVoXP9EjNwOiTVH; Authentication-Results: sj-dkim-4; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Flemming Andreasen , mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On Jan 3, 2007, at 11:55 AM, Paul Kyzivat wrote: > > > Mark Baugher wrote: >> I did not say anything about banning session-level attributes. >> You should read my note again. > > Sorry, I guess I wasn't clear. You seem to be recommending that in > some cases it might not be feasible or worth the trouble to define > a session level attribute - that the attribute could instead be > defined only for media level. Right, that happened to be the case for SDP security descriptions. I don't know if it's the case for capability negotiation. > > My point is that I don't understand why it is ever necessary to > specify that an attribute be usable only at media level. In the case of SDP security descriptions, the attribute specified a key for the media stream and we decided not to share keys between media streams. Hence, the attribute was strictly media level. It was still possible to put common parameters at the session level, but that turned out to be more complex - in the case of security descriptions. > (Though RFC 4566 defines several that are.) The real issue is to > identify those cases where the same attribute definition cannot > meaningfully appear in more than one media field - either by being > repeated or by by being defaulted into more than one media field > from session level. This is related to my original question: What do we gain by doing this? Fewer lines? If the SDP is largely machine-generated and machine-read, this does not seem to be a compelling reason if it makes the specification more complex, e.g. requiring rules for over- riding session defaults in media entries, for example. > > For example, a=rtpmap is defined as only media level, but it could > be quite useful in some cases to use it as a session level > attribute. E.g. (some lines omitted) > > m=audio 49001 RTP/AVP 96 97 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > m=audio 49002 RTP/AVP 96 97 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > > could be written as follows if a=rtpmap were allowed as a session > level attribute: > > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > m=audio 49001 RTP/AVP 96 97 > m=audio 49002 RTP/AVP 96 97 > > Even in cases where the same attribute value doesn't make sense in > multiple media fields, there would be no real harm in allowing the > attribute at session level. For example, the following would be > equivalent: > > m=audio 49001 RTP/AVP 96 97 > a=label:english > m=audio 49002 RTP/AVP 96 97 > a=label:spanish > > a=label:english > m=audio 49001 RTP/AVP 96 97 > m=audio 49002 RTP/AVP 96 97 > a=label:spanish > > Conversely the following both have the same nonsensical meaning: > > m=audio 49001 RTP/AVP 96 97 > a=label:english > m=audio 49002 RTP/AVP 96 97 > a=label:english > > a=label:english > m=audio 49001 RTP/AVP 96 97 > m=audio 49002 RTP/AVP 96 97 > > Its too late now to state that existing attribute definitions that > specified to be only media level, for reasons of backward > compatibility. But I think it would make sense to stop defining > *new* attributes that are only valid at media level. Your examples are good ones. But there are cases when it's either necessary or simpler to tolerate some redundancy. As a rule, it's probably better to keep the SDP message as small as possible so I didn't mean to suggest that session-level attributes should be banned. Just questioned. Mark > > Paul > >> Mark >> On Jan 3, 2007, at 7:41 AM, Paul Kyzivat wrote: >>> I don't understand why anyone wants to *ban* the use of at >>> attribute at session level. Session level attributes can be >>> understood as simply defaults when there is no media stream level >>> attribute for a media stream. As long as viewed that way, I don't >>> see the issue with using *any* attribute at session level. >>> >>> It may of course be the case that the semantics of a particular >>> attribute are such that applying it to more than one media stream >>> makes no sense. In that case there won't be any benefit to using >>> the attribute at session level, but it doesn't require that using >>> the attribute at session level be banned. >>> >>> The challenge is defining attributes in such a way that there >>> *is* some benefit to using it at session level. That clearly >>> isn't possible for all attributes. >>> >>> Paul >>> >>> Mark Baugher wrote: > [snip] >>>> It is noted in a few places in your document that session-level >>>> scoping of the attributes are in certain cases confusing or not >>>> suitable. I recall going through the exercise of trying to put >>>> security descriptions at the session level and deciding that it >>>> added too much complexity. Is there a compelling need to even >>>> have a session-level scope for your attributes? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 15:59:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DCX-0006xC-Ay; Wed, 03 Jan 2007 15:59:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DCN-0006gf-5y for mmusic@ietf.org; Wed, 03 Jan 2007 15:58:59 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2DCJ-0006gf-Ad for mmusic@ietf.org; Wed, 03 Jan 2007 15:58:59 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l03KpL114199; Wed, 3 Jan 2007 15:51:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Wed, 3 Jan 2007 14:58:49 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711213ECEC@zrc2hxm2.corp.nortel.com> In-Reply-To: <459C0020.4070101@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: AccvayW/BlTQc5MRQriPKl8gKAWm/wADmfIA From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Miguel Garcia , mmusic , "Gonzalo Camarillo \(JO/LMF\)" , "Christer Holmberg \(JO/LMF\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Yeah, you're right, but I don't see why an INVITE with no SDP effectively seems to constitute an offer. I looked through the cases in RFC-3311 for the callee to send an UPDATE and it's not allowed unless an OFFER/ANSWER exchange completed via a reliable 18x/PRACK. Can someone enlighten me as to why UPDATE isn't equally acceptable for transporting an SDP offer as reliable 18x/PRACK? Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, January 03, 2007 1:13 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Christer Holmberg (JO/LMF); Miguel Garcia; Gonzalo=20 > Camarillo (JO/LMF); mmusic > Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >=20 > I just went back and reviewed this thread because its=20 > continued over a long time. It appears that everybody is=20 > pretty much agreeing on the general principles. Namely that=20 > if you are using ICE then you need to deliver the initial=20 > offer, with ICE, reliably *before* the 200. >=20 > I don't think UPDATE will work here, because I don't think it=20 > is appropriate to use UPDATE for the first offer, before any=20 > other offer has been sent in the invite dialog usage. (I=20 > guess this is debatable, but it isn't permitted according to=20 > the agreements codified in the offeranswer draft.) >=20 > If the UAC doesn't provide an offer and doesn't support PRACK=20 > then I think the UAS simply can't use ICE. If that means it=20 > must reject the call then so be it. >=20 > Paul >=20 > Brian Stucker wrote: > > Use UPDATE if PRACK isn't supported. > >=20 > > I don't think we should allow an ICE SDP offer to occur on=20 > the 200 OK=20 > > because, quite honestly, I don't think anyone should be=20 > generating an=20 > > SDP offer on 200. It makes no sense... You've agreed to take a call=20 > > that you're not sure you're going to agree on the media for? > >=20 > > We have TCP, UPDATE, and PRACK. Since ICE is new, why not use these=20 > > new tools and depricate this obviously problematic offer/answer=20 > > exchange for ICE? > >=20 > > Is anyone out there really going to design something to send an SDP=20 > > offer on the 200 OK with ICE candidate addresses knowing=20 > that they may=20 > > wind up with a call failure or horrible clipping problems? > >=20 > > Regards, > > Brian > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Thursday, December 07, 2006 4:34 PM > >> To: Christer Holmberg (JO/LMF) > >> Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic > >> Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE > >> > >> Well then, how *can* ICE work with an offerless INVITE or=20 > reINVITE if=20 > >> PRACK is not used? > >> > >> Paul > >> > >> Christer Holmberg (JO/LMF) wrote: > >>>>> But that would only work when both UAs support PRACK. > >>>> Since ICE is new functionality anyway, would it be such a > >> burden to > >>>> require implementors of ICE to support PRACK? > >>> Isn't that what I propsed when we discussed the 18x=20 > retransmission=20 > >>> "hack" that ICE uses? > >>> > >>> The message at that point was that it people did NOT want > >> to require > >>> PRACK in order to support ICE... > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>>> Paul > >>>> > >>>>> Gonzalo > >>>>> > >>>>> Paul Kyzivat wrote: > >>>>>> When a UAS has received an offerless INVITE, and wants > >> to use ICE, > >>>>>> wouldn't it be better for it to return an offer in a 1xx > >>>> rather than > >>>>>> a 200, in order to sidestep this issue? > >>>>>> > >>>>>> Paul > >>>>>> > >>>>>> Gonzalo Camarillo wrote: > >>>>>> > Hi, > >>>>>> > > >>>>>> >> With respect your proposal to delay the ACK with the > >>>> SDP answer... > >>>>>> >> Isn't it so that delaying the ACK will generate > >>>> retransmissions > >>>>>> of >> the 200 OK response? I think we need to be careful > >>>> with this > >>>>>>>> behavior. Is it possible to generate the ACK with the > >>>> SDP answer, > >>>>>>>> gather the candidate addresses, and then do a=20 > re-INVITE with an > >>>>>> SDP >> offer? > >>>>>> > > >>>>>> > the way it is usually specified (e.g., in 3pcc or session > >>>>>> policies) is > that we recommend to, in principle, > >> delay the ACK > >>>>>> because the operation > that needs to be done between the > >>>> 200 OK and > >>>>>> the ACK usually completes > very quickly. However, > >>>> endpoints need to > >>>>>> also be prepared for that > operation not to complete so > >>>> quickly. In > >>>>>> such a case, the endpoint needs > to send the ACK with > >> as good an > >>>>>> answer it can generate and UPDATE or > re-INVITE at a > >>>> later point, > >>>>>> as you suggested. > >>>>>> > > >>>>>> > Cheers, > >>>>>> > > >>>>>> > Gonzalo > >>>>>> > > >>>>>> > _______________________________________________ > >>>>>> > mmusic mailing list > >>>>>> > mmusic@ietf.org > >>>>>> > https://www1.ietf.org/mailman/listinfo/mmusic > >>>>>> > > >>>>>> > >>>> _______________________________________________ > >>>> mmusic mailing list > >>>> mmusic@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mmusic > >>>> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 16:53:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2E2k-0000QI-Jk; Wed, 03 Jan 2007 16:53:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2E2h-0000Oh-Vy for mmusic@ietf.org; Wed, 03 Jan 2007 16:53:04 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2E2f-0008NT-Hz for mmusic@ietf.org; Wed, 03 Jan 2007 16:53:03 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 03 Jan 2007 13:53:01 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l03Lr0WX022724; Wed, 3 Jan 2007 13:53:00 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l03Lqdln005308; Wed, 3 Jan 2007 13:53:00 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 13:52:47 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 13:52:46 -0800 Message-ID: <459C25AD.5080108@cisco.com> Date: Wed, 03 Jan 2007 16:52:45 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE References: <6FC4416DDE56C44DA0AEE67BC7CA43711213EA05@zrc2hxm2.corp.nortel.com> <459C0020.4070101@cisco.com> In-Reply-To: <459C0020.4070101@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jan 2007 21:52:46.0807 (UTC) FILETIME=[81306E70:01C72F81] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1894; t=1167861180; x=1168725180; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Offer=20in=20a=20200=20(OK)=20and=20ICE |Sender:=20; bh=R+zrcld+cBr5uLjn9MpbHVTPt0yj2THxX+zpxaIBT7I=; b=dzGBU7WRdij27DprqCqiKDdBcfo9OgdZKmNbR6ZUTBZDk3s0XUM/h5CD6o2hbeDpqUAWw4ge y6gCoypZWMWI5DDe/czMjlwjrVwaSmZTHA6zpPgDdqHnDlvcEw8eywFG; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Miguel Garcia , "Christer Holmberg \(JO/LMF\)" , mmusic , "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Paul Kyzivat wrote: > I just went back and reviewed this thread because its continued over a > long time. It appears that everybody is pretty much agreeing on the > general principles. Namely that if you are using ICE then you need to > deliver the initial offer, with ICE, reliably *before* the 200. I think of that as a best practice, not as a requirement. In the same way a 'regular' ICE flow can have the answer in a 18x or 2xx, but 18x is the best practice. ICE will work if the offer comes in the 2xx. The time required to perform the gathering steps (required prior to sending an ACK) is still relatively small compared to the retransmit intervals. I expect it would be completed well within 500ms, and thus there would be no spurious retransmits in most cases. The bigger problem is cases where the ACK is being delayed pending *human* interactions, since these are much slower. This is not such a case. You do have the real drawback of ringing the phone prior to verifying connectivity with ICE, but as in the normal case, thats a best practice and not a requirement. > > I don't think UPDATE will work here, because I don't think it is > appropriate to use UPDATE for the first offer, before any other offer > has been sent in the invite dialog usage. (I guess this is debatable, > but it isn't permitted according to the agreements codified in the > offeranswer draft.) > > If the UAC doesn't provide an offer and doesn't support PRACK then I > think the UAS simply can't use ICE. If that means it must reject the > call then so be it. No, I think it can use ICE - it just places the offer in the 2xx. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 17:01:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EAN-0006Nc-Ai; Wed, 03 Jan 2007 17:00:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EAL-0006Lp-IO for mmusic@ietf.org; Wed, 03 Jan 2007 17:00:57 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2EAK-0002Pa-7a for mmusic@ietf.org; Wed, 03 Jan 2007 17:00:57 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l03M0pD04422; Wed, 3 Jan 2007 17:00:51 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Wed, 3 Jan 2007 16:00:42 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371121AF0CD@zrc2hxm2.corp.nortel.com> In-Reply-To: <459C25AD.5080108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: AccvgYwwcJTWylm7Sh6HQcvQoLoGTQAAMPwA From: "Brian Stucker" To: "Jonathan Rosenberg" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Miguel Garcia , "Christer Holmberg \(JO/LMF\)" , mmusic , "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I'm not worried about the spurious retransmissions, but the cruddy user experience in general that slow-start frequently offers, which would be exacerbated by the client doing any additional processing (in this case, ICE) that is going to delay the response to the answer. Then again, I just don't like the call flow at all in the first place, ICE or not. I think ICE will work on a 200 OK SDP offer, but why would you want to do it in the first place. Yuck. Brian=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, January 03, 2007 3:53 PM > To: Paul Kyzivat > Cc: Stucker, Brian (RICH1:AR00); Miguel Garcia; mmusic;=20 > Gonzalo Camarillo (JO/LMF); Christer Holmberg (JO/LMF) > Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >=20 >=20 >=20 > Paul Kyzivat wrote: >=20 > > I just went back and reviewed this thread because its=20 > continued over a=20 > > long time. It appears that everybody is pretty much agreeing on the=20 > > general principles. Namely that if you are using ICE then=20 > you need to=20 > > deliver the initial offer, with ICE, reliably *before* the 200. >=20 > I think of that as a best practice, not as a requirement. In=20 > the same way a 'regular' ICE flow can have the answer in a=20 > 18x or 2xx, but 18x is the best practice. >=20 > ICE will work if the offer comes in the 2xx. The time=20 > required to perform the gathering steps (required prior to=20 > sending an ACK) is still relatively small compared to the=20 > retransmit intervals. I expect it would be completed well=20 > within 500ms, and thus there would be no spurious retransmits=20 > in most cases. The bigger problem is cases where the ACK is=20 > being delayed pending *human* interactions, since these are=20 > much slower.=20 > This is not such a case. >=20 > You do have the real drawback of ringing the phone prior to=20 > verifying connectivity with ICE, but as in the normal case,=20 > thats a best practice and not a requirement. >=20 >=20 >=20 > >=20 > > I don't think UPDATE will work here, because I don't think it is=20 > > appropriate to use UPDATE for the first offer, before any=20 > other offer=20 > > has been sent in the invite dialog usage. (I guess this is=20 > debatable,=20 > > but it isn't permitted according to the agreements codified in the=20 > > offeranswer draft.) > >=20 > > If the UAC doesn't provide an offer and doesn't support=20 > PRACK then I=20 > > think the UAS simply can't use ICE. If that means it must=20 > reject the=20 > > call then so be it. >=20 > No, I think it can use ICE - it just places the offer in the 2xx. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 19:26:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2GQq-0000EN-3E; Wed, 03 Jan 2007 19:26:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2GQo-0000EF-OU for mmusic@ietf.org; Wed, 03 Jan 2007 19:26:06 -0500 Received: from jor-el.real.com ([207.188.23.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2GQn-0006z7-BF for mmusic@ietf.org; Wed, 03 Jan 2007 19:26:06 -0500 Received: from [172.23.147.119] ([::ffff:172.23.147.119]) (AUTH: PLAIN jgordon, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by jor-el.real.com with esmtp; Wed, 03 Jan 2007 16:25:55 -0800 id 000940A0.459C4993.00006181 Message-ID: <459C4999.5050106@real.com> Date: Wed, 03 Jan 2007 16:26:01 -0800 From: Jamie Gordon User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up session establishment References: <458ABFA6.8030107@ericsson.com> In-Reply-To: <458ABFA6.8030107@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Magnus Westerlund wrote: > > My proposal for this mechanism would be to add two new header: > Pipe-Hdr = "Pipe-Lined-Requests" HCOLON random-id > random-id = 12*(Digit / Alpha) > SeqNr = 1*DIGIT What is the purpose of the "SeqNr"? I don't see it described or used and don't see why it would be necessary. > The Pipe-Lined-Requests header is used to identify which requests that > shall be treated together and needs to be included in each request that > are pipe-lined within the same context. That way the server will when > handling the first one know that the context will need to be saved and > for how many future requests. The random-ID is one part of a mechanism > to avoid collisions between requests and allow multiple ongoing > pipelining sequences to happen at the same time. This is necessary to > allow for proxies to aggregate multiple interactions over the same > connection. The ID shall be freshly generated in a cryptographically > random way (RFC 4086) for each sequence of pipelined requests. This > intends to satisfy the requirement to have little risk of collision and > provide an identifier for binding the requests to the context being > generated. It should not be required to be random, this seems overly complex. A pipeline session initiation ID applies to exactly one session on one connection. A client controlling multiple sessions over the same RTSP control channel need only ensure that each session is given a different ID, it does not need to worry about conflicting with any others. A proxy aggregating requests for multiple clients over a single RTSP control channel will clearly need to be able to handle collisions and modify the IDs either way, there's not reason to add complexity to the client just so aggregating proxies have to exercise that code less frequently. > The server shall timeout the temporary context to prevent an attack > after 60 seconds. In case of someone attack the server by creating a > large number of contexts then the server can refuse to save the context > and instead provide an error message that the context is not available > for any request after the first one. However in this case the server is > more likely to run out of room for session states anyway. This seems again to be going overboard. It's just an ID, it shouldn't really create anything and be used to attack the server. The ID doesn't' create a session or anything, the SETUP does. An attempt to initiate a pipelining ID with a method that does not initiate a session would just fail, it should not create a session on the server. And attempts to attack a server via repeated SETUPs is not unique to setups using this ID. It identifies a single session on a single connection and therefore stops being valid if either the RTSP connection is closed or the Session ends. It could also considered removed/no longer valid once a request has been received on the session using the actual server generated session ID, as any subsequent message clearly also can contain the session ID. Sessions should be timed out in the normal manner at the server's discretion, there should be no need to define a separate time-out. Thanks, Jamie Gordon A new error > code is defined to inform the requesting entity about when the requested > temporary ID is not available. In case this happens the client will only > have lost one round trip time as the first request in the series will > have created a session if successful. Thus any subsequent requests can > use the created session context rather than the temporarily bound by the > random-id. > > The extra context the server needs to keep is small. A simple mapping > table between the temporary one and the created session ID and with an > creation time to allow for expiring the entry. The first request in the > pipelining series SHALL be one that creates a session context, i.e. a > SETUP request. Any of the methods SETUP, PLAY, OPTIONS, SET_PARAMETER, > GET_PARAMETER, TEARDOWN and PAUSE are allowed to be used as requests > subsequent the first one. > > Proxies may add, modify or delete the Pipe-Lined-Requests header. > > Please be aware that this pipelining mechanism will result in that all > the requests that are successful will build on the session context. > While any failed ones will not directly influence the subsequent > requests. Thus if a pipelining consists of SETUP, SETUP and then PLAY > then if one of the SETUP fails and the PLAY is successful then the > server will play out the session with a single media. A more advance > mechanism could be defined that put requirements on previous requests to > be successful can be designed but doesn't seem motivated. Because if > some request fails the client can stop the playback, and the go back and > correct the failed requests. This cost seems little compared to the > complexity a more advanced mechanism would create. It is also inline > with previous designs that is optimized for the case when everything > works and only in cases there are some troubles will introduce extra delay. > > Feedback is solicited. > > Cheers > > Magnus Westerlund _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 20:20:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HHO-0004ES-H6; Wed, 03 Jan 2007 20:20:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HHN-0004EL-Hy for mmusic@ietf.org; Wed, 03 Jan 2007 20:20:25 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HHM-0006kM-5l for mmusic@ietf.org; Wed, 03 Jan 2007 20:20:25 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2007 17:20:23 -0800 X-IronPort-AV: i="4.12,234,1165219200"; d="scan'208"; a="454996281:sNHT47625274" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l041KNFv026140 for ; Wed, 3 Jan 2007 17:20:23 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l041KN04028768 for ; Wed, 3 Jan 2007 17:20:23 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 17:20:23 -0800 Received: from [10.21.154.108] ([10.21.154.108]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 17:20:23 -0800 Message-ID: <459C5656.2020905@cisco.com> Date: Wed, 03 Jan 2007 20:20:22 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mark Baugher Subject: Re: [MMUSIC] SDP Capability Negotiation: Solution Document References: <459AA849.6080308@cisco.com> <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> In-Reply-To: <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2007 01:20:23.0241 (UTC) FILETIME=[81CD6B90:01C72F9E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3123; t=1167873623; x=1168737623; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Soluti on=20Document |Sender:=20; bh=zynOH2kDt2r25IgvDvYMFiQCE6JjtH9BiNIq+9tna/k=; b=m604II1asByqg65+DsWyzGgpomNH+0lX+kzvbdhq0WpMrrHxhRRwWFSY48ELPEhTUGY87vKm MNOWjF5XSxcxpRHGeMgCqNhWksTVG/cqY5xjSrnm2aG7ZlbjvVlzLA3n; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Mark Baugher wrote: > Flemming, > >> ... Another issue here is that >> payload type numbers, which really have only media-level >> scope, are >> ill-suited to be used at the session-level or across >> multiple media >> streams (as is being done here). However, an alternative >> (and more >> proper) solution seems to involve significantly more work and >> deviations from the current SDP framework. This in turn >> makes it >> more difficult to automatically use new media types, formats, >> protocols, etc. defined elsewhere within this framework, >> and that >> is a major disadvantage. Another option is to forgo the >> session- >> level media capabilities as well as the ability to >> reference across >> media streams - it will make the solution less efficient >> though and >> difficult to express latent capabilities for media streams not >> included in the offer or answer.] > > It is noted in a few places in your document that session-level > scoping of the attributes are in certain cases confusing or not > suitable. I recall going through the exercise of trying to put > security descriptions at the session level and deciding that it added > too much complexity. Is there a compelling need to even have a > session-level scope for your attributes? It's really driven by two things: 1. A desire to provide a more compact overall encoding. By listing capabilities only once and them referencing some of them in potential configurations in more than one "m=" line (typically of the same type, e.g. "audio"), we cut down on the overall message size. 2. We currently have a requirement to express latent capabilities for media streams that are not part of the offer (or answer). This requires a listing of media capabilities at the session level. -- Flemming > > Mark > > On Jan 2, 2007, at 10:45 AM, Flemming Andreasen wrote: > >> Greetings >> >> Based on our updated requirements for SDP capability negotiation, I >> have just submitted an updated solution document as >> draft-ietf-mmusic-sdp-capability-negotiation-00.txt, which you can >> retrieve from >> http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-00.txt >> until it appears in the archives. >> >> We will discuss this document on our next SDP Capability Negotiation >> design team call (1/9/07). Note that there are some open issues in >> the document currently (look for "Editor's note"), in particular in >> the area of supporting media capabilities at both the session level >> and the media level, which is not terribly elegant or even clear in >> the current document. Comments, suggestions, and other feedback on >> this as well as the rest of the document is hereby solicited. >> >> Thanks >> >> -- Flemming >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 20:22:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HJU-0005uX-NL; Wed, 03 Jan 2007 20:22:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HJT-0005sf-N2 for mmusic@ietf.org; Wed, 03 Jan 2007 20:22:35 -0500 Received: from cir-el.real.com ([207.188.23.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HJS-00074k-Te for mmusic@ietf.org; Wed, 03 Jan 2007 20:22:35 -0500 Received: from m24947 ([::ffff:192.168.129.141]) (AUTH: LOGIN csteck, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cir-el.real.com with esmtp; Wed, 03 Jan 2007 17:22:27 -0800 id 0020807B.459C56D3.00002A6C From: "Chris Steck" To: "'Magnus Westerlund'" , "'mmusic \(E-mail\)'" Subject: RE: [MMUSIC] RTSP: Improved pipelining to speed up session establishment Date: Wed, 3 Jan 2007 17:22:33 -0800 Message-ID: <001401c72f9e$cf783b90$8d81a8c0@m24947> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcclI2+dRbPKj4s0SaqpdzukSEYxOwKdmgSQ In-Reply-To: <458ABFA6.8030107@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Is there any reason MMUSIC can't define the pipelining mechanism so it can be backported to work with RTSP 1.0 as well? We would like to leverage pipelining in 3GPP Rel 7 PSSe work, but are reluctant to have a dependency on RTSP 2.0. It would be great if this proposal could account for this backport so that there is no need to extract pipelining from RTSP 2.0 to define a superset of 1.0 in SA4, where we reference the pipelining section of 2.0, as we all know how those things tend to fall out of sync easily. -Chris Chris Steck Director of Technology Strategy Technology Products and Services RealNetworks 2601 Elliott Ave. Seattle, WA USA 98121 Tel: +1.206.892.6885 Mobile/SMS: +1.206.849.3898 Email: CSteck@real.com -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Thursday, December 21, 2006 9:09 AM To: mmusic (E-mail) Subject: [MMUSIC] RTSP: Improved pipelining to speed up session establishment Hi, This email discuss if we should add an additional mechanism to allow pipelining to a higher degree, thus allowing RTSP 2.0 to complete SETUP and start playing in a single RTT after the connection has been established. Currently RTSP 2.0 allows one to create an session and start it playing in two RTTs after connection establishment. The first to create a session and receive the session ID. The second RTT to setup any additional streams and start playing media. This is better than RTSP 1.0 with one RTT, for any session using aggregation to handle multiple media streams. There has been quite a lot of interest to improve the time it takes to do the setup and start playing media. I think there is interest to improve RTSP as far as possible. A reason for doing this is that TLS establishment will increase the delay and this allows to counter that effect to some degree. There is also a point in doing this to enable the NAT traversal to done fully in parallel as all media streams will be handled at the same time, instead of one stream first and then the remaining one RTT later. Below is an proposal on how this can be accomplished. Performing pipelining of one or more SETUP followed by a PLAY without receiving any answers. The basic idea is that we should enable a client to send all the SETUP requests and the PLAY to the server without receiving any response before the other messages could be sent. The main obstacle to this is the session ID. Normally the first SETUP creates the session and its ID. First after the client has received the servers response is it able to perform any subsequent SETUP to add media streams or start playing. Thus if solving this issue one need to add something that allows the server to determine that a number of subsequent request belongs together and the server should keep some context between these messages. The main issue with this is to avoid laying to much burden on the server and avoid creating a mechanism that allows a client to overload the server when using this mechanism. My proposal for this mechanism would be to add two new header: Pipe-Hdr = "Pipe-Lined-Requests" HCOLON random-id random-id = 12*(Digit / Alpha) SeqNr = 1*DIGIT The Pipe-Lined-Requests header is used to identify which requests that shall be treated together and needs to be included in each request that are pipe-lined within the same context. That way the server will when handling the first one know that the context will need to be saved and for how many future requests. The random-ID is one part of a mechanism to avoid collisions between requests and allow multiple ongoing pipelining sequences to happen at the same time. This is necessary to allow for proxies to aggregate multiple interactions over the same connection. The ID shall be freshly generated in a cryptographically random way (RFC 4086) for each sequence of pipelined requests. This intends to satisfy the requirement to have little risk of collision and provide an identifier for binding the requests to the context being generated. The server shall timeout the temporary context to prevent an attack after 60 seconds. In case of someone attack the server by creating a large number of contexts then the server can refuse to save the context and instead provide an error message that the context is not available for any request after the first one. However in this case the server is more likely to run out of room for session states anyway. A new error code is defined to inform the requesting entity about when the requested temporary ID is not available. In case this happens the client will only have lost one round trip time as the first request in the series will have created a session if successful. Thus any subsequent requests can use the created session context rather than the temporarily bound by the random-id. The extra context the server needs to keep is small. A simple mapping table between the temporary one and the created session ID and with an creation time to allow for expiring the entry. The first request in the pipelining series SHALL be one that creates a session context, i.e. a SETUP request. Any of the methods SETUP, PLAY, OPTIONS, SET_PARAMETER, GET_PARAMETER, TEARDOWN and PAUSE are allowed to be used as requests subsequent the first one. Proxies may add, modify or delete the Pipe-Lined-Requests header. Please be aware that this pipelining mechanism will result in that all the requests that are successful will build on the session context. While any failed ones will not directly influence the subsequent requests. Thus if a pipelining consists of SETUP, SETUP and then PLAY then if one of the SETUP fails and the PLAY is successful then the server will play out the session with a single media. A more advance mechanism could be defined that put requirements on previous requests to be successful can be designed but doesn't seem motivated. Because if some request fails the client can stop the playback, and the go back and correct the failed requests. This cost seems little compared to the complexity a more advanced mechanism would create. It is also inline with previous designs that is optimized for the case when everything works and only in cases there are some troubles will introduce extra delay. Feedback is solicited. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 03 20:33:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HTg-0004jI-EG; Wed, 03 Jan 2007 20:33:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2HTf-0004jC-G9 for mmusic@ietf.org; Wed, 03 Jan 2007 20:33:07 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2HTe-0000AG-1I for mmusic@ietf.org; Wed, 03 Jan 2007 20:33:07 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Jan 2007 17:33:05 -0800 X-IronPort-AV: i="4.12,234,1165219200"; d="scan'208"; a="454997266:sNHT150730728" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l041X5R4020917 for ; Wed, 3 Jan 2007 17:33:05 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l041X4ZH015351 for ; Wed, 3 Jan 2007 17:33:04 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 17:33:04 -0800 Received: from [10.21.154.108] ([10.21.154.108]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 17:33:04 -0800 Message-ID: <459C5950.7000200@cisco.com> Date: Wed, 03 Jan 2007 20:33:04 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] SDP Capability Negotiation: Solution Document References: <459AA849.6080308@cisco.com> <61BBE203-048A-49B1-9B94-0B70FBD94CD9@cisco.com> <459BCEA4.4030501@cisco.com> <217F5F04-68FB-4EE2-B487-99595E761170@cisco.com> <459C0A3F.9050603@cisco.com> In-Reply-To: <459C0A3F.9050603@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2007 01:33:04.0603 (UTC) FILETIME=[479C0AB0:01C72FA0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4203; t=1167874385; x=1168738385; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Soluti on=20Document |Sender:=20; bh=DCub87i0Cvft6Z27edTMfNEWE11GWEt32dhDpenwFuE=; b=I408ViGeWuZletTiD3gWjPagT9MlvnAS5/onUh9tkgS79OCtu/M7HLxNnqe6wZ3xbgmvIYSO bvAVDkYux3W/KlgoCmDhktVpsD5ZKLKw7jUjPMampwYEAk5brVxblQpG; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Mark Baugher , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Paul Kyzivat wrote: > > > Mark Baugher wrote: >> I did not say anything about banning session-level attributes. You >> should read my note again. > > Sorry, I guess I wasn't clear. You seem to be recommending that in > some cases it might not be feasible or worth the trouble to define a > session level attribute - that the attribute could instead be defined > only for media level. > > My point is that I don't understand why it is ever necessary to > specify that an attribute be usable only at media level. (Though RFC > 4566 defines several that are.) The real issue is to identify those > cases where the same attribute definition cannot meaningfully appear > in more than one media field - either by being repeated or by by being > defaulted into more than one media field from session level. > > For example, a=rtpmap is defined as only media level, but it could be > quite useful in some cases to use it as a session level attribute. > E.g. (some lines omitted) > > m=audio 49001 RTP/AVP 96 97 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > m=audio 49002 RTP/AVP 96 97 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > > could be written as follows if a=rtpmap were allowed as a session > level attribute: > > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > m=audio 49001 RTP/AVP 96 97 > m=audio 49002 RTP/AVP 96 97 The problem with that particular approach is that RTP payload types apply to individual media streams and hence e.g. payload type 96 can be mapped to different codecs in different media streams. Once you start using it at the session level, you need at a minimum to require uniqueness at the session level (i.e. across media stream types), which may not get you as far as you want considering the limited payload number space. You also have to consider how to handle overlap between payload type numbers provided at the session and media level. Add "rtpmap" and "fmtp" attributes, both of which are linked to a payload type number, and the situation quickly becomes less than clear. The whole thing is further complicated by the fact that the interpretation of (payload type in this case) part of the "m=" line depends on the (RTP/AVP in this case). For example, I can specify m=image 49001 tcp t38 which clearly is unambiguous because I actually use proper MIME type and subtype and hence does not suffer the problem that payload types does. Take a look at MSRP instead, and you get something like m=message 7654 TCP/MSRP * which is yet another variant on the whole scheme. > > Even in cases where the same attribute value doesn't make sense in > multiple media fields, there would be no real harm in allowing the > attribute at session level. For example, the following would be > equivalent: > > m=audio 49001 RTP/AVP 96 97 > a=label:english > m=audio 49002 RTP/AVP 96 97 > a=label:spanish > > a=label:english > m=audio 49001 RTP/AVP 96 97 > m=audio 49002 RTP/AVP 96 97 > a=label:spanish I'm not sure those are semantically equivalent per RFC 4566, but I understand your point (having session level attributes apply as defaults at the media level). > > Conversely the following both have the same nonsensical meaning: > > m=audio 49001 RTP/AVP 96 97 > a=label:english > m=audio 49002 RTP/AVP 96 97 > a=label:english > > a=label:english > m=audio 49001 RTP/AVP 96 97 > m=audio 49002 RTP/AVP 96 97 Depends on what those two audio streams are for, but again I understand your point. > > Its too late now to state that existing attribute definitions that > specified to be only media level, for reasons of backward > compatibility. But I think it would make sense to stop defining *new* > attributes that are only valid at media level. I'm not so sure about that. It depends on the attribute in question. -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 04 13:09:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X0x-0004nB-W3; Thu, 04 Jan 2007 13:08:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X0w-0004lp-06 for mmusic@ietf.org; Thu, 04 Jan 2007 13:08:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2X0s-0004fy-KS for mmusic@ietf.org; Thu, 04 Jan 2007 13:08:29 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2007 10:08:25 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l04I8QNg029091; Thu, 4 Jan 2007 10:08:26 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l04I8Plb002613; Thu, 4 Jan 2007 10:08:25 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 10:08:25 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 10:08:25 -0800 Message-ID: <459D4297.8080208@cisco.com> Date: Thu, 04 Jan 2007 13:08:23 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Stucker Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE References: <6FC4416DDE56C44DA0AEE67BC7CA43711213ECEC@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711213ECEC@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2007 18:08:25.0249 (UTC) FILETIME=[53E37110:01C7302B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1791; t=1167934106; x=1168798106; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Offer=20in=20a=20200=20(OK)=20and=20ICE |Sender:=20; bh=b0CCD282aazjeCI8ZluqjLXu0W6qpELr5qEqc1UeEng=; b=MIowBsp3QAJn7aWd2y0JarpUNcmA+Zinv52aPJum+wXb8hujd/mX/2M6sPJS8b3bV6xKGkT3 ZhZBFZWkg34rY9IQ7y5MhG8vZ5/Os/qzyK82V0/oGro0OFa5xlmOGX0L; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Miguel Garcia , Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" , mmusic , "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Brian Stucker wrote: > Yeah, you're right, but I don't see why an INVITE with no SDP > effectively seems to constitute an offer. It doesn't. I don't know what you mean here. > > I looked through the cases in RFC-3311 for the callee to send an UPDATE > and it's not allowed unless an OFFER/ANSWER exchange completed via a > reliable 18x/PRACK. Right. > > Can someone enlighten me as to why UPDATE isn't equally acceptable for > transporting an SDP offer as reliable 18x/PRACK? Well, you really need the reliable 18x to establish a dialog. If you send the UPDATE prior to a 18x, then the UPDATE would establish the dialog. You would need to have it carry the record-route, and all kinds of awful things. A better alternative would be to have a 18x/PRACK without an offer/answer exchange, followed by an UPDATE from callee to caller at some point in time. I can't think of a reason that wouldn't work, except that RFC 3261 is pretty clear that the offer is supposed to come in the first reliable response. So, omitting one in the 18x would probably seriously confuse most implementations. So, net/net is, I don't really see why we need to do anything new here. I think its fine for ICE to specify the two flows for offerless INVITE, one with the offer in a reliable 18x, and the other in a 2xx. The former will require PRACK, the latter worsens the user experience but will otherwise work. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 04 13:12:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X4j-0007IN-Lu; Thu, 04 Jan 2007 13:12:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2X4h-0007E8-PV for mmusic@ietf.org; Thu, 04 Jan 2007 13:12:23 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2X4g-0005fG-F5 for mmusic@ietf.org; Thu, 04 Jan 2007 13:12:23 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l04I4l202910; Thu, 4 Jan 2007 13:04:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Thu, 4 Jan 2007 12:12:16 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371121AF7BB@zrc2hxm2.corp.nortel.com> In-Reply-To: <459D4297.8080208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: AccwK1i9+PNYS7btT7uwesXa9FPPBgAAHIkA From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Miguel Garcia , Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" , mmusic , "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I agree that it'll work. Just ugly. Regards, Brian=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, January 04, 2007 12:08 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Paul Kyzivat; Miguel Garcia; mmusic; Gonzalo Camarillo=20 > (JO/LMF); Christer Holmberg (JO/LMF) > Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >=20 >=20 >=20 > Brian Stucker wrote: >=20 > > Yeah, you're right, but I don't see why an INVITE with no SDP=20 > > effectively seems to constitute an offer. >=20 > It doesn't. I don't know what you mean here. >=20 > >=20 > > I looked through the cases in RFC-3311 for the callee to send an=20 > > UPDATE and it's not allowed unless an OFFER/ANSWER exchange=20 > completed=20 > > via a reliable 18x/PRACK. >=20 > Right. >=20 > >=20 > > Can someone enlighten me as to why UPDATE isn't equally=20 > acceptable for=20 > > transporting an SDP offer as reliable 18x/PRACK? >=20 > Well, you really need the reliable 18x to establish a dialog.=20 > If you send the UPDATE prior to a 18x, then the UPDATE would=20 > establish the dialog. You would need to have it carry the=20 > record-route, and all kinds of awful things. A better=20 > alternative would be to have a 18x/PRACK without an=20 > offer/answer exchange, followed by an UPDATE from callee to=20 > caller at some point in time. I can't think of a reason that=20 > wouldn't work, except that RFC 3261 is pretty clear that the=20 > offer is supposed to come in the first reliable response. So,=20 > omitting one in the 18x would probably seriously confuse most=20 > implementations. >=20 > So, net/net is, I don't really see why we need to do anything=20 > new here.=20 > I think its fine for ICE to specify the two flows for=20 > offerless INVITE, one with the offer in a reliable 18x, and=20 > the other in a 2xx. The former will require PRACK, the latter=20 > worsens the user experience but will otherwise work. >=20 > -Jonathan R. >=20 >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 04 14:02:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Xrd-0005VG-9b; Thu, 04 Jan 2007 14:02:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Xrc-0005VB-Oq for mmusic@ietf.org; Thu, 04 Jan 2007 14:02:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Xrb-0005lV-1C for mmusic@ietf.org; Thu, 04 Jan 2007 14:02:56 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 04 Jan 2007 11:02:54 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l04J2sse004389; Thu, 4 Jan 2007 11:02:54 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l04J2QJL008032; Thu, 4 Jan 2007 11:02:54 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:02:45 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:02:45 -0800 Message-ID: <459D4F54.6030305@cisco.com> Date: Thu, 04 Jan 2007 14:02:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo References: <458263F0.4050206@ericsson.com> In-Reply-To: <458263F0.4050206@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2007 19:02:45.0154 (UTC) FILETIME=[EAF17820:01C73032] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1890; t=1167937374; x=1168801374; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Comment=20on=20TCP=20ICE |Sender:=20; bh=h+QbtWKGkapqjENstqUIIc7lBtTIZcccVyZF7A3AlSA=; b=nU1FWzAmfxpjPjWdxiEQxSRC7e93vGENxagM0Q4XMZaG5Zchv8oUTDZ0wOPgG4dgUn3eLXpC ud1HRqSHsFGp6MtihGa+FNo6yr4JHD3L1EV50XcWAOYi8PZ+VYsIb2BB; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mmusic Subject: [MMUSIC] Re: Comment on TCP ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Sorry for the long delay in responding to all of these. I am finally getting back to work on this after a work-based hiatus. inline. Gonzalo Camarillo wrote: > Hi, > > the TCP ICE spec changes the way TCP connection reestablishment works in > RFC 4145. RFC 4145 allows applications to close a TCP connection without > requiring a new offer/answer exchange. However, a new offer/answer > exchange is required to reestablish (i.e., repair) a connection. > > TCP ICE, on the other hand, requires a new offer/answer exchange to > close a TCP connection, but does not require it to repair a connection. It is not the intent that a new exchange is required to close a connection. The intention is that once a connection is up and in use for media, it will stay up and should not normally be closed. However, if the client needs to close it, or it closes due to some temporary glitch, thats fine - no new o/a exchange is needed to reopen one. The only case in which you would normally close a connection is when a media stream ends, which does require a new O/A exchange. > > The ICE TCP spec says: > > "Unlike RFC 4145, additional signaling is not required to repair a > closed connection." > > I believe that the ICE TCP spec needs to give a slightly longer > explanation about it so that implementers understand both differences. > Maybe an extra paragraph along the lines of this email. I think clearly explanation is needed. If the above sounds OK to you, I will add text clarifying that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 04 14:06:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Xv1-0008KP-Vz; Thu, 04 Jan 2007 14:06:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Xv0-0008KD-5O for mmusic@ietf.org; Thu, 04 Jan 2007 14:06:26 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Xuy-0006QI-Qt for mmusic@ietf.org; Thu, 04 Jan 2007 14:06:26 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2007 11:06:23 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l04J6NBC005127; Thu, 4 Jan 2007 11:06:23 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l04J5mJ7016004; Thu, 4 Jan 2007 11:06:23 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:06:19 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 11:06:19 -0800 Message-ID: <459D502A.5040104@cisco.com> Date: Thu, 04 Jan 2007 14:06:18 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo References: <4581A5E9.3040801@ericsson.com> In-Reply-To: <4581A5E9.3040801@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2007 19:06:19.0282 (UTC) FILETIME=[6A92CF20:01C73033] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1963; t=1167937583; x=1168801583; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Passive=20and=20passive-only=20terminology=20in=20ICE |Sender:=20; bh=NitA5YK6v2oQpaF/bKl486CCV5B/+gvpaayA29xXS60=; b=Cgw44iZl9VLek6BTvkQ4fMWKcLDKFXgK/kZVCJv1e7vOSQpchPcvBcZ5tU3KrC7w0ekk65ba ocv3LgXrcCUWpOnm601pkAxIHBqQ+ZLvwI+OZQsEelFXsdRoYT1C5MSn; Authentication-Results: sj-dkim-7; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mmusic Subject: [MMUSIC] Re: Passive and passive-only terminology in ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org We had a separate thread on this. We agreed to change the terminology to the following. There are two different types of implementations: passive-only and full. A full implementation can operate in one of two modes - controlling or controlled. A passive-only operates in only one mode - passive. In passive mode, no triggered or periodic checks are sent. However, both are sent in controlled mode. One wrinkle I ran into is that there is also a minor variation in the controlling mode. If an agent is controlling, and its peer is in passive mode, its behavior is slightly different than when its controlling and its peer is controlled. Namely, it cannot use the done flag in a stun transaction on a pair which hasn't completed succesfully yet. It will also see incoming stun requests. I debated whether to describe this as a different mode, but I think its close enough that it doesn't warrant it. Rather I'll describe this exception as part of the desription of the controlling mode operation. Thanks, Jonathan R. Gonzalo Camarillo wrote: > Hi, > > a passive agent (as opposed to a controlling agent) generates periodic > connectivity checks. However, a passive-only agent does not (need to) > generate them. > > Using the same terminology for both (i.e., passive) may be confusing. It > may lead some readers to think that passive agents do not perform > periodic checks, for instance. > > This is no big deal, but if somebody else agrees that this may be > confusing, we could think of using a different term for one of those > concepts. > > Cheers, > > Gonzalo > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 04 17:24:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2b0V-0007e8-41; Thu, 04 Jan 2007 17:24:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2b0T-0007d5-Pi for mmusic@ietf.org; Thu, 04 Jan 2007 17:24:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2b0R-0001de-AT for mmusic@ietf.org; Thu, 04 Jan 2007 17:24:17 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2007 14:24:15 -0800 X-IronPort-AV: i="4.12,240,1165219200"; d="scan'208"; a="455254086:sNHT57576742" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l04MOEnW005834; Thu, 4 Jan 2007 14:24:14 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l04MO4ZT004946; Thu, 4 Jan 2007 14:24:11 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 14:24:10 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 14:24:09 -0800 Message-ID: <459D7E88.2010306@cisco.com> Date: Thu, 04 Jan 2007 17:24:08 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <45766E40.40306@ericsson.com> <4576D63B.1080203@lucent.com> In-Reply-To: <4576D63B.1080203@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2007 22:24:10.0103 (UTC) FILETIME=[0E225870:01C7304F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3830; t=1167949454; x=1168813454; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20ICE=20and=20IPv6=20transition |Sender:=20; bh=vho9wmIn5GuBJWg2ix5xrkfRmb8Gmfr3wQHdF5yq3P4=; b=uQZG/UjhakUlVGsaj7cjk/VQ00R2lPyeT6FUEPKNXbJk68fktr5l8ORUyPBccD3qWwn1tkSw sQUNshsxuPX/Sn+4mWh5dpKym4DJ2/5PuiUTSrF2teKEcG0uA/CwnDJX; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Gonzalo Camarillo , mmusic Subject: [MMUSIC] Re: ICE and IPv6 transition X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Here are my thoughts on this. I recall discussing this issue way back when with Gonzalo. We had agreed that ANAT would be complementary to ICE. ANAT would be used in cases where you were multihomed with v4 and v6, and not worrying about NAT traversal per se. ICE added a lot of complexity just to deal with something as simple as picking the right IP version. Also, ICE had the problem that it had one address as the primary (in the m/c-line) and the other candidates were secondary, in candidate lines. We wanted a solution where both addresses were really equivalently treated. Under these assumptions, you would use ANAT when you had both v4 and v6 public addresses, but public versions of both. If you needed NAT traversal, you'd use ICE. If you had both v4 and v6 and needed nat traversal, you'd use both ANAT and ICE. There'd be an m line for v4, one for v6. ANAT would select which. Then, under the v4 m-line, you'd have all of your v4 candidates. Under the v6 m-line, all of your v6. Thats why the ICE spec talks about using ICE to select between native v6 and 6to4 addresses, for example. However, a few things have changed since we originally made that decision. Firstly, we've seen that even in the absence of NAT traversal, ICE is valuable (passive mode, voice hammer prevention, keepalive timing control). Furthermore, ICE's design now treats the m/c-line address as a fallback for non-ICE endpoints. We also now have an option tag, so you could use ICE like ANAT gets used; with an option tag so you can do something different if the far end doesn't support it. Another point is, one of the benefits of ICE over ANAT for selection of v4 vs. v6 is that, you may run into scenarios where both side have v6 but they turn out to be unconnected; that is, its two phones both sitting on v6 networks that are not connected together. I don't know how common it is to have v6 islands unconnected, but it would not surprise me if this happens every once in a while. So, technically, at this point I think ICE is probably able to provide a superset of ANAT. One option is to recommend ANAT for the simplest case (no NAT traversal, dual-homed clients with public IP), and then ICE for anything more. THe problem with that is, from an interop standpoint, ICE implementations would also need to do ANAT and it would be more complicated. Plus, having ICE support on devices that aren't interested in nat traversal per se is critical for allowing the OTHER side to support nat traversal (this is why we've been pushing passive mode). I also suspect it will generally be confusing to the industry to have two specifications that are very similar. So, my recommendation would be to have ICE obsolete ANAT when its published. I don't know if its being used yet at all, which might make this an issue. Thoughts? -Jonathan R. > Gonzalo Camarillo wrote: > >> Hi, >> >> the current ICE draft seems to tackle IPv4 and IPv6 candidates for the >> same media stream. In the past, we developed ANAT to separate them so >> that a single m line used a single IP version. In particular, the >> SIPPING IPv6 transition document recommends the use of ANAT. >> >> We need to align all these efforts. > > > Probably sooner rather than later if it has any impact on > the SIPPING IPv6 transition draft, since it has already been WGLCd > and is in the "Publication Requested" state. > > Thanks, > > - vijay -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 05 00:44:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2hsJ-00080Y-Gg; Fri, 05 Jan 2007 00:44:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2hsI-0007xL-4k for mmusic@ietf.org; Fri, 05 Jan 2007 00:44:18 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2hsC-0003oZ-Ia for mmusic@ietf.org; Fri, 05 Jan 2007 00:44:18 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 72B1C4F0003; Fri, 5 Jan 2007 06:43:55 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 06:43:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Fri, 5 Jan 2007 06:43:54 +0100 Message-ID: <7374777208BDC7449D5620EF942325670143F53D@esealmw113.eemea.ericsson.se> In-Reply-To: <459D4297.8080208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: AccwK1bWYGwAUfWAQ6Wf4a2OWQlL9AAX/EtA From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" , "Brian Stucker" X-OriginalArrivalTime: 05 Jan 2007 05:43:55.0293 (UTC) FILETIME=[7CEED4D0:01C7308C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Miguel Garcia , Paul Kyzivat , mmusic , "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi,=20 >>Can someone enlighten me as to why UPDATE isn't equally acceptable for >>transporting an SDP offer as reliable 18x/PRACK? >=20 >Well, you really need the reliable 18x to establish a dialog.=20 I don't want to argue against you on that, but I HAVE heard opinions saying that you do not need a reliable response in order to establish a dialog. Also, chapter 12.1 of RFC3261 does say the following: "Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog." Note that the text only talks about non-failure responses (2xx and 101-199), not reliable responses (reliable provisional responses (101-199) are not even defined in 3261). >If you send the UPDATE prior to a 18x, then the UPDATE would=20 >establish the dialog. You would need to have it carry the=20 >record-route, and all kinds of awful things. Yes, and that is a good reason not to send UPDATE before you have sent a reliable response - at least not by the called party. But, one could claim that the early dialog may still be established before that. >A better alternative would be to have a 18x/PRACK without an=20 >offer/answer exchange, followed by an UPDATE from callee to=20 >caller at some point in time. I can't think of a reason that=20 >wouldn't work, except that RFC 3261 is pretty clear that the=20 >offer is supposed to come in the first reliable response. So,=20 >omitting one in the 18x would probably seriously confuse most=20 >implementations. This is related to the discussion about the MUST to send an offer in the first reliable 18x. It is listed as an issue in the offer/answer draft. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 05 09:52:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qQo-0006nV-US; Fri, 05 Jan 2007 09:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2qQn-0006lm-AE for mmusic@ietf.org; Fri, 05 Jan 2007 09:52:29 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2qQk-0008QE-P2 for mmusic@ietf.org; Fri, 05 Jan 2007 09:52:29 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2007 06:52:26 -0800 X-IronPort-AV: i="4.12,243,1165219200"; d="scan'208"; a="50067270:sNHT53933272" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l05EqQmM007128; Fri, 5 Jan 2007 09:52:26 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l05EqQ7f010740; Fri, 5 Jan 2007 09:52:26 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 09:52:26 -0500 Received: from [10.86.242.124] ([10.86.242.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 09:52:25 -0500 Message-ID: <459E6629.8060501@cisco.com> Date: Fri, 05 Jan 2007 09:52:25 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE References: <7374777208BDC7449D5620EF942325670143F53D@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670143F53D@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2007 14:52:25.0841 (UTC) FILETIME=[1D25EE10:01C730D9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2675; t=1168008746; x=1168872746; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20Offer=20in=20a=20200=20(OK)=20and=20ICE |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=I9OUw2MIxunDpHcYc23WpGlw0NgSjc0hhzitxRItQPo=; b=w4IYiZ/iQvotso8nVCmI8E46YHKOEheorUMvFkDSIahJw5Lt3DP0x7i1rac5IqWluG2uDxcc RHBBGCZXAeOVssm6HssgrJjn6PXOm/7+ifk9jyxbHcxKE4nJtRjNUG5F; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Miguel Garcia , "Gonzalo Camarillo \(JO/LMF\)" , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Christer, A non-reliable response *can* establish a dialog - *if* it is received by the UAC. In that case the UAC knows a dialog has been established, but the UAS does not. So, if a UAC receives an unreliable provisional that contains a tag it could potentially then send an UPDATE within that dialog. But when the UAS sends that unreliable provisional, since it doesn't know for sure that a dialog has been established, it can't yet send an UPDATE. If it did send one, and the provisional had been lost, then the UAC would not be able to associate the UPDATE with a dialog, and it would fail. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > >>> Can someone enlighten me as to why UPDATE isn't equally acceptable for > >>> transporting an SDP offer as reliable 18x/PRACK? >> Well, you really need the reliable 18x to establish a dialog. > > I don't want to argue against you on that, but I HAVE heard opinions > saying that you do not need a reliable response in order to establish a > dialog. > > Also, chapter 12.1 of RFC3261 does say the following: > > "Dialogs are created through the generation of non-failure responses > to requests with specific methods. Within this specification, only > 2xx and 101-199 responses with a To tag, where the request was > INVITE, will establish a dialog. A dialog established by a non-final > response to a request is in the "early" state and it is called an > early dialog." > > Note that the text only talks about non-failure responses (2xx and > 101-199), not reliable responses (reliable provisional responses > (101-199) are not even defined in 3261). > >> If you send the UPDATE prior to a 18x, then the UPDATE would >> establish the dialog. You would need to have it carry the >> record-route, and all kinds of awful things. > > Yes, and that is a good reason not to send UPDATE before you have sent a > reliable response - at least not by the called party. But, one could > claim that the early dialog may still be established before that. > >> A better alternative would be to have a 18x/PRACK without an >> offer/answer exchange, followed by an UPDATE from callee to >> caller at some point in time. I can't think of a reason that >> wouldn't work, except that RFC 3261 is pretty clear that the >> offer is supposed to come in the first reliable response. So, >> omitting one in the 18x would probably seriously confuse most >> implementations. > > This is related to the discussion about the MUST to send an offer in the > first reliable 18x. It is listed as an issue in the offer/answer draft. > > Regards, > > Christer > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 05 11:30:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rxD-0005Rd-Q8; Fri, 05 Jan 2007 11:30:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rxC-0005QV-Gg for mmusic@ietf.org; Fri, 05 Jan 2007 11:30:02 -0500 Received: from out001.iad.hostedmail.net ([209.225.56.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rx9-0000eQ-AP for mmusic@ietf.org; Fri, 05 Jan 2007 11:30:02 -0500 Received: from ATL1VEXC020.usdom003.tco.tc ([10.158.7.31]) by out001.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 11:29:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Fri, 5 Jan 2007 11:31:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: Accw2sA7P+JPiTsITNKPY2UXv4+3NAAANN3w From: "Brett Tate" To: "mmusic" X-OriginalArrivalTime: 05 Jan 2007 16:29:50.0388 (UTC) FILETIME=[B8C50740:01C730E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org My understanding of rfc3311 is that sending an UPDATE with offer over an early dialog which has had no prior offer/answer exchange is not be allowed. RFC3311 section 5.1 bullet 4 indicates that the callee "cannot" send it. And my interpretation (which might be incorrect) of bullet 2 is that the "UPDATE can contain an offer if" should be interpreted as "UPDATE can contain an offer only if". Thus the caller also cannot send it. If my interpretation is incorrect, hopefully the call flow and expectations get reflected within draft-ietf-sipping-sip-offeranswer. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, January 05, 2007 9:52 AM > To: Christer Holmberg (JO/LMF) > Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic > Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >=20 > Christer, >=20 > A non-reliable response *can* establish a dialog - *if* it is=20 > received by the UAC. In that case the UAC knows a dialog has=20 > been established, but the UAS does not. >=20 > So, if a UAC receives an unreliable provisional that contains=20 > a tag it could potentially then send an UPDATE within that dialog. >=20 > But when the UAS sends that unreliable provisional, since it=20 > doesn't know for sure that a dialog has been established, it=20 > can't yet send an UPDATE. If it did send one, and the=20 > provisional had been lost, then the UAC would not be able to=20 > associate the UPDATE with a dialog, and it would fail. >=20 > Paul >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > >>> Can someone enlighten me as to why UPDATE isn't equally=20 > acceptable=20 > >>> for > >=20 > >>> transporting an SDP offer as reliable 18x/PRACK? > >> Well, you really need the reliable 18x to establish a dialog.=20 > >=20 > > I don't want to argue against you on that, but I HAVE heard=20 > opinions=20 > > saying that you do not need a reliable response in order to=20 > establish=20 > > a dialog. > >=20 > > Also, chapter 12.1 of RFC3261 does say the following: > >=20 > > "Dialogs are created through the generation of non-failure=20 > responses=20 > > to requests with specific methods. Within this specification, only=20 > > 2xx and 101-199 responses with a To tag, where the request=20 > was INVITE,=20 > > will establish a dialog. A dialog established by a=20 > non-final response=20 > > to a request is in the "early" state and it is called an early=20 > > dialog." > >=20 > > Note that the text only talks about non-failure responses (2xx and=20 > > 101-199), not reliable responses (reliable provisional responses > > (101-199) are not even defined in 3261). > >=20 > >> If you send the UPDATE prior to a 18x, then the UPDATE would=20 > >> establish the dialog. You would need to have it carry the=20 > >> record-route, and all kinds of awful things. > >=20 > > Yes, and that is a good reason not to send UPDATE before=20 > you have sent=20 > > a reliable response - at least not by the called party.=20 > But, one could=20 > > claim that the early dialog may still be established before that. > >=20 > >> A better alternative would be to have a 18x/PRACK without an=20 > >> offer/answer exchange, followed by an UPDATE from callee=20 > to caller at=20 > >> some point in time. I can't think of a reason that wouldn't work,=20 > >> except that RFC 3261 is pretty clear that the offer is supposed to=20 > >> come in the first reliable response. So, omitting one in the 18x=20 > >> would probably seriously confuse most implementations. > >=20 > > This is related to the discussion about the MUST to send an=20 > offer in=20 > > the first reliable 18x. It is listed as an issue in the=20 > offer/answer draft. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 05 16:06:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wGr-0003BQ-Od; Fri, 05 Jan 2007 16:06:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wGq-0003BG-Hm; Fri, 05 Jan 2007 16:06:36 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2wGo-0006qm-Rc; Fri, 05 Jan 2007 16:06:36 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l05L6We12578; Fri, 5 Jan 2007 16:06:32 -0500 (EST) Received: from [47.130.25.81] ([47.130.25.81] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 16:06:55 -0500 Message-ID: <459EBDC3.5060101@nortel.com> Date: Fri, 05 Jan 2007 16:06:11 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: avt@ietf.org, mmusic@ietf.org Content-Type: multipart/mixed; boundary="------------010606070909070904000409" X-OriginalArrivalTime: 05 Jan 2007 21:06:55.0765 (UTC) FILETIME=[6E443C50:01C7310D] X-Spam-Score: 0.5 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: Subject: [MMUSIC] [Fwd: I-D ACTION:draft-taylor-mmusic-multev-00.txt] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --------------010606070909070904000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is the palliative 'fix' for the RFC 4733 backward compatibility problem that I identified before Christmas. Follow-ups to MMUSIC. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Signalling the Ability To Understand Packing of Multiple Telephony Events Into One RTP Packet > Author(s) : T. Taylor > Filename : draft-taylor-mmusic-multev-00.txt > Pages : 10 > Date : 2007-1-5 > > Section 2.5.1.5 of RFC 4733 specifies how an implementation of the > telephony-event payload type can pack multiple short-duration event > reports into one RTP packet. Because this capability was added to > RFC 4733 in a fashion which is not backward compatible with RFC 2833, > it is desirable that a sender have the means to determine whether the > receiver understands such packets. This memo specifies a new SDP > attribute, a=multev, to indicate that capability. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-taylor-mmusic-multev-00.txt > --------------010606070909070904000409 Content-Type: message/rfc822; name="I-D ACTION:draft-taylor-mmusic-multev-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-taylor-mmusic-multev-00.txt" X-Account-Key: account2 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcarhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 15:53:26 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7310B.8B9BE700" Received: from zcars0mt.ca.nortel.com ([47.129.242.181]) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 15:53:49 -0500 Received: from ecarhea1.nortel.com (ecarhea1.nortel.com [47.248.0.48]) by zcars0mt.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with SMTP id l05KrPH16519; Fri, 5 Jan 2007 15:53:25 -0500 (EST) Received: from megatron.ietf.org (optimus.ietf.ORG [156.154.16.145]) by ecarhea1.nortel.com with SMTP (Lyris MailShield LINUX version 4.0d standard); Fri, 05 Jan 2007 15:53:24 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w1M-0005HH-CK; Fri, 05 Jan 2007 15:50:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w1I-0005EG-T8 for i-d-announce@ietf.org; Fri, 05 Jan 2007 15:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2w1I-0004tj-Ji for i-d-announce@ietf.org; Fri, 05 Jan 2007 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 853532AD03 for ; Fri, 5 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2w0o-0002Me-8X for i-d-announce@ietf.org; Fri, 05 Jan 2007 15:50:02 -0500 Return-Path: X-OriginalArrivalTime: 05 Jan 2007 20:53:49.0765 (UTC) FILETIME=[99C62750:01C7310B] X-Mailman-Version: 2.1.5 X-BeenThere: i-d-announce@ietf.org X-SMTP-HELO: megatron.ietf.org X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org X-SMTP-RCPT-TO: julianm@nortel.com, mleech@nortel.com, gkenward@nortel.com, taylor@nortel.com, jseligso@nortel.com X-SMTP-PEER-INFO: optimus.ietf.ORG [156.154.16.145] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ecarhea1.nortel.com List-Id: i-d-announce.ietf.org Errors-To: i-d-announce-bounces@ietf.org List-Post: X-Spam-Score: 2.3 X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be List-Archive: X-Spam-Tests: FORGED_RCVD_HELO=0.05, MIME_BOUND_NEXTPART=0.106, NO_REAL_NAME=0.178, TO_NORTEL=2 X-DNSBL-Score: -50 X-DNSBL-Servers: bl.nortel.com Content-class: urn:content-classes:message Subject: I-D ACTION:draft-taylor-mmusic-multev-00.txt Date: Fri, 5 Jan 2007 15:50:02 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-taylor-mmusic-multev-00.txt Thread-Index: AccxC4wst6kNBGIqSX69F35FNS/WJQ== List-Help: List-Subscribe: , List-Unsubscribe: , From: To: Reply-To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C7310B.8B9BE700 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7310B.8B9BE700" ------_=_NextPart_002_01C7310B.8B9BE700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Signalling the Ability To Understand Packing of Multiple = Telephony Events Into One RTP Packet Author(s) : T. Taylor Filename : draft-taylor-mmusic-multev-00.txt Pages : 10 Date : 2007-1-5 =09 Section 2.5.1.5 of RFC 4733 specifies how an implementation of the telephony-event payload type can pack multiple short-duration event reports into one RTP packet. Because this capability was added to RFC 4733 in a fashion which is not backward compatible with RFC 2833, it is desirable that a sender have the means to determine whether the receiver understands such packets. This memo specifies a new SDP attribute, a=3Dmultev, to indicate that capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-taylor-mmusic-multev-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-taylor-mmusic-multev-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-taylor-mmusic-multev-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_002_01C7310B.8B9BE700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I-D ACTION:draft-taylor-mmusic-multev-00.txt

A New Internet-Draft is available from the on-line = Internet-Drafts
directories.


        Title   =         : Signalling the Ability To = Understand Packing of Multiple Telephony Events Into One RTP Packet
        = Author(s)       : T. Taylor
        = Filename        : = draft-taylor-mmusic-multev-00.txt
        Pages   =         : 10
        Date    =         : 2007-1-5
       
   Section 2.5.1.5 of RFC 4733 specifies how an implementation = of the
   telephony-event payload type can pack multiple = short-duration event
   reports into one RTP packet.  Because this capability = was added to
   RFC 4733 in a fashion which is not backward compatible with = RFC 2833,
   it is desirable that a sender have the means to determine = whether the
   receiver understands such packets.  This memo = specifies a new SDP
   attribute, a=3Dmultev, to indicate that capability.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-taylor-mmusic-multev-00.t= xt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body = of
the message.
You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. = After
logging in, type "cd internet-drafts" and then
"get draft-taylor-mmusic-multev-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html<= /A>
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-taylor-mmusic-multev-00.txt".
       
NOTE:   The mail server at ietf.org can return the document = in
        MIME-encoded form by using = the "mpack" utility.  To use this
        feature, insert the command = "ENCODING mime" before the "FILE"
        command.  To decode the = response(s), you will need "munpack" or
        a MIME-compliant mail = reader.  Different MIME-compliant mail readers
        exhibit different behavior, = especially when dealing with
        "multipart" MIME = messages (i.e. documents which have been split
        up into multiple messages), = so check your local documentation on
        how to manipulate these = messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_002_01C7310B.8B9BE700-- ------_=_NextPart_001_01C7310B.8B9BE700 Content-Type: application/octet-stream; name="ATT1533945.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT1533945.TXT Content-Disposition: attachment; filename="ATT1533945.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0xLTUxMTQ3MjEuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGF5bG9yLW1tdXNpYy1tdWx0 ZXYtMDAudHh0DQo= ------_=_NextPart_001_01C7310B.8B9BE700 Content-Type: application/octet-stream; name="draft-taylor-mmusic-multev-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-taylor-mmusic-multev-00.URL Content-Disposition: attachment; filename="draft-taylor-mmusic-multev-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC10YXlsb3ItbW11c2ljLW11bHRldi0wMC50eHQNCg== ------_=_NextPart_001_01C7310B.8B9BE700 Content-Type: text/plain; name="ATT1533946.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1533946.txt Content-Disposition: attachment; filename="ATT1533946.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C7310B.8B9BE700-- --------------010606070909070904000409 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --------------010606070909070904000409-- From mmusic-bounces@ietf.org Fri Jan 05 16:53:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2x02-0007NF-6I; Fri, 05 Jan 2007 16:53:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2x01-0007N1-1x; Fri, 05 Jan 2007 16:53:17 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2wzy-0007LY-Nw; Fri, 05 Jan 2007 16:53:17 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l05Ljb026044; Fri, 5 Jan 2007 16:45:37 -0500 (EST) Received: from [47.130.25.81] ([47.130.25.81] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 16:53:31 -0500 Message-ID: <459EC8B2.2030409@nortel.com> Date: Fri, 05 Jan 2007 16:52:50 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: avt@ietf.org, mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2007 21:53:31.0750 (UTC) FILETIME=[F0CDB060:01C73113] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [MMUSIC] [Fwd: I-D ACTION:draft-taylor-mmusic-multev-00.txt] (second try) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Apologies for duplication. The preceding message got many bounces because I forgot to delete the original announcement attachment. This is the palliative 'fix' for the RFC 4733 backward compatibility problem that I identified before Christmas. Follow-ups to MMUSIC. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Signalling the Ability To Understand Packing of Multiple Telephony Events Into One RTP Packet > Author(s) : T. Taylor > Filename : draft-taylor-mmusic-multev-00.txt > Pages : 10 > Date : 2007-1-5 > > Section 2.5.1.5 of RFC 4733 specifies how an implementation of the > telephony-event payload type can pack multiple short-duration event > reports into one RTP packet. Because this capability was added to > RFC 4733 in a fashion which is not backward compatible with RFC 2833, > it is desirable that a sender have the means to determine whether the > receiver understands such packets. This memo specifies a new SDP > attribute, a=multev, to indicate that capability. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-taylor-mmusic-multev-00.txt > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 05 17:08:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2xF1-0006QC-1H; Fri, 05 Jan 2007 17:08:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2xF0-0006Q2-Ew for mmusic@ietf.org; Fri, 05 Jan 2007 17:08:46 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2xEy-0003dw-2h for mmusic@ietf.org; Fri, 05 Jan 2007 17:08:46 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2007 14:08:44 -0800 X-IronPort-AV: i="4.13,155,1167638400"; d="scan'208"; a="50110695:sNHT51026488" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l05M8hB2005228; Fri, 5 Jan 2007 17:08:43 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l05M8f2k018774; Fri, 5 Jan 2007 17:08:43 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 17:08:40 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 17:08:39 -0500 Message-ID: <459ECC65.7000100@cisco.com> Date: Fri, 05 Jan 2007 17:08:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Brett Tate Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2007 22:08:40.0042 (UTC) FILETIME=[0E300CA0:01C73116] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4202; t=1168034923; x=1168898923; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20Offer=20in=20a=20200=20(OK)=20and=20ICE |Sender:=20 |To:=20Brett=20Tate=20; bh=con6cY2nRcm3heSihl7g+g985LDBLiSDjDMv43NJk+s=; b=FaQWLsOXGqaai44Bkr7ftQFBtKs8G4HDP7iTv+Fa1AzPnXE5c/gawDb56eMyaddnx/18oXiO QPh5p26UpHO4twFODA0Wgj4VTD43KmnApKdLOHR3xC250i2daLalqDVK; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Brett Tate wrote: > My understanding of rfc3311 is that sending an UPDATE with offer over an > early dialog which has had no prior offer/answer exchange is not be > allowed. I agree. And this can be viewed as a consequence of other requirements: - you can't send the UPDATE till an early dialog has been established - to establish the early dialog you need to send a reliable provisional - if there was no offer in the INVITE, then there must be an offer in the first reliable response. Paul > RFC3311 section 5.1 bullet 4 indicates that the callee "cannot" send it. > And my interpretation (which might be incorrect) of bullet 2 is that the > "UPDATE can contain an offer if" should be interpreted as "UPDATE can > contain an offer only if". Thus the caller also cannot send it. > > If my interpretation is incorrect, hopefully the call flow and > expectations get reflected within draft-ietf-sipping-sip-offeranswer. > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, January 05, 2007 9:52 AM >> To: Christer Holmberg (JO/LMF) >> Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic >> Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >> >> Christer, >> >> A non-reliable response *can* establish a dialog - *if* it is >> received by the UAC. In that case the UAC knows a dialog has >> been established, but the UAS does not. >> >> So, if a UAC receives an unreliable provisional that contains >> a tag it could potentially then send an UPDATE within that dialog. >> >> But when the UAS sends that unreliable provisional, since it >> doesn't know for sure that a dialog has been established, it >> can't yet send an UPDATE. If it did send one, and the >> provisional had been lost, then the UAC would not be able to >> associate the UPDATE with a dialog, and it would fail. >> >> Paul >> >> Christer Holmberg (JO/LMF) wrote: >>> Hi, >>> >>>>> Can someone enlighten me as to why UPDATE isn't equally >> acceptable >>>>> for >>>>> transporting an SDP offer as reliable 18x/PRACK? >>>> Well, you really need the reliable 18x to establish a dialog. >>> I don't want to argue against you on that, but I HAVE heard >> opinions >>> saying that you do not need a reliable response in order to >> establish >>> a dialog. >>> >>> Also, chapter 12.1 of RFC3261 does say the following: >>> >>> "Dialogs are created through the generation of non-failure >> responses >>> to requests with specific methods. Within this specification, only >>> 2xx and 101-199 responses with a To tag, where the request >> was INVITE, >>> will establish a dialog. A dialog established by a >> non-final response >>> to a request is in the "early" state and it is called an early >>> dialog." >>> >>> Note that the text only talks about non-failure responses (2xx and >>> 101-199), not reliable responses (reliable provisional responses >>> (101-199) are not even defined in 3261). >>> >>>> If you send the UPDATE prior to a 18x, then the UPDATE would >>>> establish the dialog. You would need to have it carry the >>>> record-route, and all kinds of awful things. >>> Yes, and that is a good reason not to send UPDATE before >> you have sent >>> a reliable response - at least not by the called party. >> But, one could >>> claim that the early dialog may still be established before that. >>> >>>> A better alternative would be to have a 18x/PRACK without an >>>> offer/answer exchange, followed by an UPDATE from callee >> to caller at >>>> some point in time. I can't think of a reason that wouldn't work, >>>> except that RFC 3261 is pretty clear that the offer is supposed to >>>> come in the first reliable response. So, omitting one in the 18x >>>> would probably seriously confuse most implementations. >>> This is related to the discussion about the MUST to send an >> offer in >>> the first reliable 18x. It is listed as an issue in the >> offer/answer draft. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jan 07 16:08:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3fEq-0000ca-42; Sun, 07 Jan 2007 16:07:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3fEo-0000cS-V7 for mmusic@ietf.org; Sun, 07 Jan 2007 16:07:30 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3fEk-0002L6-Bc for mmusic@ietf.org; Sun, 07 Jan 2007 16:07:30 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 420D91AF; Sun, 7 Jan 2007 22:07:21 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 22:07:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Sun, 7 Jan 2007 22:07:20 +0100 Message-ID: <7374777208BDC7449D5620EF9423256701474C02@esealmw113.eemea.ericsson.se> In-Reply-To: <459E6629.8060501@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: Accw2SheFttDNZY/QN2vPossrKNs/gBxdhNA From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 07 Jan 2007 21:07:20.0868 (UTC) FILETIME=[D20E2640:01C7329F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Miguel Garcia , "Gonzalo Camarillo \(JO/LMF\)" , mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi,=20 >A non-reliable response *can* establish a dialog - *if* it is=20 >received by the UAC. In that case the UAC knows a dialog has=20 >been established, but the UAS does not. Yes. >So, if a UAC receives an unreliable provisional that contains=20 >a tag it could potentially then send an UPDATE within that dialog. Yes. But, that UPDATE can not contain a new SDP offer, since the previous answer wasn't delivered reliably.=20 One COULD claim that since the UAC has received the SDP (eventhough unreliably) it should be allowed to send a new offer (the UAS could of course not do that, since it doesn't know whether the answer reached the UAC) since it does not know whether the. But as we know it is currently not allowed. =20 >But when the UAS sends that unreliable provisional, since it=20 >doesn't know for sure that a dialog has been established, it=20 >can't yet send an UPDATE. If it did send one, and the=20 >provisional had been lost, then the UAC would not be able to=20 >associate the UPDATE with a dialog, and it would fail. Yes. One can receive a NOTIFY before receiving any response to a SUBSCRIBE, though, so maybe it could be solved also for INVITE and UPDATE, but let's not go there :) Regards, Christer >=20 > Paul >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > >>> Can someone enlighten me as to why UPDATE isn't equally=20 > acceptable=20 > >>> for > >=20 > >>> transporting an SDP offer as reliable 18x/PRACK? > >> Well, you really need the reliable 18x to establish a dialog.=20 > >=20 > > I don't want to argue against you on that, but I HAVE heard=20 > opinions=20 > > saying that you do not need a reliable response in order to=20 > establish=20 > > a dialog. > >=20 > > Also, chapter 12.1 of RFC3261 does say the following: > >=20 > > "Dialogs are created through the generation of non-failure=20 > responses=20 > > to requests with specific methods. Within this specification, only=20 > > 2xx and 101-199 responses with a To tag, where the request=20 > was INVITE,=20 > > will establish a dialog. A dialog established by a=20 > non-final response=20 > > to a request is in the "early" state and it is called an early=20 > > dialog." > >=20 > > Note that the text only talks about non-failure responses (2xx and=20 > > 101-199), not reliable responses (reliable provisional responses > > (101-199) are not even defined in 3261). > >=20 > >> If you send the UPDATE prior to a 18x, then the UPDATE would=20 > >> establish the dialog. You would need to have it carry the=20 > >> record-route, and all kinds of awful things. > >=20 > > Yes, and that is a good reason not to send UPDATE before=20 > you have sent=20 > > a reliable response - at least not by the called party.=20 > But, one could=20 > > claim that the early dialog may still be established before that. > >=20 > >> A better alternative would be to have a 18x/PRACK without an=20 > >> offer/answer exchange, followed by an UPDATE from callee=20 > to caller at=20 > >> some point in time. I can't think of a reason that wouldn't work,=20 > >> except that RFC 3261 is pretty clear that the offer is supposed to=20 > >> come in the first reliable response. So, omitting one in the 18x=20 > >> would probably seriously confuse most implementations. > >=20 > > This is related to the discussion about the MUST to send an=20 > offer in=20 > > the first reliable 18x. It is listed as an issue in the=20 > offer/answer draft. > >=20 > > Regards, > >=20 > > Christer > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jan 07 17:24:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3gR2-0005PU-6c; Sun, 07 Jan 2007 17:24:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3gR0-0005PO-OX for mmusic@ietf.org; Sun, 07 Jan 2007 17:24:10 -0500 Received: from calf.ext.ti.com ([198.47.26.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3gQx-0001iC-EO for mmusic@ietf.org; Sun, 07 Jan 2007 17:24:10 -0500 Received: from dlep95.itg.ti.com ([157.170.170.107]) by calf.ext.ti.com (8.13.7/8.13.7) with ESMTP id l07MLxJ9001381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jan 2007 16:22:09 -0600 Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep95.itg.ti.com (8.13.7/8.13.7) with ESMTP id l07MLs70010951; Sun, 7 Jan 2007 16:21:54 -0600 (CST) Received: from dlee03.ent.ti.com ([157.170.170.66]) by dsbe71.ent.ti.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 Jan 2007 16:21:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05 Date: Sun, 7 Jan 2007 16:21:53 -0600 Message-ID: <6F1AB8A9A94550408E37D83FA0DC4E79070F48F9@dlee03.ent.ti.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-ietf-mmusic-media-loopback-05 Thread-Index: AccgVe17c2OFoGapSWG/zjOYNrqtrQJjItUwAjFpFtA= From: "Mundra, Satish" To: "Hedayat, Kaynam" X-OriginalArrivalTime: 07 Jan 2007 22:21:54.0126 (UTC) FILETIME=[3C5326E0:01C732AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Kaynam, I have following comments on this draft. 1. I am not sure if "rtp-start-loopback" mode defined in section5.2 is necessary. One can always start=20 a session in normal media processing mode and then change the mode to loopback as mentioned=20 in section 5.6 of the draft. The "rtp-start-loopback" seems to be accomplishing the same by avoiding=20 additional OFFER/ANSWER exchange which will be needed to move the session to loopback mode in absence of=20 rtp-start-loopback. =20 2. The draft specifies the rules analogous to RFC3264 for the media formats signaled via the=20 a=3D=3D: line in SDP. IMO, the OFFER/ANSWER rules specified in RFC3264 are more than=20 sufficient to accomplish the desired loopback-mirror(OFFERER) and loopback-source(ANSWERER) behavior=20 when the "fmt" are signaled via the m=3D line. 3. I also don't see the need for the attributes "rtp-pkt-loopback" and "rtp-media-loopback".=20 The payload formats "audio/encaprtp" and "audio/rtploopback" are meaningful only when the loopback-mode is=20 mode is "rtp-pkt-loopback". If "loopback" attribute is present in answer but answerer chooses=20 to send payload other than one signaled for "encaprtp" or "rtploopback", then it is implied that the mode is rtp-media-loopback. For consistency, I think it's desirable to define audio/medialoopback" for the=20 above mode. This would allow the selection or negotiation of the appropriate loopback mode preferences=20 using the payload types on the m-line following the OFFER/ANSWER rules and would simplify the implementation.=20 4. I think the draft needs to includes Media Type registration for the RTP payload formats "audio/encaprtp"=20 and "audio/rtploopback" that are introduced. Regards, Satish Mundra=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 08 10:51:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wmY-0002h4-Q0; Mon, 08 Jan 2007 10:51:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wmX-0002gp-JD for mmusic@ietf.org; Mon, 08 Jan 2007 10:51:29 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3wmV-0006fM-6w for mmusic@ietf.org; Mon, 08 Jan 2007 10:51:29 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 08 Jan 2007 07:51:26 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l08FpOlv027156; Mon, 8 Jan 2007 07:51:24 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l08Fp2lx000133; Mon, 8 Jan 2007 07:51:24 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 10:51:13 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 10:51:13 -0500 Message-ID: <45A26870.10706@cisco.com> Date: Mon, 08 Jan 2007 10:51:12 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Mundra, Satish" Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05 References: <6F1AB8A9A94550408E37D83FA0DC4E79070F48F9@dlee03.ent.ti.com> In-Reply-To: <6F1AB8A9A94550408E37D83FA0DC4E79070F48F9@dlee03.ent.ti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2007 15:51:13.0056 (UTC) FILETIME=[D2C57A00:01C7333C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2627; t=1168271484; x=1169135484; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20draft-ietf-mmusic-media-loopback-05 |Sender:=20; bh=2G3ZXF3xnyoy7zzyfNxiPr59GOA8DFw9nZn7RbCdHts=; b=XRyBvastOZkcsPd5yWN2udUO1UpK0dsh8TyAzsZmkkesUdSVkoVOK/Nk5Bns324cBmsqkXA0 G2JszNDBhtRVRgkFY2oCe9ses21fRJVH+2fo6ZzLJHRwZvFdB3+Bg005; Authentication-Results: sj-dkim-6; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Mundra, Satish wrote: > Hi Kaynam, > > I have following comments on this draft. > > 1. I am not sure if "rtp-start-loopback" mode defined in section5.2 is > necessary. One can always start > a session in normal media processing mode and then change the mode to > loopback as mentioned > in section 5.6 of the draft. The "rtp-start-loopback" seems to be > accomplishing the same by avoiding > additional OFFER/ANSWER exchange which will be needed to move the > session to loopback mode in absence of > rtp-start-loopback. There is some value in knowing from the beginning that the session is for the purpose of loopback. In that case the UAS may consider it acceptable to auto-answer the call, where otherwise it would not. Also, if you start out with a regular media session and then switch to a loopback session it is a little more difficult to synchronize the loopback processing. The UAS needs to figure out which is the first packet that should be looped back rather than rendered, and similarly for the UAC. Not an insurmountable problem, but an added complexity. Paul > 2. The draft specifies the rules analogous to RFC3264 for the media > formats signaled via the > a==: line in SDP. IMO, the OFFER/ANSWER rules > specified in RFC3264 are more than > sufficient to accomplish the desired loopback-mirror(OFFERER) and > loopback-source(ANSWERER) behavior > when the "fmt" are signaled via the m= line. > > 3. I also don't see the need for the attributes "rtp-pkt-loopback" and > "rtp-media-loopback". > The payload formats "audio/encaprtp" and "audio/rtploopback" are > meaningful only when the loopback-mode is > mode is "rtp-pkt-loopback". If "loopback" attribute is present in > answer but answerer chooses > to send payload other than one signaled for "encaprtp" or > "rtploopback", then it is implied that the > mode is rtp-media-loopback. For consistency, I think it's desirable to > define audio/medialoopback" for the > above mode. This would allow the selection or negotiation of the > appropriate loopback mode preferences > using the payload types on the m-line following the OFFER/ANSWER rules > and would simplify the implementation. > > 4. I think the draft needs to includes Media Type registration for the > RTP payload formats "audio/encaprtp" > and "audio/rtploopback" that are introduced. > > > Regards, > > Satish Mundra > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 08 14:10:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zsr-0001lP-RQ; Mon, 08 Jan 2007 14:10:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zsq-0001ky-OO for mmusic@ietf.org; Mon, 08 Jan 2007 14:10:12 -0500 Received: from calf.ext.ti.com ([198.47.26.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3zsn-0001EG-BV for mmusic@ietf.org; Mon, 08 Jan 2007 14:10:12 -0500 Received: from dlep95.itg.ti.com ([157.170.170.107]) by calf.ext.ti.com (8.13.7/8.13.7) with ESMTP id l08J7eoJ031914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 13:07:54 -0600 Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep95.itg.ti.com (8.13.7/8.13.7) with ESMTP id l08J7Yqs010923; Mon, 8 Jan 2007 13:07:35 -0600 (CST) Received: from dlee03.ent.ti.com ([157.170.170.66]) by dsbe71.ent.ti.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 13:07:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-05 Date: Mon, 8 Jan 2007 13:07:33 -0600 Message-ID: <6F1AB8A9A94550408E37D83FA0DC4E79070F4E2E@dlee03.ent.ti.com> In-Reply-To: <45A26870.10706@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-ietf-mmusic-media-loopback-05 Thread-Index: AcczPOCgLSMDxUxcR7CJyQEzuRxvTQAF4TLA From: "Mundra, Satish" To: "Paul Kyzivat" X-OriginalArrivalTime: 08 Jan 2007 19:07:34.0901 (UTC) FILETIME=[414C5A50:01C73358] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, January 08, 2007 10:51 AM > To: Mundra, Satish > Cc: Hedayat, Kaynam; MMUSIC WG > Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05 >=20 >=20 >=20 > Mundra, Satish wrote: > > Hi Kaynam, > >=20 > > I have following comments on this draft. > >=20 > > 1. I am not sure if "rtp-start-loopback" mode defined in=20 > section5.2 is=20 > > necessary. One can always start a session in normal media=20 > processing=20 > > mode and then change the mode to loopback as mentioned in=20 > section 5.6=20 > > of the draft. The "rtp-start-loopback" seems to be=20 > accomplishing the=20 > > same by avoiding additional OFFER/ANSWER exchange which=20 > will be needed=20 > > to move the session to loopback mode in absence of=20 > rtp-start-loopback. >=20 > There is some value in knowing from the beginning that the=20 > session is for the purpose of loopback. In that case the UAS=20 > may consider it acceptable to auto-answer the call, where=20 > otherwise it would not. >=20 UAS probably would also have to ensure that user is not alerted for these calls apart from auto answering=20 so there will have to be some means of signaling this intent (may be Alert-Info in case of SIP).=20 If the SDP attribute is to be used for this purpose then the loopback payloads can be present on the media=20 line but not as preferred to allow the call to start in normal mode of media processing.=20 > Also, if you start out with a regular media session and then=20 > switch to a loopback session it is a little more difficult to=20 > synchronize the loopback processing. The UAS needs to figure=20 > out which is the first packet that should be looped back=20 > rather than rendered, and similarly for the UAC. Not an=20 > insurmountable problem, but an added complexity. >=20 Since the transition between different loopback modes (including the loopback-none to begin with) will happen=20 with re-invite (new RTP session), there should be no confusion for the UAS as to when to begin the loopback. --Satish > Paul >=20 > > 2. The draft specifies the rules analogous to RFC3264 for the media=20 > > formats signaled via the a=3D=3D:=20 > line in SDP.=20 > > IMO, the OFFER/ANSWER rules specified in RFC3264 are more than=20 > > sufficient to accomplish the desired loopback-mirror(OFFERER) and > > loopback-source(ANSWERER) behavior > > when the "fmt" are signaled via the m=3D line. > >=20 > > 3. I also don't see the need for the attributes=20 > "rtp-pkt-loopback" and=20 > > "rtp-media-loopback". > > The payload formats "audio/encaprtp" and "audio/rtploopback" are=20 > > meaningful only when the loopback-mode is mode is=20 > "rtp-pkt-loopback". =20 > > If "loopback" attribute is present in answer but answerer=20 > chooses to=20 > > send payload other than one signaled for "encaprtp" or=20 > "rtploopback",=20 > > then it is implied that the mode is rtp-media-loopback. For=20 > > consistency, I think it's desirable to define=20 > audio/medialoopback" for=20 > > the above mode. This would allow the selection or=20 > negotiation of the=20 > > appropriate loopback mode preferences using the payload=20 > types on the=20 > > m-line following the OFFER/ANSWER rules and would simplify the=20 > > implementation. > >=20 > > 4. I think the draft needs to includes Media Type=20 > registration for the=20 > > RTP payload formats "audio/encaprtp" > > and "audio/rtploopback" that are introduced. > >=20 > >=20 > > Regards, > >=20 > > Satish Mundra > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 08 16:15:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41pK-0002cp-9N; Mon, 08 Jan 2007 16:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41pJ-0002cf-7E for mmusic@ietf.org; Mon, 08 Jan 2007 16:14:41 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H41pH-0001Lm-RB for mmusic@ietf.org; Mon, 08 Jan 2007 16:14:41 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Jan 2007 16:14:40 -0500 X-IronPort-AV: i="4.13,160,1167627600"; d="scan'208"; a="111124449:sNHT52703828" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l08LEdKF002913; Mon, 8 Jan 2007 16:14:39 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l08LEX2k004759; Mon, 8 Jan 2007 16:14:39 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 16:14:33 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 16:14:33 -0500 Message-ID: <45A2B439.6010906@cisco.com> Date: Mon, 08 Jan 2007 16:14:33 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Mundra, Satish" Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05 References: <6F1AB8A9A94550408E37D83FA0DC4E79070F4E2E@dlee03.ent.ti.com> In-Reply-To: <6F1AB8A9A94550408E37D83FA0DC4E79070F4E2E@dlee03.ent.ti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2007 21:14:33.0503 (UTC) FILETIME=[FE56C2F0:01C73369] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4525; t=1168290879; x=1169154879; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20draft-ietf-mmusic-media-loopback-05 |Sender:=20 |To:=20=22Mundra,=20Satish=22=20; bh=bbEa/dB7aX0gZAea10Nvrth5jydaCHBv+Ep5zZF7O4s=; b=cK+XElimj+vCN6VIlitKkGfPYUZsOqeCq8xTwTOto3IfZBn0jL5RHxDAqMulluin2N0h2cBf +nYRu8Z68TTGeZzVNqAX40fMBX6lO9Piv70CQ3tB5LuML7UCnf/zCTff; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Mundra, Satish wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, January 08, 2007 10:51 AM >> To: Mundra, Satish >> Cc: Hedayat, Kaynam; MMUSIC WG >> Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05 >> >> >> >> Mundra, Satish wrote: >>> Hi Kaynam, >>> >>> I have following comments on this draft. >>> >>> 1. I am not sure if "rtp-start-loopback" mode defined in >> section5.2 is >>> necessary. One can always start a session in normal media >> processing >>> mode and then change the mode to loopback as mentioned in >> section 5.6 >>> of the draft. The "rtp-start-loopback" seems to be >> accomplishing the >>> same by avoiding additional OFFER/ANSWER exchange which >> will be needed >>> to move the session to loopback mode in absence of >> rtp-start-loopback. >> >> There is some value in knowing from the beginning that the >> session is for the purpose of loopback. In that case the UAS >> may consider it acceptable to auto-answer the call, where >> otherwise it would not. >> > > UAS probably would also have to ensure that user is not alerted for > these calls apart from auto answering > so there will have to be some means of signaling this intent (may be > Alert-Info in case of SIP). > If the SDP attribute is to be used for this purpose then the loopback > payloads can be present on the media > line but not as preferred to allow the call to start in normal mode of > media processing. The difference is that if the call starts out normally, then the media sent must come from someplace. Typically it would come from the microphone of the device. This is not something you would typically want if you are going to auto-answer a call - it turns the phone into a surveillance device. The usage of this mechanism for unattended testing of devices requires a variety of pieces. Not alerting is another part of that. There is some controversy (justified) about that, which is, I think, a reason it isn't mentioned in this draft. >> Also, if you start out with a regular media session and then >> switch to a loopback session it is a little more difficult to >> synchronize the loopback processing. The UAS needs to figure >> out which is the first packet that should be looped back >> rather than rendered, and similarly for the UAC. Not an >> insurmountable problem, but an added complexity. >> > > Since the transition between different loopback modes (including the > loopback-none to begin with) will happen > with re-invite (new RTP session), there should be no confusion for the > UAS as to when to begin the loopback. I guess it could be clear if the new session chose a different address or port. If the address and port remain the same, then its still a bit tricky. Paul > --Satish > > >> Paul >> >>> 2. The draft specifies the rules analogous to RFC3264 for the media >>> formats signaled via the a==: >> line in SDP. >>> IMO, the OFFER/ANSWER rules specified in RFC3264 are more than >>> sufficient to accomplish the desired loopback-mirror(OFFERER) and >>> loopback-source(ANSWERER) behavior >>> when the "fmt" are signaled via the m= line. >>> >>> 3. I also don't see the need for the attributes >> "rtp-pkt-loopback" and >>> "rtp-media-loopback". >>> The payload formats "audio/encaprtp" and "audio/rtploopback" are >>> meaningful only when the loopback-mode is mode is >> "rtp-pkt-loopback". >>> If "loopback" attribute is present in answer but answerer >> chooses to >>> send payload other than one signaled for "encaprtp" or >> "rtploopback", >>> then it is implied that the mode is rtp-media-loopback. For >>> consistency, I think it's desirable to define >> audio/medialoopback" for >>> the above mode. This would allow the selection or >> negotiation of the >>> appropriate loopback mode preferences using the payload >> types on the >>> m-line following the OFFER/ANSWER rules and would simplify the >>> implementation. >>> >>> 4. I think the draft needs to includes Media Type >> registration for the >>> RTP payload formats "audio/encaprtp" >>> and "audio/rtploopback" that are introduced. >>> >>> >>> Regards, >>> >>> Satish Mundra >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 08 19:03:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H44Ru-0006IA-3u; Mon, 08 Jan 2007 19:02:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H44Rt-0006I4-8Q for mmusic@ietf.org; Mon, 08 Jan 2007 19:02:41 -0500 Received: from arroyo.ext.ti.com ([192.94.94.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H44Rr-0006ef-Qb for mmusic@ietf.org; Mon, 08 Jan 2007 19:02:41 -0500 Received: from dlep95.itg.ti.com ([157.170.170.107]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id l0900k9K015894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 18:00:51 -0600 Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep95.itg.ti.com (8.13.7/8.13.7) with ESMTP id l0900kXJ015038; Mon, 8 Jan 2007 18:00:46 -0600 (CST) Received: from dlee03.ent.ti.com ([157.170.170.66]) by dsbe71.ent.ti.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Jan 2007 18:00:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-05 Date: Mon, 8 Jan 2007 18:00:44 -0600 Message-ID: <6F1AB8A9A94550408E37D83FA0DC4E79070F4FFD@dlee03.ent.ti.com> In-Reply-To: <45A2B439.6010906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-ietf-mmusic-media-loopback-05 Thread-Index: Acczag0HriSwBMdiRVCMrZ2SxjUFHQAC1PFQ From: "Mundra, Satish" To: "Paul Kyzivat" X-OriginalArrivalTime: 09 Jan 2007 00:00:46.0214 (UTC) FILETIME=[3689B260:01C73381] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, January 08, 2007 4:15 PM > To: Mundra, Satish > Cc: Hedayat, Kaynam; MMUSIC WG > Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05 >=20 >=20 >=20 > Mundra, Satish wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, January 08, 2007 10:51 AM > >> To: Mundra, Satish > >> Cc: Hedayat, Kaynam; MMUSIC WG > >> Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05 > >> > >> > >> > >> Mundra, Satish wrote: > >>> Hi Kaynam, > >>> > >>> I have following comments on this draft. > >>> > >>> 1. I am not sure if "rtp-start-loopback" mode defined in > >> section5.2 is > >>> necessary. One can always start a session in normal media > >> processing > >>> mode and then change the mode to loopback as mentioned in > >> section 5.6 > >>> of the draft. The "rtp-start-loopback" seems to be > >> accomplishing the > >>> same by avoiding additional OFFER/ANSWER exchange which > >> will be needed > >>> to move the session to loopback mode in absence of > >> rtp-start-loopback. > >> > >> There is some value in knowing from the beginning that the=20 > session is=20 > >> for the purpose of loopback. In that case the UAS may consider it=20 > >> acceptable to auto-answer the call, where otherwise it would not. > >> > >=20 > > UAS probably would also have to ensure that user is not alerted for=20 > > these calls apart from auto answering so there will have to be some=20 > > means of signaling this intent (may be Alert-Info in case of SIP). > > If the SDP attribute is to be used for this purpose then=20 > the loopback=20 > > payloads can be present on the media line but not as preferred to=20 > > allow the call to start in normal mode of media processing. >=20 > The difference is that if the call starts out normally, then=20 > the media sent must come from someplace. Typically it would=20 > come from the microphone of the device. This is not something=20 > you would typically want if you are going to auto-answer a=20 > call - it turns the phone into a surveillance device. >=20 This behavior is possible even if you were to signal rtp-start-loopback, draft at present requires transmission of the media by mirror until it receives=20 media from the source so if a source desires then it can convert such a phone=20 to surveillance device by not sending any media. If the call is for the purpose of loopback then the loopback attribute would be required in SDP for the reasons you mention, I am only proposing that=20 loopback-types including the rtp-start-loopback are unnecessary(comment 2,3 below)=20 and would simplify this draft and implementation.=20 I guess a guidance is required in the draft that that any media sent for calls established using the=20 procedures specified in this draft should not come from any real source. --Satish > The usage of this mechanism for unattended testing of devices=20 > requires a variety of pieces. Not alerting is another part of=20 > that. There is some controversy (justified) about that, which=20 > is, I think, a reason it isn't mentioned in this draft. >=20 > >> Also, if you start out with a regular media session and=20 > then switch=20 > >> to a loopback session it is a little more difficult to synchronize=20 > >> the loopback processing. The UAS needs to figure out which is the=20 > >> first packet that should be looped back rather than rendered, and=20 > >> similarly for the UAC. Not an insurmountable problem, but an added=20 > >> complexity. > >> > >=20 > > Since the transition between different loopback modes=20 > (including the=20 > > loopback-none to begin with) will happen with re-invite (new RTP=20 > > session), there should be no confusion for the UAS as to=20 > when to begin=20 > > the loopback. >=20 > I guess it could be clear if the new session chose a=20 > different address or port. If the address and port remain the=20 > same, then its still a bit tricky. >=20 > Paul >=20 > > --Satish > >=20 > >=20 > >> Paul > >> > >>> 2. The draft specifies the rules analogous to RFC3264 for=20 > the media=20 > >>> formats signaled via the a=3D=3D: > >> line in SDP.=20 > >>> IMO, the OFFER/ANSWER rules specified in RFC3264 are more than=20 > >>> sufficient to accomplish the desired loopback-mirror(OFFERER) and > >>> loopback-source(ANSWERER) behavior > >>> when the "fmt" are signaled via the m=3D line. > >>> > >>> 3. I also don't see the need for the attributes > >> "rtp-pkt-loopback" and > >>> "rtp-media-loopback". > >>> The payload formats "audio/encaprtp" and "audio/rtploopback" are=20 > >>> meaningful only when the loopback-mode is mode is > >> "rtp-pkt-loopback". =20 > >>> If "loopback" attribute is present in answer but answerer > >> chooses to > >>> send payload other than one signaled for "encaprtp" or > >> "rtploopback", > >>> then it is implied that the mode is rtp-media-loopback. For=20 > >>> consistency, I think it's desirable to define > >> audio/medialoopback" for > >>> the above mode. This would allow the selection or > >> negotiation of the > >>> appropriate loopback mode preferences using the payload > >> types on the > >>> m-line following the OFFER/ANSWER rules and would simplify the=20 > >>> implementation. > >>> > >>> 4. I think the draft needs to includes Media Type > >> registration for the > >>> RTP payload formats "audio/encaprtp" > >>> and "audio/rtploopback" that are introduced. > >>> > >>> > >>> Regards, > >>> > >>> Satish Mundra > >>> > >>> > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mmusic > >>> > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 09 14:02:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MEN-0006x6-3t; Tue, 09 Jan 2007 14:01:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MEL-0006wI-3B for mmusic@ietf.org; Tue, 09 Jan 2007 14:01:53 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4MEF-0006im-9f for mmusic@ietf.org; Tue, 09 Jan 2007 14:01:53 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 480591C7; Tue, 9 Jan 2007 20:01:38 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 20:01:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Tue, 9 Jan 2007 20:01:36 +0100 Message-ID: <7374777208BDC7449D5620EF942325670155B106@esealmw113.eemea.ericsson.se> In-Reply-To: <459ECC65.7000100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: AccxFjTgW84puFHtQliuzBMswEfnwwDCYXvQ From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , "Brett Tate" X-OriginalArrivalTime: 09 Jan 2007 19:01:38.0099 (UTC) FILETIME=[970A7030:01C73420] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi,=20 >>My understanding of rfc3311 is that sending an UPDATE with=20 >>offer over an early dialog which has had no prior offer/answer=20 >>exchange is not be allowed. >=20 >I agree. I also agree.=20 My point was that one could claim that if the "answer" is sent unreliably, the UAC knows it has got it, so it could send a new offer in the UPDATE. But, that is not allowed. =20 >And this can be viewed as a consequence of other requirements: >- you can't send the UPDATE till an early dialog has been established >- to establish the early dialog you need to send a reliable provisional Earlier you said the follwing: "A non-reliable response *can* establish a dialog - *if* it is received by the UAC." So, yes, the UAS must send a reliable response in order to establish an early dialog. But, as you said, the UAC can establish a dialog even when receiving an unreliable response. But the UAC still not allowed to send a new offer within that dialog, since no answer has yet been delivered reliably (the unreliable 18x may have included a "preview" of the answer, but it doesn't count). >- if there was no offer in the INVITE, then there must be an offer in the first reliable response. That is currently the rule, yes, but one of the issues listed in the offer-answer draft. Regards, Christer >=20 > Paul >=20 > > RFC3311 section 5.1 bullet 4 indicates that the callee=20 > "cannot" send it. > > And my interpretation (which might be incorrect) of bullet=20 > 2 is that=20 > > the "UPDATE can contain an offer if" should be interpreted=20 > as "UPDATE=20 > > can contain an offer only if". Thus the caller also cannot send it. > >=20 > > If my interpretation is incorrect, hopefully the call flow and=20 > > expectations get reflected within=20 > draft-ietf-sipping-sip-offeranswer. > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, January 05, 2007 9:52 AM > >> To: Christer Holmberg (JO/LMF) > >> Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic > >> Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE > >> > >> Christer, > >> > >> A non-reliable response *can* establish a dialog - *if* it is=20 > >> received by the UAC. In that case the UAC knows a dialog has been=20 > >> established, but the UAS does not. > >> > >> So, if a UAC receives an unreliable provisional that=20 > contains a tag=20 > >> it could potentially then send an UPDATE within that dialog. > >> > >> But when the UAS sends that unreliable provisional, since=20 > it doesn't=20 > >> know for sure that a dialog has been established, it can't=20 > yet send=20 > >> an UPDATE. If it did send one, and the provisional had been lost,=20 > >> then the UAC would not be able to associate the UPDATE=20 > with a dialog,=20 > >> and it would fail. > >> > >> Paul > >> > >> Christer Holmberg (JO/LMF) wrote: > >>> Hi, > >>> > >>>>> Can someone enlighten me as to why UPDATE isn't equally > >> acceptable > >>>>> for > >>>>> transporting an SDP offer as reliable 18x/PRACK? > >>>> Well, you really need the reliable 18x to establish a dialog.=20 > >>> I don't want to argue against you on that, but I HAVE heard > >> opinions > >>> saying that you do not need a reliable response in order to > >> establish > >>> a dialog. > >>> > >>> Also, chapter 12.1 of RFC3261 does say the following: > >>> > >>> "Dialogs are created through the generation of non-failure > >> responses > >>> to requests with specific methods. Within this=20 > specification, only=20 > >>> 2xx and 101-199 responses with a To tag, where the request > >> was INVITE, > >>> will establish a dialog. A dialog established by a > >> non-final response > >>> to a request is in the "early" state and it is called an early=20 > >>> dialog." > >>> > >>> Note that the text only talks about non-failure responses=20 > (2xx and=20 > >>> 101-199), not reliable responses (reliable provisional responses > >>> (101-199) are not even defined in 3261). > >>> > >>>> If you send the UPDATE prior to a 18x, then the UPDATE would=20 > >>>> establish the dialog. You would need to have it carry the=20 > >>>> record-route, and all kinds of awful things. > >>> Yes, and that is a good reason not to send UPDATE before > >> you have sent > >>> a reliable response - at least not by the called party.=20 > >> But, one could > >>> claim that the early dialog may still be established before that. > >>> > >>>> A better alternative would be to have a 18x/PRACK without an=20 > >>>> offer/answer exchange, followed by an UPDATE from callee > >> to caller at > >>>> some point in time. I can't think of a reason that=20 > wouldn't work,=20 > >>>> except that RFC 3261 is pretty clear that the offer is=20 > supposed to=20 > >>>> come in the first reliable response. So, omitting one in the 18x=20 > >>>> would probably seriously confuse most implementations. > >>> This is related to the discussion about the MUST to send an > >> offer in > >>> the first reliable 18x. It is listed as an issue in the > >> offer/answer draft. > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 09 17:12:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PCc-0007r8-GS; Tue, 09 Jan 2007 17:12:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PCa-0007nJ-Gc for mmusic@ietf.org; Tue, 09 Jan 2007 17:12:16 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4PCY-00056G-3a for mmusic@ietf.org; Tue, 09 Jan 2007 17:12:16 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2007 17:12:14 -0500 X-IronPort-AV: i="4.13,164,1167627600"; d="scan'208"; a="111207001:sNHT55672604" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l09MCD5Z032611; Tue, 9 Jan 2007 17:12:13 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l09MCD2m008294; Tue, 9 Jan 2007 17:12:13 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 17:12:13 -0500 Received: from [10.86.242.10] ([10.86.242.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 17:12:12 -0500 Message-ID: <45A4133B.4060802@cisco.com> Date: Tue, 09 Jan 2007 17:12:11 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE References: <7374777208BDC7449D5620EF942325670155B106@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670155B106@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2007 22:12:13.0027 (UTC) FILETIME=[36C9FB30:01C7343B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5930; t=1168380733; x=1169244733; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20Offer=20in=20a=20200=20(OK)=20and=20ICE |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=fKXVHok6ZhCFVRzp11QerxKPz353DQ6qeNGIvEqKuh4=; b=kBalO2mFOl6Y+WcNe+emJtaxMFeaABSjXKjT6g5N+BW5oHbIUWTR0JMsXww4Nlp+FeXYUREN awrnDbn5Y9fM0ITzLHlAc5LCy6j9jXAQ1iL/XxnZFCpCUvVZvboDlV/z; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: mmusic , Brett Tate X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Christer, The subject of this thread scopes it to the case where there would be an offer in the 200. That can only happen if there was no offer in the invite. The issues you raise below are when there was an offer in the invite, which is off topic for this thread. I agree the situation is a bit different in that case, but if you want to discuss that, how about starting a new thread for it. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > >>> My understanding of rfc3311 is that sending an UPDATE with >>> offer over an early dialog which has had no prior offer/answer >>> exchange is not be allowed. >> I agree. > > I also agree. > > My point was that one could claim that if the "answer" is sent > unreliably, the UAC knows it has got it, so it could send a new offer in > the UPDATE. But, that is not allowed. > >> And this can be viewed as a consequence of other requirements: >> - you can't send the UPDATE till an early dialog has been established >> - to establish the early dialog you need to send a reliable provisional > > Earlier you said the follwing: "A non-reliable response *can* establish > a dialog - *if* it is received by the UAC." > > So, yes, the UAS must send a reliable response in order to establish an > early dialog. > > But, as you said, the UAC can establish a dialog even when receiving an > unreliable response. But the UAC still not allowed to send a new offer > within that dialog, since no answer has yet been delivered reliably (the > unreliable 18x may have included a "preview" of the answer, but it > doesn't count). > >> - if there was no offer in the INVITE, then there must be an offer in > the first reliable response. > > That is currently the rule, yes, but one of the issues listed in the > offer-answer draft. > > Regards, > > Christer > > > > >> Paul >> >>> RFC3311 section 5.1 bullet 4 indicates that the callee >> "cannot" send it. >>> And my interpretation (which might be incorrect) of bullet >> 2 is that >>> the "UPDATE can contain an offer if" should be interpreted >> as "UPDATE >>> can contain an offer only if". Thus the caller also cannot send it. >>> >>> If my interpretation is incorrect, hopefully the call flow and >>> expectations get reflected within >> draft-ietf-sipping-sip-offeranswer. >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Friday, January 05, 2007 9:52 AM >>>> To: Christer Holmberg (JO/LMF) >>>> Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic >>>> Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >>>> >>>> Christer, >>>> >>>> A non-reliable response *can* establish a dialog - *if* it is >>>> received by the UAC. In that case the UAC knows a dialog has been >>>> established, but the UAS does not. >>>> >>>> So, if a UAC receives an unreliable provisional that >> contains a tag >>>> it could potentially then send an UPDATE within that dialog. >>>> >>>> But when the UAS sends that unreliable provisional, since >> it doesn't >>>> know for sure that a dialog has been established, it can't >> yet send >>>> an UPDATE. If it did send one, and the provisional had been lost, >>>> then the UAC would not be able to associate the UPDATE >> with a dialog, >>>> and it would fail. >>>> >>>> Paul >>>> >>>> Christer Holmberg (JO/LMF) wrote: >>>>> Hi, >>>>> >>>>>>> Can someone enlighten me as to why UPDATE isn't equally >>>> acceptable >>>>>>> for >>>>>>> transporting an SDP offer as reliable 18x/PRACK? >>>>>> Well, you really need the reliable 18x to establish a dialog. >>>>> I don't want to argue against you on that, but I HAVE heard >>>> opinions >>>>> saying that you do not need a reliable response in order to >>>> establish >>>>> a dialog. >>>>> >>>>> Also, chapter 12.1 of RFC3261 does say the following: >>>>> >>>>> "Dialogs are created through the generation of non-failure >>>> responses >>>>> to requests with specific methods. Within this >> specification, only >>>>> 2xx and 101-199 responses with a To tag, where the request >>>> was INVITE, >>>>> will establish a dialog. A dialog established by a >>>> non-final response >>>>> to a request is in the "early" state and it is called an early >>>>> dialog." >>>>> >>>>> Note that the text only talks about non-failure responses >> (2xx and >>>>> 101-199), not reliable responses (reliable provisional responses >>>>> (101-199) are not even defined in 3261). >>>>> >>>>>> If you send the UPDATE prior to a 18x, then the UPDATE would >>>>>> establish the dialog. You would need to have it carry the >>>>>> record-route, and all kinds of awful things. >>>>> Yes, and that is a good reason not to send UPDATE before >>>> you have sent >>>>> a reliable response - at least not by the called party. >>>> But, one could >>>>> claim that the early dialog may still be established before that. >>>>> >>>>>> A better alternative would be to have a 18x/PRACK without an >>>>>> offer/answer exchange, followed by an UPDATE from callee >>>> to caller at >>>>>> some point in time. I can't think of a reason that >> wouldn't work, >>>>>> except that RFC 3261 is pretty clear that the offer is >> supposed to >>>>>> come in the first reliable response. So, omitting one in the 18x >>>>>> would probably seriously confuse most implementations. >>>>> This is related to the discussion about the MUST to send an >>>> offer in >>>>> the first reliable 18x. It is listed as an issue in the >>>> offer/answer draft. >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 09 22:38:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UHn-0001Gz-KK; Tue, 09 Jan 2007 22:37:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4UHm-0001Gq-LA for mmusic@ietf.org; Tue, 09 Jan 2007 22:37:58 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4UHg-00087v-Ps for mmusic@ietf.org; Tue, 09 Jan 2007 22:37:58 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A55314F0001; Wed, 10 Jan 2007 04:37:37 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 04:37:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Offer in a 200 (OK) and ICE Date: Wed, 10 Jan 2007 04:37:36 +0100 Message-ID: <7374777208BDC7449D5620EF942325670155B2ED@esealmw113.eemea.ericsson.se> In-Reply-To: <45A4133B.4060802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Offer in a 200 (OK) and ICE Thread-Index: Acc0Ozi8BJTZJLdwRhmMF8rbThkAPwALRh0g From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 10 Jan 2007 03:37:37.0519 (UTC) FILETIME=[AC4B07F0:01C73468] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: mmusic , Brett Tate X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Paul, I just wanted to clarify that, even if a UAC can send an UPDATE on an dialog it created when receiving an unreliable 18x, that UPDATE can not contain an offer (or an answer for that matter). I don't want to change that behavior :) Regards, Christer=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 10. tammikuuta 2007 0:12 > To: Christer Holmberg (JO/LMF) > Cc: Brett Tate; mmusic > Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE >=20 > Christer, >=20 > The subject of this thread scopes it to the case where there=20 > would be an offer in the 200. That can only happen if there=20 > was no offer in the invite. The issues you raise below are=20 > when there was an offer in the invite, which is off topic for=20 > this thread. I agree the situation is a bit different in that=20 > case, but if you want to discuss that, how about starting a=20 > new thread for it. >=20 > Paul >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > >>> My understanding of rfc3311 is that sending an UPDATE with offer=20 > >>> over an early dialog which has had no prior offer/answer=20 > exchange is=20 > >>> not be allowed. > >> I agree. > >=20 > > I also agree.=20 > >=20 > > My point was that one could claim that if the "answer" is sent=20 > > unreliably, the UAC knows it has got it, so it could send a=20 > new offer=20 > > in the UPDATE. But, that is not allowed. > > =20 > >> And this can be viewed as a consequence of other requirements: > >> - you can't send the UPDATE till an early dialog has been=20 > established > >> - to establish the early dialog you need to send a reliable=20 > >> provisional > >=20 > > Earlier you said the follwing: "A non-reliable response *can*=20 > > establish a dialog - *if* it is received by the UAC." > >=20 > > So, yes, the UAS must send a reliable response in order to=20 > establish=20 > > an early dialog. > >=20 > > But, as you said, the UAC can establish a dialog even when=20 > receiving=20 > > an unreliable response. But the UAC still not allowed to send a new=20 > > offer within that dialog, since no answer has yet been delivered=20 > > reliably (the unreliable 18x may have included a "preview" of the=20 > > answer, but it doesn't count). > >=20 > >> - if there was no offer in the INVITE, then there must be=20 > an offer in > > the first reliable response. > >=20 > > That is currently the rule, yes, but one of the issues=20 > listed in the=20 > > offer-answer draft. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >> Paul > >> > >>> RFC3311 section 5.1 bullet 4 indicates that the callee > >> "cannot" send it. > >>> And my interpretation (which might be incorrect) of bullet > >> 2 is that > >>> the "UPDATE can contain an offer if" should be interpreted > >> as "UPDATE > >>> can contain an offer only if". Thus the caller also=20 > cannot send it. > >>> > >>> If my interpretation is incorrect, hopefully the call flow and=20 > >>> expectations get reflected within > >> draft-ietf-sipping-sip-offeranswer. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Friday, January 05, 2007 9:52 AM > >>>> To: Christer Holmberg (JO/LMF) > >>>> Cc: Miguel Garcia; Gonzalo Camarillo (JO/LMF); mmusic > >>>> Subject: Re: [MMUSIC] Offer in a 200 (OK) and ICE > >>>> > >>>> Christer, > >>>> > >>>> A non-reliable response *can* establish a dialog - *if* it is=20 > >>>> received by the UAC. In that case the UAC knows a dialog=20 > has been=20 > >>>> established, but the UAS does not. > >>>> > >>>> So, if a UAC receives an unreliable provisional that > >> contains a tag > >>>> it could potentially then send an UPDATE within that dialog. > >>>> > >>>> But when the UAS sends that unreliable provisional, since > >> it doesn't > >>>> know for sure that a dialog has been established, it can't > >> yet send > >>>> an UPDATE. If it did send one, and the provisional had=20 > been lost,=20 > >>>> then the UAC would not be able to associate the UPDATE > >> with a dialog, > >>>> and it would fail. > >>>> > >>>> Paul > >>>> > >>>> Christer Holmberg (JO/LMF) wrote: > >>>>> Hi, > >>>>> > >>>>>>> Can someone enlighten me as to why UPDATE isn't equally > >>>> acceptable > >>>>>>> for > >>>>>>> transporting an SDP offer as reliable 18x/PRACK? > >>>>>> Well, you really need the reliable 18x to establish a dialog.=20 > >>>>> I don't want to argue against you on that, but I HAVE heard > >>>> opinions > >>>>> saying that you do not need a reliable response in order to > >>>> establish > >>>>> a dialog. > >>>>> > >>>>> Also, chapter 12.1 of RFC3261 does say the following: > >>>>> > >>>>> "Dialogs are created through the generation of non-failure > >>>> responses > >>>>> to requests with specific methods. Within this > >> specification, only > >>>>> 2xx and 101-199 responses with a To tag, where the request > >>>> was INVITE, > >>>>> will establish a dialog. A dialog established by a > >>>> non-final response > >>>>> to a request is in the "early" state and it is called an early=20 > >>>>> dialog." > >>>>> > >>>>> Note that the text only talks about non-failure responses > >> (2xx and > >>>>> 101-199), not reliable responses (reliable provisional responses > >>>>> (101-199) are not even defined in 3261). > >>>>> > >>>>>> If you send the UPDATE prior to a 18x, then the UPDATE would=20 > >>>>>> establish the dialog. You would need to have it carry the=20 > >>>>>> record-route, and all kinds of awful things. > >>>>> Yes, and that is a good reason not to send UPDATE before > >>>> you have sent > >>>>> a reliable response - at least not by the called party.=20 > >>>> But, one could > >>>>> claim that the early dialog may still be established=20 > before that. > >>>>> > >>>>>> A better alternative would be to have a 18x/PRACK without an=20 > >>>>>> offer/answer exchange, followed by an UPDATE from callee > >>>> to caller at > >>>>>> some point in time. I can't think of a reason that > >> wouldn't work, > >>>>>> except that RFC 3261 is pretty clear that the offer is > >> supposed to > >>>>>> come in the first reliable response. So, omitting one=20 > in the 18x=20 > >>>>>> would probably seriously confuse most implementations. > >>>>> This is related to the discussion about the MUST to send an > >>>> offer in > >>>>> the first reliable 18x. It is listed as an issue in the > >>>> offer/answer draft. > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mmusic > >>> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 10 16:56:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4lQ2-0000wb-IZ; Wed, 10 Jan 2007 16:55:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4lQ1-0000wM-4W for mmusic@ietf.org; Wed, 10 Jan 2007 16:55:37 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4lPy-0005rq-ID for mmusic@ietf.org; Wed, 10 Jan 2007 16:55:37 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0ALtPYZ031689 for ; Wed, 10 Jan 2007 16:55:25 -0500 Received: from [135.9.42.38] ([135.9.42.38]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Jan 2007 14:55:24 -0700 Message-ID: <45A560CB.1080309@avaya.com> Date: Wed, 10 Jan 2007 14:55:23 -0700 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2007 21:55:24.0426 (UTC) FILETIME=[08076EA0:01C73502] X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [MMUSIC] Session-level Parameters in Cap Negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org In yesterday's telephone conference on SDP capabilities negotiation, discussion centered on the needs and uses of capability expressions at the session level verses use of those expressions at the media level. Refer to the current draft for definition of attributes not defined in this note. I volunteered to put forward a straw- man set of examples about how this might work - so here's a first cut at it. Comments, suggestions and alternatives are solicited. (We also discussed changing the transport protocol parameter identifier from "p=" to "t=" in the pcfg attribute, but I've left it as "p=" here so it matches the current version of the draft. In addition, the cver attribute may become a special option tag, e.g. cvern, to be used in the creq/csup attributes as a shorthand for "all attributes in version n".) To start, consider the example in Section 2.1 of the draft: v=0 o=- 25678 753849 IN IP4 128.96.41.1 s= c=IN IP4 128.96.41.1 t=0 0 m=audio 3456 RTP/AVP 0 18 a=cver:0 a=cmed:1 audio RTP/AVP 0 18 96 a=ctrpr:1 RTP/SAVP a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=capar:2 a=rtpmap:96 iLBC/8000 a=pcfg: m=1,2|3 p=1 a=1,2 a=pcfg: m=1,2|3 a=2 This SDP represents a conventional offer of PCMU or G729, along with capability attibutes to offer PCMU, G729 and/or iLBC coding, with or without SRTP. Now, if the offeror wishes to offer RTP/SAVP or RTP/AVP with different payload types so that it may easily decide whether or not to render early media before it has received the other party's transmit key, for example, then it can send the following offer: v=0 o=- 25678 753849 IN IP4 128.96.41.1 s= c=IN IP4 128.96.41.1 t=0 0 m=audio 3456 RTP/AVP 0 18 a=cver:0 a=cmed:1 audio RTP/AVP 0 18 96 a=cmed:4 audio RTP/SAVP 97 98 99 a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=capar:2 a=rtpmap:96 iLBC/8000 a=capar:3 a=rtpmap:97 PCMU/8000 a=capar:4 a=rtpmap:98 G729/8000 a=capar:5 a=rtpmap:99 iLBC/8000 a=pcfg: m=4,5|6 a=1,3,4,5 a=pcfg: m=1,2|3 a=2 This type of solution will also be required in cases where multiple media streams carry the same encoding(s) but separation by payload type is desired. Now, consider what might happen if the cap negotiation attributes are permitted to appear at the session level. This has a couple of potential advantages: 1. Attributes may be reused in multiple media streams. 2. Stream configurations may be presented for future use independent of any stream in the present offer. 3. The resulting SDP may be more compact. Here's an example similar to the above, but with the encrypted media stream offer left for a future negotiation, and a second (unencrypted) audio stream using iLBC only. The second channel has the cap negotiation elements at the media level since they're not reused. v=0 o=- 25678 753849 IN IP4 128.96.41.1 s= c=IN IP4 128.96.41.1 t=0 0 a=cver:0 a=cmed:1 audio RTP/AVP 0 18 96 a=ctrpr:1 RTP/SAVP a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=capar:2 a=rtpmap:96 iLBC/8000 a=pcfg: m=1,2|3 p=1 a=1,2 m=audio 3456 RTP/AVP 0 18 a=pcfg: m=1,2|3 a=2 m= audio 3458 RTP/AVP 0 a=cmed:4 audio RTP/AVP 97 a=capar: a=rtpmap:97 iLBC/8000 a=pcfg: m=4 a=3 This illustrates a problem with payload formats versus RTP payload types. Ideally, the media lines (or at least the cmed attributes) should describe the payload format(s) and the RTP payload types should be defined within each media stream. One proposal is to specify the cmed lines using mime subtypes, with a new attribute for mapping from mime subtype to payload type at the media level. Here's the previous example with that change, as well as a second option for the first media stream. We've defined a new cap negotiation attribute called cptmap to carry the PT mapping, and a cmed parameter, ptm, to specify the mapping attribute(s) to use: v=0 o=- 25678 753849 IN IP4 128.96.41.1 s= c=IN IP4 128.96.41.1 t=0 0 a=cver:0 a=cmed:1 audio RTP/AVP pcmu/8000 g729/8000 ilbc/8000 a=ctrpr:1 RTP/SAVP a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 a=pcfg: m=1,2|3 p=1 a=1,2 m=audio 3456 RTP/AVP 0 18 a=cptmap:1 0=pcmu 18=g729 96=ilbc a=pcfg: m=1,2|3 ptm=1,2|3 a=pcfg: m=3 ptm=3 <- iLBC-only option, with PT=96. m= audio 3458 RTP/AVP 0 a=cptmap:4 97=ilbc a=pcfg: m=4 a=3 ptm=4 Note that cptmap is not needed for latent pcfg lines - the mapping will be specified, if necessary, when/if a media stream using the capability is actually offered. Note that we have avoided the use of rtpmap attributes by including their content in the cmed line, but we've ignored the use of fmtp attributes, leaving them to the media level. Rather than use the mime subtypes explicitly, we could revert to the use of the "default" payload types in cmed attributes, as in the m= lines. But, when the lines appear at the session level, we would interpret the payload types as media formats only (with the help of rtpmap attributes for codecs with no fixed payload type.) RFC 4566 specifies the rtpmap attribute as a media-level-only parameter, hence it may be necessary to merge the rtpmap information into the cmed line. If we do this, the cmed:1 line in the above example could become something like a=cmed:1 audio RTP/AVP 0 18 96:iLBC/8000 A cptmap attribute could still be used to map the media types to specific payloads for each media stream, if necessary. In this case (from the above example), it could take a form something like a=cptmap:1 97=96 in the second media stream (it's not needed in the first stream since the "default" payload type is used. Clearly, this could use better punctuation. So as to avoid an ordering problem with fmtp attributes, I'd suggest they must use the PT numbers that appear in the cmed and/or media lines, not the mapped-to PTs. The ability to map payload types could prove useful outside of the capability negotiation realm, but it's not necessary. The same effect can be achieved with the use of an rtpmap line per payload with little extra cost. Comments, suggestions, and alternatives are welcome. -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 10 17:20:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4lnq-0006vn-GJ; Wed, 10 Jan 2007 17:20:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4lnp-0006vi-0v for mmusic@ietf.org; Wed, 10 Jan 2007 17:20:13 -0500 Received: from [63.110.43.12] (helo=mail.covergence.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4lnn-0000We-Pv for mmusic@ietf.org; Wed, 10 Jan 2007 17:20:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2007 17:20:05 -0500 Message-ID: <0D1719326D64BD4E9F92A0C120237678018B988B@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mmusic-media-loopback-05 comments Thread-Index: Acc1BXrzhL/RXT46SAG79sLul/z1eA== From: "Rick Porter" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [MMUSIC] draft-ietf-mmusic-media-loopback-05 comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Here are a few comments/questions... 1. Where does SRTP encryption/decryption come when doing packet loopback? For media loopback, you obviously need to decrypt any encrypted packets. If you're on a link that "always" does SRTP, I would think that you'd want to be able to see how much jitter/loss/latency is introduced by encryption/decryption and possibly compare plaintext/encrypted performance. 2. Should looped back packets go thru the jitter buffer on the mirror? If they do not, the jitter for a call will be compounded. If they do, the latency is increased--depending on implementation, you may be able to subtract jitter-buffer delay if the inner timestamp portion of the encapsulated packet is set to the received timestamp (instead of simply repeating the RTP timestamp).=20 3. Can we reduce SDP to have a single media-description, even when mirror initially sends packets? I think the session should only have one media stream, and the second media-description/stream may confuse non-loopback aware devices who handle the media (e.g. SBCs). 4. With packet loopback, can/should the mirror truncate the last 16 bytes of RTP payload to preserve RTP characteristics? In many situations, I think the RTP header should be sufficient for processing. However, I do see some situations where a device in the middle could potentially transcode RTP packets so that the mirror does not receive the original RTP and it may be desirable to have the whole RTP payload.=20 Cheers, Rick _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 11 12:14:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53VX-0008PQ-87; Thu, 11 Jan 2007 12:14:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53VW-0008OF-8F for mmusic@ietf.org; Thu, 11 Jan 2007 12:14:30 -0500 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53VT-0004tu-0F for mmusic@ietf.org; Thu, 11 Jan 2007 12:14:30 -0500 Received: by wx-out-0506.google.com with SMTP id h31so526116wxd for ; Thu, 11 Jan 2007 09:14:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=l2hnMFJEC3YNOKocssiEUL/MXhQ+Kf1AnsokSuMd85i3oAX0tMbJ/yBkGq1uS81LB40IT+lI3PpSiMp+Ty4ScyGHCVprZ1537Pw+p3yb72O7d2az+cdTgTG6c8miQYJ3pCG2qF3Geb2tqH/sM46z9X9Kygnulcv50a2mAU3PRag= Received: by 10.90.113.20 with SMTP id l20mr1217420agc.1168535666859; Thu, 11 Jan 2007 09:14:26 -0800 (PST) Received: by 10.90.98.17 with HTTP; Thu, 11 Jan 2007 09:14:26 -0800 (PST) Message-ID: <458913680701110914x57202096tb1472919d8cca7eb@mail.gmail.com> Date: Thu, 11 Jan 2007 18:14:26 +0100 From: "Xavier Marjou" To: "Magnus Westerlund" Subject: Re: ICE-for-RTSP? (was Re: [MMUSIC] RTSP: Integrated SETUP vs SIP/SDP Offer/answer) In-Reply-To: <457D57FA.2010901@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45795B61.6080607@ericsson.com> <457D57FA.2010901@ericsson.com> X-Google-Sender-Auth: 7cb1c405d1cdc7d9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Ross Finlayson , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > 1/ ICE-for-RTSP could, in principle, be designed to work for RTSP 1.0 > (and RTSP 2.0), with no changes to either. > >> 2/ ICE-for-RTSP could, in principle, be designed to work for RTSP 2.0, > with no changes (but not for RTSP 1.0). > > 3/ ICE-for-RTSP could, in principle, be designed to work for RTSP 2.0, > but requiring some small additional changes to RTSP 2.0. > > 4/ ICE-for-RTSP could not be designed to work for RTSP 2.0 without > significant changes, so therefore it would make more sense to wait > for a future "RTSP 3.0" (using SIP offer/answer), so that we could > use more of the existing ICE-for-SIP work. Alternatives 1/, 2/, and 3/ are evolutions in the RTSP protocol that will "only" help negotiating NAT traversal for audio and video streams. Alternative 4/ would help negotiating NAT traversal not only for audio and video streams, but also for the RTSP stream. Today, with RTSP 1.0 or 2.0, the main limitation is that an RTSP server located behind a NAT can not be accessed (default case) or can be accessed by anybody (if the RTSP port has been open on the NAT). With 4/, we could create a "conditional access" to an RTSP server. Let's consider the following use-case: a user A wants to be the only person who can access his streaming server located at his home B behind a residential NAT. The mechanism would be the following: The streaming server B is made of an RTSP server and of a SIP UA with a SIP outbound connection. User A sends a SIP INVITE in order to reach server B, and also in order to propose an SDP offer for a session with an RTSP stream. B can accept or reject the INVITE, possibly based on the Identity of A. In case B accepts the INVITE, B sends a TCP-SYN towards A to open an "RTSP" TCP binding "its" front-end NAT. The RTSP client of user A can thus open the TCP connection with the RTSP server, as the NAT could then be traversed. I think it should be possible to allow this in the context of sip-rtsp convergence and RTSP 2.0, although some few details would need to be discussed. Cheers, Xavier PS: Although out-of-scope, one could also think about "HTTP" instead of "RTSP" ;-) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 11 12:47:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5418-00020A-Jz; Thu, 11 Jan 2007 12:47:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5416-000204-UQ for mmusic@ietf.org; Thu, 11 Jan 2007 12:47:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5415-0002Q2-KF for mmusic@ietf.org; Thu, 11 Jan 2007 12:47:08 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 11 Jan 2007 09:47:07 -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/8.12.11) with ESMTP id l0BHl64P030925 for ; Thu, 11 Jan 2007 09:47:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0BHkwV6004445 for ; Thu, 11 Jan 2007 09:47:05 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:46:52 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:46:52 -0800 Message-ID: <45A6780B.8040608@cisco.com> Date: Thu, 11 Jan 2007 12:46:51 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 17:46:52.0666 (UTC) FILETIME=[7A572DA0:01C735A8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1201; t=1168537626; x=1169401626; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20suggested=20ICE=20terminology=20change |Sender:=20; bh=mEZn9+zTTACmJ4141l5VhFso859FcIbiv4S9ow5P12Y=; b=EBRc2Gaf6pdQZSweuUpjjwXXk0qleWu2NGqm4zVEz2r0WR4fmdFpy4JkIqt5ZneZ7h1Eu/iB M/6UsvVo3OBsI0V6drgSX79+FFZypGLsImr948pxnuuYgeq4an/ZrFVS; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [MMUSIC] suggested ICE terminology change X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I'm working on ICE-13 today (finally - my apologies for the extreme lateness on this...). As I incorporate changes, I think we need to make another tweak to terminology. In a previous note, ekr had pointed out that there were really two types of endpoints (full-mode and passive-only), and three modes of operation (controlling, controlled, and passive). I'd like to abandon the term 'passive' in favor of 'reactive'. The main reason is that passive has defined meaning for things like tcp, and ice-tcp will be very ugly when it talks about how a passive ICE agent is active or passive in the TCP sense. Yuck. So, the two types of endpoints would be full-mode and reactive-only, and the three modes would be controlling, controlled, and reactive. I'll go ahead and make this change unless the group feels strongly otherwise. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 11 13:33:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54jN-0001Xe-Ij; Thu, 11 Jan 2007 13:32:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54jM-0001X6-Vo for mmusic@ietf.org; Thu, 11 Jan 2007 13:32:52 -0500 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H54jJ-0004HC-Jc for mmusic@ietf.org; Thu, 11 Jan 2007 13:32:52 -0500 Received: from source ([192.150.11.134]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Thu, 11 Jan 2007 10:32:46 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l0BITYvV014349; Thu, 11 Jan 2007 10:29:38 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l0BIWceE017185; Thu, 11 Jan 2007 10:32:40 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 10:32:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] suggested ICE terminology change Date: Thu, 11 Jan 2007 10:32:20 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D221414F2@namail5.corp.adobe.com> In-Reply-To: <45A6780B.8040608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] suggested ICE terminology change Thread-Index: Acc1qK8HPwMkcicITuueMWfcFfNMIwABhwIg From: "Henry Sinnreich" To: "Jonathan Rosenberg" , "IETF MMUSIC WG" X-OriginalArrivalTime: 11 Jan 2007 18:32:40.0116 (UTC) FILETIME=[DFF2C740:01C735AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Excellent! Thanks, Henry -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Thursday, January 11, 2007 9:47 AM To: IETF MMUSIC WG Subject: [MMUSIC] suggested ICE terminology change I'm working on ICE-13 today (finally - my apologies for the extreme=20 lateness on this...). As I incorporate changes, I think we need to make=20 another tweak to terminology. In a previous note, ekr had pointed out that there were really two types of endpoints (full-mode and passive-only), and three modes of operation=20 (controlling, controlled, and passive). I'd like to abandon the term=20 'passive' in favor of 'reactive'. The main reason is that passive has=20 defined meaning for things like tcp, and ice-tcp will be very ugly when=20 it talks about how a passive ICE agent is active or passive in the TCP=20 sense. Yuck. So, the two types of endpoints would be full-mode and reactive-only, and the three modes would be controlling, controlled, and reactive. I'll go ahead and make this change unless the group feels strongly=20 otherwise. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 11 18:03:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58wR-00073l-7N; Thu, 11 Jan 2007 18:02:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58wP-00073a-Mi for mmusic@ietf.org; Thu, 11 Jan 2007 18:02:37 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58wO-0006B6-PB for mmusic@ietf.org; Thu, 11 Jan 2007 18:02:37 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 11 Jan 2007 15:02:36 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0BN2ZBM009608 for ; Thu, 11 Jan 2007 15:02:35 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0BN2ZUw023627 for ; Thu, 11 Jan 2007 15:02:35 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 15:02:35 -0800 Received: from [10.21.89.214] ([10.21.89.214]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 15:02:35 -0800 Message-ID: <45A6C209.50306@cisco.com> Date: Thu, 11 Jan 2007 18:02:33 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 11 Jan 2007 23:02:35.0287 (UTC) FILETIME=[9505C270:01C735D4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15862; t=1168556555; x=1169420555; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotation=3A=20Minutes=20of=201/9/07=20de sign=20team=20conference=0A=20call |Sender:=20; bh=8wXWUVHKQjZB3HwJvWY3e4vGXZ1aGi6ig6jvnuDxyFg=; b=qfwOfjDG4yIsu8uoprETBboLlMsP1nntHZyd+qKrpxfb/u+GDFrpuShF4i+H/rEPD0my/HHg C/Nhcw4lZ71ksXsZS7pcrjxA19RO4yYHlnT9TcP5RfWy3r3Hu4VNfkdQ; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Subject: [MMUSIC] SDP Capability Negotation: Minutes of 1/9/07 design team conference call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0504337799==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0504337799== Content-Type: multipart/alternative; boundary="------------090800060409020201010603" This is a multi-part message in MIME format. --------------090800060409020201010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings The SDP Capability Negotiation Design team had a conference call on 1/9/07. The attendees were: Flemming Andreasen Matt Lepinski Cullen Jennings Bob Gilman Thomas Stach Roni Even Colin Perkins The focus of the call was to discuss the current SDP Capability Negotiation solution document (draft-ietf-mmusic-sdp-capability-negotiation-00.txt). There was general consensus within the design team on the direction the solution is taking and hence the team agreed to move forward based on solution proposed in the document. The team then moved on to discuss the following open issues: 1) Version indication and semantics 2) Option tags outside of SDP Capability Negotiation 3) Reliance on attribute order 4) Session versus media-level capabilities 1) Version indication and semantics The current draft defines a "cver" attribute to indicate the version of the SDP capability negotiation framework being used. Questions had been raised about how this would actually work outside of the currently defined version 0, since there is no ability to indicate multiple versions or procedures for what to do. The team discussed different approaches to dealing with version negotiation, ranging from the current text, which provides only a way to indicate the currently used version and then reject in case of version mismatch, to more sophisticated approaches allowing for version negotiation. Colin felt it was important to preseve simplicity. Bob Gilman suggested we should rather use the option-tag mechanism (with csup/supported and creq/require) to convey version information as that would provide for some level of graceful backwards compatibility. This seemed to bring the best of both worlds and team agreed to pursue that path. The "cver" attribute will thus be removed and an option-tag for version 0 defined. 2) Option tags outside of SDP Capability Negotiation The document notes that the option tag mechanism defined for the SDP Capability Negotiation would be generally useful for SDP, and hence the scope of the mechanism could be enhanced. The team asked Colin for guidance as a chair, and Colin expressed a preference for limiting the scope to SDP capability negotiation, since there is an urgent need to produce a solution for this, and enhanced scope will only serve to delay it. The team agreed with this and hence the scope of the option-tags will remain as-is. 3) Reliance on attribute order Currently, some attributes (e.g. "pcfg" for potential configurations") rely on the order in which they are provided to express their order of preference. The document notes this as a potential concern with middle-boxes that may reorder attributes at the session-level or within a particular media stream. Such reordering would be problematic. The team felt, that it was entirely possible that such middle-boxes exist (i.e. entities that reorder attributes they do not understand, but otherwise pass them through unmodified) and hence the solution should avoid ordering dependencies. For the "pcfg" attribute, this implies that an explicit ordering indication must be added. Any other attributes with ordering requirements must be updated accordingly too. 4) Session versus media-level capabilities This is the most complicated problem in the current solution document and the team spent a significant amount of time discussing it. The structure and format of media capabilities in the current proposal is based on the SDP "m=" line. This implies that we have payload types (with media-level scope) that need to be accompanied by rtpmaps and possibly fmtp attributes for RTP-based transport protocols, whereas other transport protocols may use a different format. MSRP for example specifies "m=message 7654 TCP/MSRP *" whereas other media formats (such as T.38 over UDP) uses a MIME type/subtype structure (e.g. instead of "message/*"). This lack of a universal format and interpretation of media formats in the "m=" line is in large part what drove the desire to reuse the existing format (easier development and no need for additional specification of how to represent media formats in SDP Capability Negotiation - just use the "m=" line format). Discussion on this particular item lead to the conclusion that SDP actually intended for the media format to be an actual MIME type (the subtype specifically) with the only exception to this rule being RTP-based transport protocols (which instead use payload formats). The team agreed to ask the MSRP authors if they can change the current MSRP representation in SDP accordingly. Use of payload types in media capabilities at the session level (or between media streams) has the problem that payload type mappings are media stream specific. For example, payload type 96 may be mapped to "G729" in one media stream, and "H264" in another media stream. When used at the session level or between media streams, we therefore run into potential issues with overlap between streams. Given the current complexitites in this area, the discussed whether we actually need to support media stream capabilities at the session level (and/or between media streams). There are two motivations for doing so: 1) Allows for smaller SDP since media capabilities for a particular media format will never have to be included more than once. Potential configurations (at the session level and/or in more than media stream) can then reference the globally defined media capability. 2) Allows us to actually express media capabilites and potential configurations at the session level which enables us to indicate additional media streams supported, but not offered currently. Due to real-life UDP limitations, it was felt that message size cannot be ignored, and hence that motivation stands. Similarly, several design team members believed it was important to allow for potential configurations at the session level as well. The team then discussed three different options for how to actually support this: A) Have media capabilites always use MIME types. In the case of RTP-based transports, a mapping to payload types will then be part of the actual configuration. The existing "m=" lines will still remain as-is. B) Use payload types at the session level with clear grouping of parameters to their associated latent "m=" line. Two suboptions here: B1) Allow sesssion-level capabilities to be used at the media level (for efficiency) and define rules to deal with potential inconsistencies B2) Do not allow them to be used at the media level (simpler, but more verbose). C) Use "m=" line with a port set to zero if you want to offer latent media stream capabilities. The team did not conclude on which option would be preferred, in large part because the complexities and issues associated with each were not well understood. The team therefore agreed to outline a solution for each of the three options and base further discussion on that. Bob Gilman graciously volunteered to do this before the next call (which will take place on 1/17 at the usual time). Thanks -- Flemming --------------090800060409020201010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

The SDP Capability Negotiation Design team had a conference call on 1/9/07. The attendees were:

    Flemming Andreasen
    Matt Lepinski
    Cullen Jennings
    Bob Gilman
    Thomas Stach
    Roni Even
    Colin Perkins

The focus of the call was to discuss the current SDP Capability Negotiation solution document  (draft-ietf-mmusic-sdp-capability-negotiation-00.txt).

There was general consensus within the design team on the direction the solution is taking and hence the team agreed to move forward based on solution proposed in the document. The team then moved on to discuss the following open issues:

1) Version indication and semantics
2) Option tags outside of SDP Capability Negotiation
3) Reliance on attribute order
4) Session versus media-level capabilities


1) Version indication and semantics
The current draft defines a "cver" attribute to indicate the version of the SDP capability negotiation framework being used. Questions had been raised about how this would actually work outside of the currently defined version 0, since there is no ability to indicate multiple versions or procedures for what to do.

The team discussed different approaches to dealing with version negotiation, ranging from the current text, which provides only a way to indicate the currently used version and then reject in case of version mismatch, to more sophisticated approaches allowing for version negotiation. Colin felt it was important to preseve simplicity. Bob Gilman suggested we should rather use the option-tag mechanism (with csup/supported and creq/require) to convey version information as that would provide for some level of graceful backwards compatibility. This seemed to bring the best of both worlds and team agreed to pursue that path.

The "cver" attribute will thus be removed and an option-tag for version 0 defined.

2) Option tags outside of SDP Capability Negotiation
The document notes that the option tag mechanism defined for the SDP Capability Negotiation would be generally useful for SDP, and hence the scope of the mechanism could be enhanced. The team asked Colin for guidance as a chair, and Colin expressed a preference for limiting the scope to SDP capability negotiation, since there is an urgent need to produce a solution for this, and enhanced scope will only serve to delay it. The team agreed with this and hence the scope of the option-tags will remain as-is.


3) Reliance on attribute order
Currently, some attributes (e.g. "pcfg" for potential configurations") rely on the order in which they are provided to express their order of preference. The document notes this as a potential concern with middle-boxes that may reorder attributes at the session-level or within a particular media stream. Such reordering would be problematic.

The team felt, that it was entirely possible that such middle-boxes exist (i.e. entities that reorder attributes they do not understand, but otherwise pass them through unmodified) and hence the solution should avoid ordering dependencies. For the "pcfg" attribute, this implies that an explicit ordering indication must be added. Any other attributes with ordering requirements must be updated accordingly too.


4) Session versus media-level capabilities
This is the most complicated problem in the current solution document and the team spent a significant amount of time discussing it. The structure and format of media capabilities in the current proposal is based on the SDP "m=" line. This implies that we have payload types (with media-level scope) that need to be accompanied by rtpmaps and possibly fmtp attributes for RTP-based transport protocols, whereas other transport protocols may use a different format. MSRP for example specifies "m=message 7654 TCP/MSRP *" whereas other media formats (such as T.38 over UDP) uses a MIME type/subtype structure (e.g. instead of "message/*"). This lack of a universal format and interpretation of media formats in the "m=" line is in large part what drove the desire to reuse the existing format (easier development and no need for additional specification of how to represent media formats in SDP Capability Negotiation - just use the "m=" line format). Discussion on this particular item lead to the conclusion that SDP actually intended for the media format to be an actual MIME type (the subtype specifically) with the only exception to this rule being RTP-based transport protocols (which instead use payload formats). The team agreed to ask the MSRP authors if they can change the current MSRP representation in SDP accordingly.

Use of payload types in media capabilities at the session level (or between media streams) has the problem that payload type mappings are media stream specific. For example, payload type 96 may be mapped to "G729" in one media stream, and "H264" in another media stream. When used at the session level or between media streams, we therefore run into potential issues with overlap between streams.

Given the current complexitites in this area, the discussed whether we actually need to support media stream capabilities at the session level (and/or between media streams). There are two motivations for doing so:
1) Allows for smaller SDP since media capabilities for a particular media format will never have to be included more than once. Potential configurations (at the session level and/or in more than media stream) can then reference the globally defined media capability.
2) Allows us to actually express media capabilites and potential configurations at the session level which enables us to indicate additional media streams supported, but not offered currently.

Due to real-life UDP limitations, it was felt that message size cannot be ignored, and hence that motivation stands. Similarly, several design team members believed it was important to allow for potential configurations at the session level as well.

The team then discussed three different options for how to actually support this:
A) Have media capabilites always use MIME types. In the case of RTP-based transports, a mapping to payload types will then be part of the actual configuration. The existing "m=" lines will still remain as-is.
B) Use payload types at the session level with clear grouping of parameters to their associated latent "m=" line. Two suboptions here:
B1) Allow sesssion-level capabilities to be used at the media level (for efficiency) and define rules to deal with potential inconsistencies
B2) Do not allow them to be used at the media level (simpler, but more verbose).
C) Use "m=" line with a port set to zero if you want to offer latent media stream capabilities.

The team did not conclude on which option would be preferred, in large part because the complexities and issues associated with each were not well understood. The team therefore agreed to outline a solution for each of the three options and base further discussion on that. Bob Gilman graciously volunteered to do this before the next call (which will take place on 1/17 at the usual time).


Thanks

-- Flemming



















--------------090800060409020201010603-- --===============0504337799== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0504337799==-- From mmusic-bounces@ietf.org Sat Jan 13 14:49:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5osa-0005SV-2R; Sat, 13 Jan 2007 14:49:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5osZ-0005Rd-2E for mmusic@ietf.org; Sat, 13 Jan 2007 14:49:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5osX-0004zO-Pd for mmusic@ietf.org; Sat, 13 Jan 2007 14:49:27 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 13 Jan 2007 11:49:25 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0DJnPSq020759 for ; Sat, 13 Jan 2007 11:49:25 -0800 Received: from [192.168.1.5] (sjc-vpn2-444.cisco.com [10.21.113.188]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0DJl9ht018475 for ; Sat, 13 Jan 2007 11:49:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: MMUSIC WG From: Cullen Jennings Date: Sat, 13 Jan 2007 11:49:20 -0800 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=439; t=1168717765; x=1169581765; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20New=20RAI=20mailing=20list=20formed=20=20 |Sender:=20; bh=aYF9ifkEszPCZDECS+DKE+Xp7XzOBy9zCsTm4P/L9Jg=; b=UrevG2sT9aOivHz7dnRcNMwrV2O3dQKCBtKvkTghPTUHdfWSbLTrx5iq5YLV/hSuEw0fiZv0 bOtI6aOl2Z3wmaoMFJXKCBkmRA0yZZIWZcNKbFQog/ib3g//reuHQWmX; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [MMUSIC] New RAI mailing list formed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Sorry for the many duplicate posts. A new mailing list for announcement and discussion of general topics of interest to RAI Area has been created. The list is rai@ietf.org You can subscribe at: https://www1.ietf.org/mailman/listinfo/rai Or by sending email with a body containing "subscribe" to rai- request@ietf.org Please do subscribe to it so you can find announcements for things like RAI BOFs. Thanks, Cullen & Jon _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 15 09:02:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6SPp-0002Tl-J6; Mon, 15 Jan 2007 09:02:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6SPo-0002Tg-4a for mmusic@ietf.org; Mon, 15 Jan 2007 09:02:24 -0500 Received: from brixmail.brixnet.com ([63.122.27.37] helo=brixmail.ma.brixnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6SPm-0002Ih-Sw for mmusic@ietf.org; Mon, 15 Jan 2007 09:02:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-05 Date: Mon, 15 Jan 2007 09:02:17 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] draft-ietf-mmusic-media-loopback-05 Thread-Index: AccgVe17c2OFoGapSWG/zjOYNrqtrQJjItUwAjFpFtAAx5G6EA== From: "Hedayat, Kaynam" To: "Mundra, Satish" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Satish, Thank you for the comments. My comments below. Regards, Kaynam=20 > -----Original Message----- > From: Mundra, Satish [mailto:smundra@ti.com]=20 > Sent: Sunday, January 07, 2007 5:22 PM > To: Hedayat, Kaynam > Cc: MMUSIC WG > Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05 >=20 > Hi Kaynam, >=20 > I have following comments on this draft. >=20 > 1. I am not sure if "rtp-start-loopback" mode defined in=20 > section5.2 is necessary. One can always start a session in=20 > normal media processing mode and then change the mode to=20 > loopback as mentioned in section 5.6 of the draft. The=20 > "rtp-start-loopback" seems to be accomplishing the same by=20 > avoiding additional OFFER/ANSWER exchange which will be=20 > needed to move the session to loopback mode in absence of=20 > rtp-start-loopback. =20 This adds the flexibility to start the call with loopback (something that is needed in performance management systems). And with additional OFFER/ANSWER, the requirement to traverse NAT's does not change. The new OFFER/ANSWER can potentially have completely different ports. >=20 > 2. The draft specifies the rules analogous to RFC3264 for the=20 > media formats signaled via the a=3D=3D:=20 > line in SDP. IMO, the OFFER/ANSWER rules specified in RFC3264=20 > are more than sufficient to accomplish the desired=20 > loopback-mirror(OFFERER) and > loopback-source(ANSWERER) behavior > when the "fmt" are signaled via the m=3D line. With source and mirror attributes it is possible for the OFFERER to be mirror (and vice versa). >=20 > 3. I also don't see the need for the attributes=20 > "rtp-pkt-loopback" and "rtp-media-loopback".=20 > The payload formats "audio/encaprtp" and "audio/rtploopback"=20 > are meaningful only when the loopback-mode is mode is=20 > "rtp-pkt-loopback". If "loopback" attribute is present in=20 > answer but answerer chooses to send payload other than one=20 > signaled for "encaprtp" or "rtploopback", then it is implied=20 > that the mode is rtp-media-loopback. For consistency, I think=20 > it's desirable to define audio/medialoopback" for the above=20 > mode. This would allow the selection or negotiation of the=20 > appropriate loopback mode preferences using the payload types=20 > on the m-line following the OFFER/ANSWER rules and would=20 > simplify the implementation.=20 In cases where only media loopback is desired this is needed. >=20 > 4. I think the draft needs to includes Media Type=20 > registration for the RTP payload formats "audio/encaprtp"=20 > and "audio/rtploopback" that are introduced. I will look into it. >=20 >=20 > Regards, >=20 > Satish Mundra=20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 16 15:35:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6v1E-0004jU-LY; Tue, 16 Jan 2007 15:34:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6v1C-0004jI-Pg for mmusic@ietf.org; Tue, 16 Jan 2007 15:34:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6tue-0007Is-4O for mmusic@ietf.org; Tue, 16 Jan 2007 14:24:07 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 16 Jan 2007 11:24:03 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0GJO3Hc028312 for ; Tue, 16 Jan 2007 11:24:03 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0GJNvnb020789 for ; Tue, 16 Jan 2007 11:24:03 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 11:23:34 -0800 Received: from [10.32.241.158] ([10.32.241.158]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 11:23:34 -0800 Message-ID: <45AD2634.9000803@cisco.com> Date: Tue, 16 Jan 2007 14:23:32 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 19:23:34.0230 (UTC) FILETIME=[D0685760:01C739A3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4123; t=1168975443; x=1169839443; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE-13=20has=20arrived! |Sender:=20; bh=PZUmt9X9ZKXuBtkYxK7WZjbXMF+77l0S87/8kwPtoTs=; b=K5WKWgflaoq2CEz38j4WXGnN+z4799V4R7IOfhSlD9kgQZJTwFFk6SfnsdyfgfhbJwT5NrGj d8nkkxmFZ5G4ZMuWV9HZM3yZYevvIwWw/xdElQzc9fipV2u4K4haDBOD; Authentication-Results: sj-dkim-6; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [MMUSIC] ICE-13 has arrived! X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Sorry for the delay in doing this. This was supposed to be done weeks ago. Here you have, finally, ICE-13: http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-13.txt I've submitted it and it should appear in the archives shortly. The draft includes everything we agreed to at the meeting. The only thing not there are the comments from the reviews posted to the list by Jason and Jean-Francois, which are all minor and which I'll address with the rest of the WGLC comments. Here are the specific changes: * changed keepalives to be sent only when there is no other traffic, and changed the format from a Binding Request to Binding Indication. Note that no message integrity is used for these indications. Added a section to the design motivations appendix on why indications are used instead of requests. Spec says you MUST still be prepared to receive and process a Binding Request. * cleanly separated lite and full implementation requirements in the text * updated terminology section with new terms - full lite implementations. Modes are now controlling and controlled, and refer to only a subset of the overall processing of an agent - who selects the final candidates and sends the re-invite * changed the appendix on full/lite. Now, this is a discussion of the applicability of a full vs. lite implementation. The section emphasizes that lite is a stepping stone to a full implementation. * renamed a=ice-passive to a=ice-lite * added a=ice-mismatch attribute. Per agreement at the last meeting, this is used when an answerer receives an offer whose m/c-line did not have a matching candidate attribute. * added requirement that a controlling agent talking to a lite implementation has to do a second check with the USE-CANDIDATE flag once a first without the flag succeeds. THis is what allows us to eliminate triggered checks for lite implementations. * clarified usage guidelines for the STUN reliable 1xx hack. SHOULD use PRACK if available. Only works for certain provisional responses (answers that start ICE). Retransmits cease on 2xx. Lack of Binding Request doesnt terminate session. Answer in 2xx alone allowed but not recommended. * added reference to ICE option and media feature tag spec. SHOULD support it. * Added maximum of 100 connectivity checks as a SHOULD requirement, updated math in the document based on new STUN timers * Added section on SBC and ALG considerations. Interactions with ALG are described. TLS is recommended. Note that ICE doesnt try to fix broken ALG or work around SBC. * Added a new section on extensibility considerations, on how interoperability is addressed with new variations in the ICE algorithm. Added a new ice-options attribute that is like SIP's Supported header field. No IANA registry. Discuss the importance of sending a separate connectivity check with the USE-CANDIDATE flag in achieving interoperability between different protocol versions. ALso the importance of triggered checks. * mentioned other offer/answer exchanges with sip, notably 18x/PRACK and 200/ACK. Recommend the former. * added USE-CANDIDATE attribute to call flows * clarified that an agent can send the USE-CANDIDATE flag after a check has succesfully completed, or before * changed STUN to newly agreed acronym - Session Traversal Utilities for NAT * Requirement strength on the candidate prioritization algorithm is SHOULD, not MUST * corrected bug which was still claiming that bidirectional media is not sent once a candidate is selected by ICE * if an offerer restarts by changing the username/password, the answerer has to change them too -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 16 15:51:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vHH-0006AX-IT; Tue, 16 Jan 2007 15:51:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vHF-00069E-QW for mmusic@ietf.org; Tue, 16 Jan 2007 15:51:29 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vHC-0004Lj-2g for mmusic@ietf.org; Tue, 16 Jan 2007 15:51:29 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3A11E4F0001; Tue, 16 Jan 2007 21:51:15 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 21:51:14 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 21:51:14 +0100 Received: from [131.160.126.58] (rvi2-126-58.lmf.ericsson.se [131.160.126.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8A942236E; Tue, 16 Jan 2007 22:51:13 +0200 (EET) Message-ID: <45AD3ABF.40904@ericsson.com> Date: Tue, 16 Jan 2007 22:51:11 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jonathan Rosenberg References: <45766E40.40306@ericsson.com> <4576D63B.1080203@lucent.com> <459D7E88.2010306@cisco.com> In-Reply-To: <459D7E88.2010306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2007 20:51:14.0199 (UTC) FILETIME=[0F97EA70:01C739B0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Karim El Malki , mmusic , "Vijay K. Gurbani" Subject: [MMUSIC] Re: ICE and IPv6 transition X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, I agree ICE is useful even in the absence of NATs and that every endpoint should implement it. I also agree that even endpoints using ANAT should use ICE. What we have to analyze is the advantage of using ICE on a single m line versus using ICE on each of the two m lines (one for IPv6 and one for IPv4). That is, it is not ANAT vs. ICE. It is an m line per address type vs. a single m line for everything. I believe that having a separate m line per address type is cleaner. However, having separate m lines would keep an IPv6-only host from trying to send data to an IPv4-only host through a NAT-PT. Covering this scenario may justify not using ANAT and using ICE on a single m line instead. Cheers, Gonzalo Jonathan Rosenberg wrote: > Here are my thoughts on this. > > I recall discussing this issue way back when with Gonzalo. We had agreed > that ANAT would be complementary to ICE. ANAT would be used in cases > where you were multihomed with v4 and v6, and not worrying about NAT > traversal per se. ICE added a lot of complexity just to deal with > something as simple as picking the right IP version. Also, ICE had the > problem that it had one address as the primary (in the m/c-line) and the > other candidates were secondary, in candidate lines. We wanted a > solution where both addresses were really equivalently treated. > > Under these assumptions, you would use ANAT when you had both v4 and v6 > public addresses, but public versions of both. If you needed NAT > traversal, you'd use ICE. If you had both v4 and v6 and needed nat > traversal, you'd use both ANAT and ICE. There'd be an m line for v4, one > for v6. ANAT would select which. Then, under the v4 m-line, you'd have > all of your v4 candidates. Under the v6 m-line, all of your v6. Thats > why the ICE spec talks about using ICE to select between native v6 and > 6to4 addresses, for example. > > However, a few things have changed since we originally made that > decision. Firstly, we've seen that even in the absence of NAT traversal, > ICE is valuable (passive mode, voice hammer prevention, keepalive timing > control). Furthermore, ICE's design now treats the m/c-line address as a > fallback for non-ICE endpoints. We also now have an option tag, so you > could use ICE like ANAT gets used; with an option tag so you can do > something different if the far end doesn't support it. > > Another point is, one of the benefits of ICE over ANAT for selection of > v4 vs. v6 is that, you may run into scenarios where both side have v6 > but they turn out to be unconnected; that is, its two phones both > sitting on v6 networks that are not connected together. I don't know how > common it is to have v6 islands unconnected, but it would not surprise > me if this happens every once in a while. > > So, technically, at this point I think ICE is probably able to provide a > superset of ANAT. One option is to recommend ANAT for the simplest case > (no NAT traversal, dual-homed clients with public IP), and then ICE for > anything more. THe problem with that is, from an interop standpoint, ICE > implementations would also need to do ANAT and it would be more > complicated. Plus, having ICE support on devices that aren't interested > in nat traversal per se is critical for allowing the OTHER side to > support nat traversal (this is why we've been pushing passive mode). > I also suspect it will generally be confusing to the industry to have > two specifications that are very similar. > > So, my recommendation would be to have ICE obsolete ANAT when its > published. I don't know if its being used yet at all, which might make > this an issue. > > Thoughts? > > -Jonathan R. > >> Gonzalo Camarillo wrote: >> >>> Hi, >>> >>> the current ICE draft seems to tackle IPv4 and IPv6 candidates for the >>> same media stream. In the past, we developed ANAT to separate them so >>> that a single m line used a single IP version. In particular, the >>> SIPPING IPv6 transition document recommends the use of ANAT. >>> >>> We need to align all these efforts. >> >> >> Probably sooner rather than later if it has any impact on >> the SIPPING IPv6 transition draft, since it has already been WGLCd >> and is in the "Publication Requested" state. >> >> Thanks, >> >> - vijay > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 16 19:08:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6yLn-0005dm-7C; Tue, 16 Jan 2007 19:08:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6yLm-0005dh-Ae for mmusic@ietf.org; Tue, 16 Jan 2007 19:08:22 -0500 Received: from 103.13.152.198.in-addr.arpa ([198.152.13.103] helo=co300216-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6yLj-0004mp-QX for mmusic@ietf.org; Tue, 16 Jan 2007 19:08:22 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0H08IN5006730 for ; Tue, 16 Jan 2007 19:08:18 -0500 Received: from [135.9.42.38] ([135.9.42.38]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Jan 2007 17:08:18 -0700 Message-ID: <45AD68F1.2080402@avaya.com> Date: Tue, 16 Jan 2007 17:08:17 -0700 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 00:08:18.0298 (UTC) FILETIME=[974E3DA0:01C739CB] X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Subject: [MMUSIC] Modified Proposal for Capability Negotiations X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I've been playing with a means to make the cmed attribute line independent of payload types, so it can be use at the session level or media level to define media encodings. These can be combined with transport protocols at the session or media levels, and payload types at the media level. Here's an approach that doesn't simply replicate the existing m-line in a cmed attribute. It builds up the capabilities from mime type/subtypes, encoding parameters, and format parameters. Note that the cenc and cfmt lines are tied directly into the subtypes listed in the cmed line via the subtype ordinal; they are implicitly incorporated in the pcfg attribute by reference to their subtype ordinal(s). One of the advantages of doing this binding early is that an endpoint can offer a particular codec with different format parameters (e.g., G.729 and G.729B). Define/redefine the following new attributes: a=cmed: This line defines the set of codecs supported, and assigns an ordinal to each codec. The codecs are referenced via their ordinals in pcfg or acfg lines (via the m= parameter), and in cenc and cfmt attributes. If the first subtype ordinal is 's', say, the the first mime subtype corresponds to "subtyp s", the next to "s+1", and so on. example: a=cmed:1 PCMU G729 G729 iLBC events ; PCMU=1, G729=2, G729=3 iLBC=4, events=5 a=ctrpr: This line defines the transport protocols/profiles supported; the pcfg line will refer to one of these via "p=" example: a=ctrpr:1 RTP/AVP RTP/SAVP => RTP/AVP=1 RTP/SAVP=2 a=cenc: [/] This line defines encoding attributes for the specified mime subtype. It is effectively incorporated as part of the codec with the specified ordinal. example: a=cenc:4 8000 ;sample rate for iLBC a=cfmt: This line defines format parameters for the specified mime subtype. It is effectively incorporated as part of the codec with the specified ordinal. example: a=cfmt:2 annexb:no ;codec 2 doesn't support comfort noise a=cptmap: : pairs> This line defines the payload type(s) to be used with a particular configuration and referenced via "ptm=". It may only be used by offered configurations, not latent configurations. example: a=cptmap:1 2:99 3:100 ; maps G.729 to PT 99, iLBC to PT 100 The remaining attributes (pcfg, acfg, capar) are defined as in Flemming's draft: . Then we might have an offer like the following. This announces support for 4 audio codecs (G.711mu-law, G.729, G.729B, iLBC) and in-band telephony events for DTMF and Flash. ... (skipping over initial session lines) 1) a=cmed:1 audio PCMU G729 G729 iLBC events 2) a=cenc:4 8000 ;iLBC with 8K sample rate 3) a=ctrpr:1 RTP/AVP RTP/SAVP ;transport profiles 4) a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 5) a=cfmt:2 annexb:no ;no comfort noise for G.729 6) a=cfmt:5 0-15,16 ;DTMF plus flash events 7) a=pcfg:1 m=3,5|4,5 t=1 ;a latent AVP capset 8) a=pcfg:2 m=3,5|4,5 t=2 a=1 ;a latent SAVP capset 9) m=audio 22222 AVT/RTP 0 18 100 ; standard audio line 10) a=rtpmap:100 events 11) a=fmt:100 0-15 12) a=cptmap:1 1:101 2:102 5:103 13) a=pcfg:3 m=1,5|2,5 p=2 a=1 ptm=1 ;(SRTP option) Notes: 1) This cmed line defines a set of audio codecs numbered 1-5. 2) This cenc line defines adds encoding rate information for codec 3. 3) This ctpr line defines two transport profiles numbered 1-2. 4) This capar line defines an SDES crypto attribute. 5) This cfmt line defines format parameters for codec 3 (G.729) 6) This cfmt line defines the telephony event parameters for "codec 5", the telephony events. 7) This pcfg line defines a latent AVP capset with any one of the four audio codecs plus DTMF telephony events. 8) This pcfg line defines a latent SAVP capset with the same combinations of codecs/tlephony events. 9) This is the conventional media line for audio with G.711mu-law, G.729B, and a dynamic payload type. 10) "Traditional" SDP for backward compatibility. 11) "Traditional" SDP for backward compatibility. 9)-11) In case the receiver understands capability negotiation, but wishes to choose the AVT/RTP offer rather than encryption, we define that the m= line defines "pcfg:0", "cptmap:0", transport type "0", and the media codecs are assigned the next codec ordinals following those defined at the session level (codecs defined at the media level via cmed attributes will be numbered following those defined on the m=line). Thus, the m= line and the following rtpmap and fmtp lines are equivalent to: a=cmed:6 PCMU G729 event a=cptmap:0 8:100 a=pcfg:0 m=6,7,8 p=0 ptm=0 Any pcfg: line at the media level may refer to the codecs and transports defined by the current m= line. 12) This line provides the payload types for each cmed codec for this media stream. The payload types are chosen, in this case, so that the receiver can use them to tell which choices the answerer made if media is received by the offeror before the answer arrives. 13) This line specifies an alternative media stream using SRTP. p=2 invokes the second transport protocol (RTP/SAVP) from the ctrpr line. a=1 identifies the SDES crypto attribute ptm=1 identifies the payload map. I've used "1" to identify the entire line, but we could use numbers to identify each mapping, as ptm=1,2,3 Note that there are no references to the cfmt or cenc attributes - they're always attached to their respective media subtypes. Given an offer in the above form, a endpoint that doesn't understand the capneg attributes will respond with the usual m= line and attributes. If the endpoint does understand capneg, it is expected to reply with the m=line and the particular configuration it has chosen in an acfg attribute. If it chooses the unencrypted media as described above with PCMU encoding, it might follow the m= line with a=acfg:0 m=6,8 p=0 ptm=0 In either case, the answering endpoint can include latent configurations as well. In the simple case that the offeror doesn't want to offer any latent media configurations, but does want to offer the SRTP alternative, the SDP could be reduced to the following: ... (skipping over initial session lines) 9) m=audio 22222 AVT/RTP 0 18 100 ; standard audio line 10) a=rtpmap:100 events 11) a=fmt:100 0-15 3) a=ctrpr:1 RTP/SAVP ;transport profile 4) a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 12) a=cptmap:1 1:101 2:102 3:103 13) a=pcfg:1 m=1,3|2,3 p=1 a=1 ptm=1 ;(SRTP option) Line 12, and the ptm=1 parameter in line 13, could be eliminated if the offeror doesn't need to use the payload types to decide early media can be rendered. My apologies for numbering errors, etc. Please reply with any comments, corrections, additions, etc. -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 16 23:47:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H72hX-0008Px-Qm; Tue, 16 Jan 2007 23:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H72hW-0008Pk-3X for mmusic@ietf.org; Tue, 16 Jan 2007 23:47:06 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H72hU-0002Vc-Lo for mmusic@ietf.org; Tue, 16 Jan 2007 23:47:06 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 4D4385C077 for ; Tue, 16 Jan 2007 20:54:58 -0800 (PST) To: mmusic@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 16 Jan 2007 20:47:01 -0800 From: Eric Rescorla Message-Id: <20070117045458.4D4385C077@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8104b3fcabb4d2dfaed548848b9dc80f Subject: [MMUSIC] Review of draft-ietf-mmusic-ice-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org $Id: draft-ietf-mmusic-ice-13-rev.txt,v 1.1 2007/01/16 23:38:58 ekr Exp $ GLOBAL COMMENTS There is a *lot* of new terminology in this document. In my experience glossaries at the beginning really don't help much. Each term should be capitalized on first introduction and come with a definition in context. Wherever possible, we should avoiding new terms that are only used a few times. In S 1-12 there are lots of forward references to stuff that is only defined in S 12. I understand the urge to keep the formal grammar towards the end, but you need to provide some sort of abstract sketch of what's in an offer or answer in order to make this understandable before the definition. Somewhere there needs to be a diagram of the relationship of the various pieces of the system. I.e., addresses, candidates, candidate pairs, checks, check lists, valid lists, etc. Many sections are just run-on descriptions of protocol elements or operational steps. These each need to be broken out with some sort of textual marker (bullets, whitespace, heds, depending on the length of the relevant subsection). For instance, S 4.1.1 reads (in part) An agent gathers candidates when it believes that communications is imminent. An offerer can do this based on a user interface cue, or based on an explicit request to initiate a session. Every candidate is a transport address. It also has a type and a base. Three types are defined and gathered by this specification - host candidates, server reflexive candidates, and relayed candidates. The base of a candidate is the candidate that an agent must send from when using that candidate. The first step is to gather host candidates. Host candidates are obtained by binding to ports (typically ephemeral) on an interface (physical or virtual, including VPN interfaces) on the host. The process for gathering host candidates depends on the transport protocol. Procedures are specified here for UDP. For each UDP media stream the agent wishes to use, the agent SHOULD obtain a candidate for each component of the media stream on each interface that the host has. It obtains each candidate by binding to a UDP port on the specific interface. A host candidate (and indeed every candidate) is always associated with a specific component for which it is a candidate. Each component has an ID assigned to it, called the component ID. For RTP-based media streams, the RTP itself has a component ID of 1, and RTCP a component ID of 2. If an agent is using RTCP it MUST obtain a candidate for it. If an agent is using both RTP and RTCP, it would end up with 2*K host candidates if an agent has K interfaces. The base for each host candidate is set to the candidate itself. Agents SHOULD obtain relayed candidates and MUST obtain server reflexive candidates. The requirement to obtain relayed candidates is at SHOULD strength to allow for provider variation. If they are not used, it is RECOMMENDED that it be implemented and just disabled through configuration, so that it can re-enabled through configuration if conditions change in the future. The agent next pairs each host candidate with the STUN server with Each candidate type should be set off with its own hed. Another example would be S 13: The foundation is composed of one or more ice-char. The component-id is a positive integer, which identifies the specific component for which the transport address is a candidate. It MUST start at 1 and MUST increment by 1 for each component of a particular candidate. The connect-address production is taken from RFC 4566 [10], allowing for IPv4 addresses, IPv6 addresses and FQDNs. The port production is also taken from RFC 4566 [10]. The token production is taken from RFC 3261 [3]. The transport production indicates the transport protocol for the candidate. This specification only defines UDP. However, extensibility is provided to allow for future transport protocols to be used with ICE, such as TCP or the Datagram Congestion Control Protocol (DCCP) [29]. This defines the following productions: - foundation - component-id - connect-address - port - token - transport Each of these should be set off in its own bulleted list. DETAILED COMMENTS S 2. There is a bad break around Figure 1. o It's directly attached network interface (or interfaces in the case of a multihomed machine s/It's/Its/ S 2.1. s/net10/net 10/ the STUN server is configured, or learned in some way.) When the ^ the STUN server is manually configured or learned in some other unspecified way.) When the The formatting around the Note is screwd up. The final type of candidate is a RELAYED candidate. The STUN Relay s/RELAYED candidate/RELAYED CANDIDATE/ Once L has gathered all of its candidates, it orders them highest to s/them highest/them in highest/ S 2.4. You need to introduce the concept of foundation here. S 2.6. "controlling agent" and "controlled agent" should be capitalized on first use. Figure 4 has the third arrow in the wrong relation to its label. You need diagrams of both the mode where the flag is sent after the initial ICE exchange and the aggressive one where it's sent with some message subset. I don't see what the term "favored" is bringing to the party here. In any case, "selected" might be a better state. S 2.7. I'm not sure that this section adds much to the overview. S 3. The definition of "Foundation" seems less than helpful. I would rewrite: Foundation: An arbitrary string that is the same for two candidates that have the same type, base IP address, and STUN server. If any of these are different then the foundation will be different. Two candidate pairs with the same foundation pairs are likely to have similar network characteristics. Foundations are used in the frozen algorithm. The way "check" is used to mean "candidate pair" seems confusing. A check is an action, not an object. S 4.1.1. Each type of candidate should have its own subsection. has a component ID of 1, and RTCP a component ID of 2. If an agent is using RTCP it MUST obtain a candidate for it. If an agent is using both RTP and RTCP, it would end up with 2*K host candidates if an agent has K interfaces. Doesn't this 2*K rule apply to every kind of candidate? Can a TURN server refuse to allocate a port? If so, does that mean you get denied the server-reflexive address as well? In the definition of foundation you should have a list of the criteria, not a para. S 4.1.2. At minimum the rules for each component of the priority formula should go in their own graf. Arguably under their own heds. These rules guarantee that there is a unique priority for each candidate. This priority will be used by ICE to determine the order of the connectivity checks and the relative preference for candidates. Consequently, what follows are some guidelines for selection of these values. This section should go earlier. The region from "One criteria for selection of the type..." to the end of the section is informative. I wonder if it belongs here at all. It certainyl should be its own section. important, the type preference for relayed candidates can be set lower than the type preference for reflexive and host candidates. Indeed, it is RECOMMENDED that in this case, This can be compressed to be "SHOULD be set lower. The value of 126 is recommended..." S 4.1.3. A candidate is said to be "in-use" if it appears in the m/c-line of an offer or answer. When communicating with an ICE peer, being in- That should be a "a current offer or answer", right? If it appears in the m/c line of a previous o/a, then it's not necessarily in-use I would htink. each active media stream, to be in-use. A media stream is active if it does not contain the a=inactive SDP attribute. A reference for a=inactive seems appropriate. Unfortunately ... needed This seems superfluous. Isn't the last graf redundant? S 4.3. This whole section seems problematic. It's full of stuff that only makes sense if you have seen the SDP grammar yet. I would replace it with an abstract discussion of the contents of a candidate in an offer or answer. This will provide enough context for the reader while avoiding the confusing forward references to the grammer. I would also include an example with a brief explanation of how each value was being represented. Why are types optional? When should I include them? Why wouldn't I? S 5.1. I find the first full graf (starting with "If...") very confusing. I would make the following changes to this section: - Make this list a numbered list. - Add the ice=lite criteria from the last para to the list. Have the rest of the section be separate directions about what to do if each constraint is violated... I would make these separate grafs. S 5.2. Based on this definition, once roles are determined for a session, they persist unless ICE is restarted, as discussed below. A restart causes a new selection of roles. "discussed below" should point to somehting. S 5.7. There is one check list... This graf should be moved to S 4 somewhere... It's a concept issue. The remainder of this section is in dire need of heds. You should have a state machine diagram for the check states. I'm not sure it helps to introduce states for a Check List. They're not used that often. I would just replace them with the relevant conditions inline in the text. S 5.8. When the timer fires, the agent MUST find the highest priority check in that check list that is in the Waiting state. The agent then sends a STUN check from the local candidate of that check to the remote candidate of that check. The procedures for forming the STUN request for this purpose are described in Section 7.1.1. If none of the checks in that check list are in the Waiting state, but there are checks in the Frozen state, the highest priority check in the Frozen state is moved into the Waiting state, and that check is performed. When a check is performed, its state is set to In-Progress. If there are no checks in either the Waiting or Frozen state, then the timer for that check list is stopped. Breaking this into bullets would help readability. Performing the connectivity check requires the agent to know the username fragment for the local and remote candidates, and the password for the remote candidate. For periodic checks, the remote username fragment and password are learned directly from the SDP received from the peer, and the local username fragment is known by the agent. And for triggered checks they are...? S 6. Most of these sections say "do what S 5 says". Why do we need this section at all? S 7.1.1. A Binding Request ... a password of APASS. This at least should be in a subsections since it's a detail and doesn't flow well with the rest of the section. I'd put it at the end of 7.1.1. too. An agent MUST include the PRIORITY attribute in its Binding Request. The attribute MUST be set equal to the priority that would be assigned, based on the algorithm in Section 4.1.2, to a peer reflexive candidate learned from this check. peer reflexive candidates are never defined adequately outside the glossary. This is where they're really introduced, so you need a narrative explanation. S 7.1.2. I think it would pay off to explain how you correlate the STUN responses here. Each of the cases described here needs to be broken out in its own subsection. The agent MUST check that the source IP address and port of the response equals the destination IP address and port that the Binding Request was sent to, and that the destination IP address and port of the response match the source IP address and port that the Binding Request was sent from. If these do not match, the processing described in the remainder of this section MUST NOT be performed. In addition, an agent sets the state of the check to Failed. If the check succeeds, processing continues. The agent creates a candidate pair whose local candidate equals the mapped address of the response, and whose remote candidate equals the destination address to which the request was sent. This is called a validated pair, since it has been validated by a STUN connectivity check. It is very important to note that this validated pair will often not be identical to the check itself; in many cases, the local candidate (learned through the mapped address in the response) will be different than the local candidate the request was sent from. OK. This is a really important section but it just sort of flies by. The key points here are: 1. The transport addresses in the UDP must match those you expect. 2. The XOR-MAPPED-ADDRESS attribute may not match. I find this bit about creating a new candidate pair very confusing, since in at least *some* cases this candidate pair will match the one you're doing the check on. Is the notion here that you're creating a new pair and then putting it on the valid list, so you need a copy even if it's the same? If so, that seems unnecessarily prescriptive about implementation. An alternative would be to not maintain a separate valid list and just mark these checks with their own state.... Am I missing something? Once the priority of the candidate pair has been computed, the pair is added to the valid list for that media stream. If the agent was a controlling agent, and the check had included a USE-CANDIDATE attribute, the candidate pair is marked as "favored". If the agent was a controlled agent, and the check was a triggered check, and the request which caused the triggered check included the USE-CANDIDATE attribute, the candidate pair is marked as "favored". Isn't there a race condition here if the periodic check for the candidate precedes the triggered check? PRIORITY attribute of the request. Its foundation is selected as described in Section 4.1.1. The peer reflexive candidate is then added to the list of local candidates known by the agent (though it is not paired with other remote candidates at this time). When is it paired with other remote candidates? unfrozen. If the check had a component ID of one, the agent MUST please be consistent about whether you use "one" or "1" here. Also, please break out the cases in this para.... S 7.2.1. This section needs heds again... Why would something be encapsulated in a Data Indication? If it's relayed, right? Please explain. What's a tentative check? I think it would help to explain upfront why this is tentative. Maybe something to the effect of "In some cases, the receipt of a check requires that the implementation send an immediate "triggered check" in the remote direction..." The list of cases here is flat but the first four cases are one branch and the last case is a separate branch. Some hierarchy here would help. If the tentative check is to be performed, it is constructed and processed as described in Section 7.1.1. But sent immediately, right? S 8. More heds needed again... I don't think the terms "introspective selection" and "proactive selection" add much value here. It's not like they're used a lot later. If you add heds you can refer to the section numbers and give them sort of informal names... You should have a diagram of each of the cases here (or have it in the intro...) S 9.1. An agent MAY change the ice-pwd and/or ice-ufrag for a media stream in an offer. Doing so is a signal to restart ICE processing for that media stream. When an agent restarts ICE for a media stream, it MUST NOT include the a=remote-candidates attribute, since the state of the Why would it occur to me to include this attribute since this is the first the reader has heard of it? I'm trying to wrap my head around the cases here. It seems to me that you would do some kind of ICE restart if: 1. There is a new media session. 2. One of the media sessions has changed, right? 3. You want to change your implementation level so you do a full restart. Maybe you should enumerate these? So the bit about not setting c=0.0.0.0 is sort of a parenthetical, right? Maybe make it a note? S 9.1.1. Need heds again. If a candidate was sent in a previous offer/answer exchange, it SHOULD have the same priority. For a peer reflexive candidate, the priority SHOULD be the same as determined by the processing in Section 7.1.2. The foundation SHOULD be the same. The username fragments and passwords for a media stream SHOULD remain the same as the previous offer or answer. Is the basic concept here that you should replicate previous offers? Maybe say that first.... Again, what does the remote-candidates attribute *do*...? Can you explain the concept somewhere before it's introduced? S 9.2. If the offer contained a change in the a=ice-ufrag or a=ice-pwd attributes compared to the previous SDP from the peer, it is a signal that ICE is restarting for this media stream. "a signal"? Is it the only signal? Is this iff? Can you reduce the last graf to "do whatever the offerer would do..."? S 9.3. If ICE is restarting for a media stream, the agent MUST start a new Valid list for that media stream. However, it retains the old Valid list for the purposes of sending media until ICE processing completes, at which point the old Valid list is discarded and the new one is utilized to determine media and keepalive targets. I'm trying to figure out what the "Valid list" is doing here. Isn't what I need to remember the address pairs I'm sending media on, not the address pairs I might have sent on but decide not to? The valid list seems like too-much information... S 9.3.1. The various subcases need to be broken out with bullets or heds here... S 10. All endpoints MUST send keepalives for each media session. What is the scope of this mandate? Does this update all RTP stacks whether or not they implement ICE? Is HTTP media? used [11]. The Binding Indication SHOULD NOT contain integrity checks; since the messages are simply discarded on receipt regardless of contents. s/; since/as/ media. An agent receipt a Binding Indication MUST discard it s/receipt/receiving/ S 11.1.1. If the state of a media stream is Running, there is no old Valid list s/,/ and/ ? S 12. I wonder if this could all be made an appendix...? It seems kind of orthogonal to ICE per-se. S 13. Each production here needs at least its own graf and should be set off in the text. E.g., foundation - The foundation is composed of... Each attribute should probably hve its own section. S 14. Firstly, ICE provides the a=ice-options SDP attribute. Each s/Firstly/First/ S 15. This example is fairly monolithic and hard to parse. It would be better if the ladder diagram were broken up into pieces (and maybe scattered throughout the text). Then you can present a complete ladder diagram as a worked example. Agents L and R both pair up the candidates. They both initially have two. two pairs, right? However, agent L will prune the pair containing its server reflexive candidate, resulting in just one. At agent L, this pair (the check) has a local candidate of $L_PRIV_1 and remote candidate of $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that an implementation would represent this as a 64 bit integer so as not to lose precision). At agent R, there are two checks. The highest priority has a local candidate of $R_PUB_1 and remote candidate of $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and priority 3.63891E+18. This seems like listing each side's perspective would help. Also, I would render the priorities in hex or decimal, not scientific notation, so it's easy to see what's going on.... S 16.2. force a false valid on a false candidate. This attack is very hard to launch if the false address identifies a third party, and is prevented by SRTP if it identifies the attacker themself. I don't understand this claim. S B.4. The point that the username/password is a disambiguator should be made in the main text. S B.6. This section seems redundant to me. S B.7. Some of this should be promoted to the main text along with an example of how it works. -Ekr _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 17 15:51:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HkC-0005F8-AQ; Wed, 17 Jan 2007 15:50:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hjt-000515-K9; Wed, 17 Jan 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7Hjs-0004r5-9F; Wed, 17 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 30BEE2AD36; Wed, 17 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7HjN-0004Ge-U9; Wed, 17 Jan 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-ice-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-13.txt Pages : 81 Date : 2007-1-17 This document describes a protocol for Network Address Translator (NAT) traversal for multimedia session signaling protocols based on the offer/answer model, such as the Session Initiation Protocol (SIP). This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol, applying its binding discovery and relay usages, in addition to defining a new usage for checking connectivity between peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-ice-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-ice-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-17135031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-17135031.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Jan 18 07:38:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WX5-00022R-QD; Thu, 18 Jan 2007 07:38:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7WX4-00022E-Ko for mmusic@ietf.org; Thu, 18 Jan 2007 07:38:18 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7WX2-0004Rd-6n for mmusic@ietf.org; Thu, 18 Jan 2007 07:38:18 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0ICZkLj026484 for ; Thu, 18 Jan 2007 14:36:02 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 14:37:51 +0200 Received: from esebe104.NOE.Nokia.com ([172.21.143.44]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 14:37:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jan 2007 14:37:52 +0200 Message-ID: In-Reply-To: <45AD2634.9000803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE-13 & Foundation Thread-Index: Acc5rhoHOBhAnaSbTWyJo5ZT99OXaABTPgCg References: <45AD2634.9000803@cisco.com> From: To: X-OriginalArrivalTime: 18 Jan 2007 12:37:51.0602 (UTC) FILETIME=[77E59520:01C73AFD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [MMUSIC] ICE-13 & Foundation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, The draft-ietf-mmusic-ice-13.txt specifies the foundation of a candiate as follows: "Foundation: Each candidate has a foundation, which is an identifier that is distinct for two candidates that have different types, different interface IP addresses for their base, and different IP addresses for their STUN servers. Two candidates have the same foundation when they are of the same type, their bases have the same IP address, and, for server reflexive or relayed candidates, they come from the same STUN server. Foundations are used to correlate candidates, so that when one candidate is found to be valid, candidates sharing the same foundation can be tested next, as they are likely to also be valid." This is otherwise ok, but how come the requirement about having the same STUN server IP address for server reflexive and/or relayed clients? If these are from different network interfaces or if they are otherwise obtained from different networks, that's of course understandable. But if not, then is there any reason why the candidates should be acquired from exactly the same server? The concern is, that this forces the STUN (or TURN) candidates to be acquired from the same server (if we want to get the same foundation). This breaks the possible load balancing enabled by multiple STUN servers listed with DNS (SRV/A/AAAA). Also this forces the candidate gathering to be done in serial. Otherwise we could get candidates from different STUN servers. -- Tomi Kohonen Nokia Corporation _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 19 07:04:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sT4-0007CR-JM; Fri, 19 Jan 2007 07:03:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sT2-00076y-AA; Fri, 19 Jan 2007 07:03:36 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7sT1-0001f8-0S; Fri, 19 Jan 2007 07:03:36 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l0JC3YcV022042; Fri, 19 Jan 2007 13:03:34 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l0JC3XXK002130; Fri, 19 Jan 2007 13:03:33 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 13:03:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C73BC1.D7385145" Date: Fri, 19 Jan 2007 13:03:33 +0100 Message-ID: <72963DDDF17D7949ABD18DC5DA58E77001AC8E5D@MCHP7R5A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New ID, related to media stream dependencies Thread-Index: AcE8+q9WSC0EcqjREdWWxAAADv2DOIv9iK3QAACrAzA= From: "Schmidt, Christian" To: X-OriginalArrivalTime: 19 Jan 2007 12:03:33.0273 (UTC) FILETIME=[D7734090:01C73BC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 Cc: MMusic , Joerg Ott Subject: [MMUSIC] New ID, related to media stream dependencies X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C73BC1.D7385145 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C73BC1.D7385145" ------_=_NextPart_002_01C73BC1.D7385145 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Dear editor, >=20 > we would like to submit a new Internet Draft related to work in the > MMUSIC Working Group (although it is not an official product of the = WG). >=20 > > <>=20 >=20 > Abstract: > The Session Description Protocol (SDP) was intended for describing > multimedia sessions for the purposes of session announcement, session > invitation, and other forms of multimedia session initiation. > Together with Offer/Answer model it defines a mechanism, how two > entities can reach a common view of a multimedia session between > them. >=20 > In certain cases, there are dependencies between media streams, for > example a text stream for subtitling make sense only together with a > video stream. To avoid senseless connections, the SDP mechanism can > be extended with a new Session Description Protocol (SDP) media-level > attribute: "dependency". The "dependency" attribute allows the > offerer to define dependencies of media streams. The updated offer/ > answer mechanism used with new "dependency" attribute can be used > furthermore, that in a multi-party SIP session all participants share > at least one common media type.=20 >=20 > Mit freundlichen Gr=FC=DFen > Christian Schmidt >=20 > Siemens Networks GmbH & Co. KG > St.-Martin-Str. 76 > 81541 M=FCnchen, Germany > Tel.: +49 89 636-75192 > Fax: +49 89 636-75577 > christian-schmidt@siemens.com > =20 > Siemens Networks GmbH & Co. KG > Gesch=E4ftsf=FChrer: Joachim Malterer, Roland Meinzer, Christian = Unterberger > Sitz der Gesellschaft: M=FCnchen > Registergericht: M=FCnchen, HRA 88537 > WEEE-Reg.-Nr. DE 52984304 > Pers=F6nlich haftende Gesellschafterin: Siemens Networks Management = GmbH > Sitz der Gesellschaft: M=FCnchen > Registergericht: M=FCnchen, HRB 163416 > =20 >=20 ------_=_NextPart_002_01C73BC1.D7385145 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New ID, related to media stream dependencies

Dear = editor,

we would like to = submit a new  Internet Draft related to work in the
MMUSIC  Working Group (although it is not an official = product of the WG).

= <<draft-schmidt-mmusic-media-dependency-00.txt>> =

Abstract:
The Session = Description Protocol (SDP) was intended for describing
multimedia = sessions for the purposes of session announcement, session
invitation, = and other forms of multimedia session initiation.
Together = with Offer/Answer model it defines a mechanism, how two
entities = can reach a common view of a multimedia session between
them.

In certain = cases, there are dependencies between media streams, for
example a = text stream for subtitling make sense only together with a
video = stream.  To avoid senseless connections, the SDP mechanism = can
be extended = with a new Session Description Protocol (SDP) media-level
attribute: = "dependency".  The "dependency" attribute = allows the
offerer to = define dependencies of media streams.  The updated = offer/
answer = mechanism used with new "dependency" attribute can be = used
furthermore, that in a multi-party SIP session all participants = share
at least = one common media type.

Mit freundlichen = Gr=FC=DFen
Christian Schmidt

Siemens Networks GmbH = & Co. KG
St.-Martin-Str. = 76
81541 M=FCnchen, = Germany
Tel.: +49 89 = 636-75192
Fax: +49 89 = 636-75577
christian-schmidt@siemens.com
=A0
Siemens Networks = GmbH & Co. KG
Gesch=E4ftsf=FChrer: = Joachim Malterer, Roland Meinzer, Christian Unterberger
Sitz der = Gesellschaft: M=FCnchen
Registergericht: = M=FCnchen, HRA 88537
WEEE-Reg.-Nr. DE = 52984304
Pers=F6nlich = haftende Gesellschafterin: Siemens Networks Management = GmbH
Sitz der = Gesellschaft: M=FCnchen
Registergericht: = M=FCnchen, HRB 163416
 

------_=_NextPart_002_01C73BC1.D7385145-- ------_=_NextPart_001_01C73BC1.D7385145 Content-Type: text/plain; name="draft-schmidt-mmusic-media-dependency-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-schmidt-mmusic-media-dependency-00.txt Content-Disposition: attachment; filename="draft-schmidt-mmusic-media-dependency-00.txt" CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIENoLiBTY2htaWR0CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2llbWVucyBOZXR3b3JrcwpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMTgsIDIwMDcKRXhwaXJl czogSnVseSAyMiwgMjAwNwoKCiAgICAgIFRoZSBTRFAgKFNlc3Npb24gRGVzY3JpcHRpb24gUHJv dG9jb2wpIERlcGVuZGVuY3kgQXR0cmlidXRlCiAgICAgICAgICAgICAgICBkcmFmdC1zY2htaWR0 LW1tdXNpYy1tZWRpYS1kZXBlbmRlbmN5LTAwCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBz dWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhh dCBhbnkKICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBo ZSBvciBzaGUgaXMgYXdhcmUKICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQg YW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2Vk LCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAg IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBO b3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0 cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0 cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9y aWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s LgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdWx5IDIyLCAyMDA3LgoK Q29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNyku CgoKCgoKCgoKCgoKCgoKU2NobWlkdCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjIs IDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg U0RQIERlcGVuZGVuY3kgYXR0cmlidXRlICAgICAgICAgICAgSmFudWFyeSAyMDA3CgoKQWJzdHJh Y3QKCiAgIFRoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIHdhcyBpbnRlbmRl ZCBmb3IgZGVzY3JpYmluZwogICBtdWx0aW1lZGlhIHNlc3Npb25zIGZvciB0aGUgcHVycG9zZXMg b2Ygc2Vzc2lvbiBhbm5vdW5jZW1lbnQsIHNlc3Npb24KICAgaW52aXRhdGlvbiwgYW5kIG90aGVy IGZvcm1zIG9mIG11bHRpbWVkaWEgc2Vzc2lvbiBpbml0aWF0aW9uLgogICBUb2dldGhlciB3aXRo IE9mZmVyL0Fuc3dlciBtb2RlbCBpdCBkZWZpbmVzIGEgbWVjaGFuaXNtLCBob3cgdHdvCiAgIGVu dGl0aWVzIGNhbiByZWFjaCBhIGNvbW1vbiB2aWV3IG9mIGEgbXVsdGltZWRpYSBzZXNzaW9uIGJl dHdlZW4KICAgdGhlbS4KCiAgIEluIGNlcnRhaW4gY2FzZXMsIHRoZXJlIGFyZSBkZXBlbmRlbmNp ZXMgYmV0d2VlbiBtZWRpYSBzdHJlYW1zLCBmb3IKICAgZXhhbXBsZSBhIHRleHQgc3RyZWFtIGZv ciBzdWJ0aXRsaW5nIG1ha2Ugc2Vuc2Ugb25seSB0b2dldGhlciB3aXRoIGEKICAgdmlkZW8gc3Ry ZWFtLiAgVG8gYXZvaWQgc2Vuc2VsZXNzIGNvbm5lY3Rpb25zLCB0aGUgU0RQIG1lY2hhbmlzbSBj YW4KICAgYmUgZXh0ZW5kZWQgd2l0aCBhIG5ldyBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29s IChTRFApIG1lZGlhLWxldmVsCiAgIGF0dHJpYnV0ZTogImRlcGVuZGVuY3kiLiAgVGhlICJkZXBl bmRlbmN5IiBhdHRyaWJ1dGUgYWxsb3dzIHRoZQogICBvZmZlcmVyIHRvIGRlZmluZSBkZXBlbmRl bmNpZXMgb2YgbWVkaWEgc3RyZWFtcy4gIFRoZSB1cGRhdGVkIG9mZmVyLwogICBhbnN3ZXIgbWVj aGFuaXNtIHVzZWQgd2l0aCBuZXcgImRlcGVuZGVuY3kiIGF0dHJpYnV0ZSBjYW4gYmUgdXNlZAog ICBmdXJ0aGVybW9yZSwgdGhhdCBpbiBhIG11bHRpLXBhcnR5IFNJUCBzZXNzaW9uIGFsbCBwYXJ0 aWNpcGFudHMgc2hhcmUKICAgYXQgbGVhc3Qgb25lIGNvbW1vbiBtZWRpYSB0eXBlLgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpTY2htaWR0ICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgSnVseSAyMiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICBTRFAgRGVwZW5kZW5jeSBhdHRyaWJ1dGUgICAgICAgICAgICBKYW51YXJ5IDIw MDcKCgoxLiAgSW50cm9kdWN0aW9uCgogICBUaGUgb3ZlcmFsbCBmcmFtZXdvcmsgZm9yIHRpZ2h0 bHkgY291cGxlZCBTSVAgY29uZmVyZW5jaW5nIGlzIGRlZmluZWQKICAgaW4gUkZDIDQzNTMgWzVd LiAgVGhlIGNvbmZlcmVuY2luZyBhcmNoaXRlY3R1cmUgZGVmaW5lcyB0aGUgY2VudHJhbAogICBj b21wb25lbnQgY2FsbGVkICdmb2N1cycuICBUaGUgZm9jdXMgbWFpbnRhaW5zIGEgU0lQIHNpZ25h bGluZwogICByZWxhdGlvbnNoaXAgd2l0aCBlYWNoIHBhcnRpY2lwYW50IGluIHRoZSBjb25mZXJl bmNlLiAgRWFjaAogICBjb25mZXJlbmNlIGlzIGNvbXBvc2VkIG9mIGEgcGFydGljdWxhciBzZXQg b2YgbWVkaWEgdHlwZXMgdGhhdCB0aGUKICAgZm9jdXMgaXMgbWFuYWdpbmcuICBUaGUgc3RhbmRh cmQgb2ZmZXIvYW5zd2VyIHRlY2huaXF1ZXMgZGVmaW5lZCBpbgogICBSRkMgMzI2NCBbNF0gYXJl IHVzZWQgZm9yIGFkZGluZyBhbmQgcmVtb3ZpbmcgbWVkaWEgdHlwZXMgaW4gdGhlCiAgIGNvbmZl cmVuY2UuICBXaGVuIHRoZSBzZXQgb2YgbWVkaWEgdHlwZXMgaW4gdGhlIGNvbmZlcmVuY2UgY2hh bmdlcywKICAgdGhlIGZvY3VzIHdpbGwgbmVlZCB0byBnZW5lcmF0ZSBhIHJlLUlOVklURSB0byBl YWNoIHBhcnRpY2lwYW50IGluCiAgIG9yZGVyIHRvIGFkZCBvciByZW1vdmUgdGhlIG1lZGlhIHN0 cmVhbXMuICBXaGVuIGEgbWVkaWEgc3RyZWFtIGlzCiAgIGJlaW5nIGFkZGVkLCBhIHBhcnRpY2lw YW50IGNhbiByZWplY3QgdGhlIG9mZmVyZWQgbWVkaWEgc3RyZWFtLCBpbgogICB3aGljaCBjYXNl IGhlIHdpbGwgbm90IHJlY2VpdmUgb3IgY29udHJpYnV0ZSB0byB0aGF0IHN0cmVhbS4KICAgUmVq ZWN0aW9uIG9mIGEgc3RyZWFtIGJ5IGEgcGFydGljaXBhbnQgZG9lcyBub3QgaW1wbHkgdGhhdCB0 aGUgc3RyZWFtCiAgIGlzIG5vIGxvbmdlciBwYXJ0IG9mIHRoZSBjb25mZXJlbmNlLCBvbmx5IHRo YXQgdGhpcyBwYXJ0aWNpcGFudCBpcwogICBub3QgaW52b2x2ZWQgaW4gaXQuCgogICBJbiBzb21l IGNhc2VzLCB0aGVyZSBhcmUgZGVwZW5kZW5jaWVzIGJldHdlZW4gbWVkaWEgc3RyZWFtcy4gIEZv cgogICBleGFtcGxlLCBhIHRleHQtc3RyZWFtIGZvciBzdWJ0aXRsaW5nIG1heSBvbmx5IG1ha2Ug c2Vuc2UgdG9nZXRoZXIKICAgd2l0aCBhIHZpZGVvIHN0cmVhbS4gIEtub3dsZWRnZSBhYm91dCB0 aGVzZSBkZXBlbmRlbmNpZXMgY2FuIGF2b2lkCiAgIHNldHVwIG9mIHNlbnNlbGVzcyBjb25uZWN0 aW9ucy4gIFRoaXMgaW5mb3JtYXRpb24gaXMgbm90IGluY2x1ZGVkIGluCiAgIHRoZSBjdXJyZW50 IFNEUCBzcGVjaWZpY2F0aW9ucy4gIEEgc29sdXRpb24gY291bGQgYmUgYW4gZW5oYW5jZW1lbnQK ICAgb2Ygb2ZmZXIvYW5zd2VyIG1vZGVsIHRoYXQgYWxsb3dzIHRvIHRoZSBvZmZlcmVyIHRvIGlu ZGljYXRlIGluIHRoZQogICBvZmZlciwgdGhhdCBvbmUgbWVkaWEgc3RyZWFtIGNhbiBiZSBhY2Nl cHRlZCBvbmx5IGlmIGFub3RoZXIKICAgZGVwZW5kYW50IG1lZGlhIHN0cmVhbXMgYXJlIGFsc28g YWNjZXB0ZWQuCgogICBUaGUgT2ZmZXIvYW5zd2VyIG1vZGVsIGFzIGRlZmluZWQgbm93IGRvZXMg bm90IGFsbG93IHRvIGRlZmluZQogICBkZXBlbmRlbmNpZXMgYmV0d2VlbiBtZWRpYSBzdHJlYW1z LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYQogICBzb2x1dGlvbiBob3cgdGhlIFNEUCAo ZGVmaW5lZCBpbiBSRkMgNDU2NiBbM10pIGNhbiBiZSBlbmhhbmNlZCB3aXRoIGEKICAgbmV3IGF0 dHJpYnV0ZSB0aGF0IGFsbG93cyB0aGUgZGVmaW5pdGlvbiBvZiBtZWRpYSBkZXBlbmRlbmNpZXMg YW5kCiAgIHRoZSBtYXJraW5nIG9mIG1lZGlhIHN0cmVhbXMgYXMgbWFuZGF0b3J5IG9yIG9wdGlv bmFsLgoKICAgVGhlIGN1cnJlbnQgdHJlYXRtZW50IG9mIG11bHRpbWVkaWEgY29uZmVyZW5jZXMg bWF5IHBvdGVudGlhbGx5IGxlYWQKICAgdG8gbXVsdGktcGFydHkgbXVsdGltZWRpYSBjb25mZXJl bmNlcyB3aGVyZSwgYWZ0ZXIgdGhlIGNvbmZlcmVuY2UgaXMKICAgc2V0IHVwLCBkaWZmZXJlbnQg Y29uZmVyZW5jZSBwYXJ0aWNpcGFudHMgdXNlIGRpZmZlcmVudCwgbm9uCiAgIG92ZXJsYXBwaW5n LCBtZWRpYSB0eXBlIHNldHMgaW4gb25lIGNvbmZlcmVuY2Ugc28gbm8gY29udGVudCBjYW4gYmUK ICAgZGVsaXZlcmVkIHRvIGFsbCB0aGUgY29uZmVyZW5jZSBwYXJ0aWNpcGFudHMuICBBcyBhbiBl eGFtcGxlLCBpZiBvbmUKICAgY29uZmVyZW5jZSB1c2VyIEEgdXNlcyBhdWRpbyB0b2dldGhlciB3 aXRoIHRleHQgbWVzc2FnaW5nLCB1c2VyIEIKICAgdXNlcyBhdWRpbyBvbmx5IGFuZCB1c2VyIEMg dXNlcyB0ZXh0IG1lc3NhZ2luZyBvbmx5LiAgSW4gc3VjaCBhCiAgIGNvbmZpZ3VyYXRpb24sIHRo ZSB1c2VyIEIgY2Fubm90IGNvbW11bmljYXRlIGRpcmVjdGx5IHdpdGggdXNlciBDLAogICB0aGUg aW5mb3JtYXRpb24gZXhjaGFuZ2UgY2FuIGJlIGRvbmUgb25seSB2aWEgdXNlciBBLiBUaGlzCiAg IGNvbmZpZ3VyYXRpb24gY2FuIGJlIGluIHNvbWUgY2FzZXMgdW5kZXNpcmVkLgoKICAgVGhlIHVw ZGF0ZWQgb2ZmZXIvYW5zd2VyIG1lY2hhbmlzbSB1c2VkIHdpdGggbmV3ICJkZXBlbmRlbmN5Igog ICBhdHRyaWJ1dGUgY2FuIGFsc28gYmUgdXNlZCwgdG8gYXZvaWQgdGhpcyBiZWhhdmlvci4gIEl0 IGNvdWxkIGJlCiAgIGFjaGlldmVkLCB0aGF0IGluIGEgbXVsdGktcGFydHkgU0lQIHNlc3Npb24g YWxsIHBhcnRpY2lwYW50cyBzaGFyZSBhdAogICBsZWFzdCBvbmUgY29tbW9uIG1lZGlhIHR5cGUu CgoKClNjaG1pZHQgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDA3ICAgICAg ICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNEUCBEZXBlbmRl bmN5IGF0dHJpYnV0ZSAgICAgICAgICAgIEphbnVhcnkgMjAwNwoKCjIuICBUZXJtaW5vbG9neQoK ICAgSW4gdGhpcyBkb2N1bWVudCwgdGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJS RVFVSVJFRCIsCiAgICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1Qi LCAiUkVDT01NRU5ERUQiLCAiTk9UCiAgIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9O QUwiIGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcwogICBkZXNjcmliZWQgaW4gQkNQIDE0LCBSRkMg MjExOSBbMV0gYW5kIGluZGljYXRlIHJlcXVpcmVtZW50IGxldmVscyBmb3IKICAgY29tcGxpYW50 IGltcGxlbWVudGF0aW9ucy4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgpTY2htaWR0ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAwNyAgICAg ICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTRFAgRGVwZW5k ZW5jeSBhdHRyaWJ1dGUgICAgICAgICAgICBKYW51YXJ5IDIwMDcKCgozLiAgTW90aXZhdGlvbiBm b3IgdGhlIE5ldyBEZXBlbmRlbmN5IEF0dHJpYnV0ZQoKICAgRXZlbiB0aG91Z2ggdGhlIG9yZGVy IG9mICdtJyBsaW5lcyBpbiBvZmZlciBjYW4gYmUgY29uc2lkZXJlZCBhcwogICBwcmVmZXJlbmNl IG9mIHRoZSBvZmZlcmVyLCB0aGUgaGFuZGxpbmcgZGVmaW5lZCBpbiBPZmZlci9BbnN3ZXIgbW9k ZWwKICAgWzRdIGxpbWl0cyB0aGUgdXNhZ2Ugb2Ygc3VjaCBhbiBvcmRlcmVkIGxpc3QuICBBcyB0 aGUgb3JkZXIgb2YgdGhlCiAgIG1lZGlhLWxpbmVzIGluIGFuIG9mZmVyIGNhbm5vdCBiZSBjaGFu Z2VkIGluIHRoZSBzdWJzZXF1ZW50IG9mZmVyIG9mCiAgIHRoZSBzYW1lIFNJUCBzZXNzaW9uLCB0 aGUgbmV3bHkgb2ZmZXJlZCBtZWRpYSBzdHJlYW0gY2Fubm90IGJlIHBsYWNlZAogICB0byB0aGUg cG9zaXRpb24gaW4gdGhlIG9yZGVyZWQgbGlzdCB3aXNoZWQgYnkgdGhlIG9mZmVyZXIuCgogICBU aGUgU0RQIFszXSBhbmQgaXRzIGV4dGVuc2lvbnMgYWxyZWFkeSBkZWZpbmUgc2V2ZXJhbCBhdHRy aWJ1dGVzIHRvCiAgIGJlIHVzZWQgb24gdGhlIG1lZGlhLWxldmVsLCBidXQgbm9uZSBvZiB0aGVt IGlzIGFwcHJvcHJpYXRlIHRvIGJlCiAgIHVzZWQgaW4gdGhlIGNvbnRleHQgb2Ygb3JkZXJpbmcg bWVkaWEgc3RyZWFtcyBiYXNlZCBvbiB0aGUKICAgcHJlZmVyZW5jZXMgb2YgdGhlIG9mZmVyZXIu CgogICBUaGUgbW9zdCBkZXNpcmFibGUgc2VlbXMgdG8gYmUgdGhlICdpJyBsaW5lLCBkZWZpbmVk IGluIFJGQyA0NTY2IFszXSwKICAgdGhhdCBjYW4gYmUgdXNlZCB0byBsYWJlbCBtZWRpYSBzdHJl YW1zIHdpdGggYW55IHRleHQgdmFsdWUsCiAgIGluY2x1ZGluZyB0aGUgbnVtYmVyLiAgTmV2ZXJ0 aGVsZXNzLCB2YWx1ZXMgb2YgdGhlICdpJyBsaW5lIGFyZQogICBpbnRlbmRlZCBmb3IgaHVtYW4g dXNlcnMgYW5kIG5vdCBmb3IgYXV0b21hdGEuICBNb3Jlb3ZlciwgdGhlIHVzYWdlCiAgIG9mICdp JyBsaW5lIGZvciBvdGhlciBwdXJwb3NlIHRoYW4gZGVmaW5pbmcgb2YgbWVkaWEgc3RyZWFtCiAg IGRlcGVuZGVuY2llcyAoZm9yIGV4YW1wbGUgYnkgY2xpZW50cyBub3Qgc3VwcG9ydGluZyBleHRl bnNpb24gZGVmaW5lZAogICBpbiB0aGlzIGRvY3VtZW50KSBtYXkgbGVhZCB0byBpbnRlcm9wZXJh YmlsaXR5IHByb2JsZW1zLgoKICAgQWxzbyB1c2FnZSBvZiBzb21lIG90aGVyIHBvc3NpYmxlIGF0 dHJpYnV0ZXMgZGVmaW5lZCBpbiBSRkMgNDU2NiBbM10KICAgYW5kIGl0cyBleHRlbnNpb25zIGNh biBiZSBjb25zaWRlcmVkIGFzIHRoZWlyIG1pc3VzZSBhbmQgaXMgbm90CiAgIHJlY29tbWVuZGVk LgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClNjaG1pZHQgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBKdWx5IDIyLCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgIFNEUCBEZXBlbmRlbmN5IGF0dHJpYnV0ZSAgICAgICAgICAgIEphbnVhcnkg MjAwNwoKCjQuICBUaGUgRGVwZW5kZW5jeSBBdHRyaWJ1dGUKCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBkZWZpbmVzIGEgbmV3IG1lZGlhLWxldmVsIHZhbHVlIGF0dHJpYnV0ZToKICAgImRlcGVuZGVu Y3kiLiAgSXRzIGZvcm1hdHRpbmcgaW4gU0RQIGlzIGRlc2NyaWJlZCBieSB0aGUgZm9sbG93aW5n CiAgIEJORiBbMl06CgogICAgICBkZXBlbmRlbmN5LWF0dHJpYnV0ZSA9ICJhPWRlcGVuZGVuY3k6 bWFuZGF0b3J5PSIgcG9pbnRlcnMKICAgICAgIjtvcHRpb25hbD0iIHBvaW50ZXJzIC8gImE9ZGVw ZW5kZW5jeTptYW5kYXRvcnk9IiBwb2ludGVycyAvCiAgICAgICJhPWRlcGVuZGVuY3k6b3B0aW9u YWw9IiBwb2ludGVycwoKICAgICAgcG9pbnRlcnMgPSBwb2ludGVyICooICIsIiBwb2ludGVyKQoK ICAgICAgcG9pbnRlciA9IHRva2VuCgogICAgICB0b2tlbiA9IDEqKHRva2VuLWNoYXIpCgogICAg ICB0b2tlbi1jaGFyID0gJXgyMSAvICV4MjMtMjcgLyAleDJBLTJCIC8gJXgyRC0yRSAvICV4MzAt MzkKCiAgICAgIC8gJXg0MS01QSAvICV4NUUtN0UKCiAgICAgIFRoZSBwb2ludGVyIGVsZW1lbnQg aXMgZGVmaW5lZCBpbiB0aGUgU0RQIExhYmVsIEF0dHJpYnV0ZSBbN10gYnV0CiAgICAgIGluY2x1 ZGVkIGhlcmUgdG8gcHJvdmlkZSBzdXBwb3J0IGZvciB0aGUgaW1wbGVtZW50b3Igb2YgdGhpcyBT RFAKICAgICAgZmVhdHVyZS4KCiAgICAgIFRoaXMgbmV3ICJkZXBlbmRlbmN5IiBhdHRyaWJ1dGUg U0hBTEwgY29udGFpbiBvbmUgb3IgdHdvIGxpc3RzIG9mCiAgICAgIFNEUCBMYWJlbHMgLSBtYW5k YXRvcnkgYW5kIG9wdGlvbmFsLiAgRWFjaCBsaXN0IFNIQUxMIGNvbnRhaW4gYQogICAgICBsaXN0 IG9mIHRva2VucyBkZWZpbmVkIGJ5IGFuIG9mZmVyZXIgKG9yIGhlciBhcHBsaWNhdGlvbikgdGhh dCBhcmUKICAgICAgY29ubmVjdGVkIHRvIG1lZGlhIHN0cmVhbSBpbiB0aGUgU0RQIG1lc3NhZ2Uu CgogICAgICBUaGUgbWFuZGF0b3J5IGxpc3QgY29udGFpbnMgZGVwZW5kZW5jaWVzIHRoYXQgbXVz dCBiZSBmdWxmaWxsZWQgaW4KICAgICAgb3JkZXIgdG8gZW5zdXJlIHRoZSBjb3JyZWN0IHNlc3Np b24gc2V0dXAsIHdoaWxlIHRoZSBvcHRpb25hbCBsaXN0CiAgICAgIGNvbnRhaW5zIHRoZSBkZXBl bmRlbmNpZXMgdGhhdCBhcmUgcmVjb21tZWRlZCB0byB0aGUgYW5zd2VyZXIuCiAgICAgIEUuZy4g c3VidGl0bGluZyBkb2VzIG5vdCBtYWtlIHNlbnNlIHdpdGhvdXQgdmlkZW8gKG1hbmRhdG9yeQog ICAgICBkZXBlbmRlbmN5KSwgd2hpbGUgc3VidGl0bGluZyB3aXRoIHZpZGVvIGlzIHVzZWZ1bCBi dXQgbm90CiAgICAgIG5lY2Vzc2FyeSAob3B0aW9uYWwgZGVwZW5kZW5jeSkuCgogICBFeGFtcGxl IChzZWUgYWxzbyBzZWN0aW9uIDYpOgoKICAgICAgYT1kZXBlbmRlbmN5Om1hbmRhdG9yeT0xLDM7 b3B0aW9uYWw9MgoKCgoKCgoKCgoKCgpTY2htaWR0ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMg SnVseSAyMiwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICBTRFAgRGVwZW5kZW5jeSBhdHRyaWJ1dGUgICAgICAgICAgICBKYW51YXJ5IDIwMDcK Cgo1LiAgVGhlIERlcGVuZGVuY3kgQXR0cmlidXRlIGluIE9mZmVyL0Fuc3dlciBNb2RlbAoKICAg SW4gdGhpcyBzZWN0aW9uLCB3ZSBkZWZpbmUgZXh0ZW5zaW9ucyB0byB0aGUgb2ZmZXIvYW5zd2Vy IG1vZGVsCiAgIGRlZmluZWQgaW4gUkZDMzI2NCBbNF0gdG8gYWxsb3cgZXN0YWJsaXNobWVudCBv ZiB0aGUgbXVsdGltZWRpYQogICBzZXNzaW9uIHdpdGggbWVkaWEgc3RyZWFtIGRlcGVuZGVuY2ll cy4KCiAgIEFuIG9mZmVyZXIgdGhhdCB3YW50cyB0byB1c2UgZGVwZW5kZW5jeSBleHRlbnNpb24g ZGVmaW5lZCBpbiB0aGlzCiAgIGRvY3VtZW50IE1BWSBpbmNsdWRlIHRoZSAiZGVwZW5kZW5jeSIg YXR0cmlidXRlIGluIGVhY2ggbWVkaWEtbGV2ZWwKICAgc2VjdGlvbiBpbiB0aGUgU0RQIG9mZmVy LiAgSW4gYWRkaXRpb24sIGVhY2ggbWVkaWEgc3RyZWFtIGluIHRoZSBTRFAKICAgbWVzc2FnZSBn ZW5lcmF0ZWQgYnkgdGhlIG9mZmVyZXIsIHdoaWNoIGlzIHJlZmVyZW5jZWQgaW4gYW4KICAgImRl cGVuZGVuY3kiIGF0dHJpYnV0ZSBvZiBhbm90aGVyIG1lZGlhIHN0cmVhbSwgTVVTVCBpbmNsdWRl IHRoZQogICBsYWJlbCBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBSRkM0NTc0IFs3XS4KCiAgIFdoZW4g dGhlIGFuc3dlcmVyIHJlY2VpdmVzIGFuIG9mZmVyIHdpdGggImRlcGVuZGVuY3kiIGF0dHJpYnV0 ZXMgYW5kCiAgIHN1cHBvcnRzIGV4dGVuc2lvbiBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsIHRo ZSBhbnN3ZXJlciBTSEFMTCB1c2UKICAgdGhlIGZvbGxvd2luZyBydWxlcyB3aGVuIGdlbmVyYXRp bmcgdGhlIGFuc3dlcjoKCiAgICAgICgxKSBXaGVuIGFueSBtZWRpYSBzdHJlYW0gZnJvbSB0aGUg b2ZmZXIgaXMgYWNjZXB0ZWQsIGFsbCBtZWRpYQogICAgICBzdHJlYW1zIHdpdGggbGFiZWwgbGlz dGVkIGFzIG1hbmRhdG9yeSBpbiB0aGUgImRlcGVuZGVuY3kiCiAgICAgIGF0dHJpYnV0ZSBNVVNU IGJlIGFjY2VwdGVkIHRvby4KCiAgICAgICgyKSBXaGVuIGFueSBtZWRpYSBsYWJlbCBpbmNsdWRl ZCBpbiB0aGUgbWFuZGF0b3J5IGxpc3QgaXMgbm90CiAgICAgIHJlY29nbml6ZWQgYXMgdmFsaWQg bGFiZWwgb2YgYW55IG1lZGlhIGluY2x1ZGVkIGluIHRoZSBTRFAKICAgICAgbWVzc2FnZSwgdGhl IGFuc3dlcmVyIFNIQUxMIHJlamVjdCB0aGUgZW50aXJlIG9mZmVyZWQgc2Vzc2lvbi4KCiAgIFRo aXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYW5kYXRlIGFueSBoYW5kbGluZyBmb3IgdGhlIG1l ZGlhIHR5cGVzCiAgIHdpdGggbGFiZWxzIGxpc3RlZCBhcyBvcHRpb25hbCBpbiB0aGUgImRlcGVu ZGVuY3kiIGF0dHJpYnV0ZSwgYnV0IGl0CiAgIGlzIFJFQ09NTUVOREVEIHRoYXQgd2hlbiBhbnkg bWVkaWEgc3RyZWFtIGZyb20gdGhlIG9mZmVyIGlzIGFjY2VwdGVkLAogICBhbGwgbWVkaWEgc3Ry ZWFtcyB3aXRoIGxhYmVsIGxpc3RlZCBhcyBvcHRpb25hbCBpbiB0aGUgImRlcGVuZGVuY3kiCiAg IGF0dHJpYnV0ZSBhcmUgYWNjZXB0ZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHRvby4KCgoKCgoKCgoK CgoKCgoKCgoKCgoKU2NobWlkdCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjIsIDIw MDcgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU0RQ IERlcGVuZGVuY3kgYXR0cmlidXRlICAgICAgICAgICAgSmFudWFyeSAyMDA3CgoKNi4gIEV4YW1w bGUKCiAgIFRoZSBmb2xsb3dpbmcgaXMgYW4gZXhhbXBsZSBvZiBhbiBTRFAgc2Vzc2lvbiBkZXNj cmlwdGlvbiB0aGF0IHVzZXMKICAgdGhlICJkZXBlbmRlbmN5IiBhdHRyaWJ1dGU6CgogICAgICB2 PTAKCiAgICAgIGM9SU4gSVA0IDEuMi4zLjQKCiAgICAgIG09YXVkaW8gMTIzNCBSVFAvQVZQIC4u LgoKICAgICAgYT1sYWJlbDoxCgogICAgICBtPXZpZGVvIDIzNDYgUlRQL0FWUCAuLi4KCiAgICAg IGE9bGFiZWw6MgoKICAgICAgYT1kZXBlbmRlbmN5Om1hbmRhdG9yeT0xO29wdGlvbmFsPTMKCiAg ICAgIG09bWVzc2FnZSAzNDU2IFRDUC9NU1JQIC4uLgoKICAgICAgaT1zdWJ0aXRsZXMgZm9yIGF1 ZGlvCgogICAgICBhPWxhYmVsOjMKCiAgICAgIGE9ZGVwZW5kZW5jeTptYW5kYXRvcnk9MgoKICAg VGhlIGV4YW1wbGUgYWJvdmUsIHdoZW4gdXNlZCBpbiB0aGUgb2ZmZXIsIHJlcHJlc2VudHMgdGhl IHNlc3Npb24KICAgd2hlcmUgYXQgbGVhc3QgYXVkaW8gc2hhbGwgYmUgdXNlZCBieSBhbGwgbXVs dGktcGFydHkgbXVsdGltZWRpYQogICBzZXNzaW9uIHBhcnRpY2lwYW50cy4gIFZpZGVvIGNhbiBi ZSB1c2VkIG9ubHkgdG9nZXRoZXIgd2l0aCBhdWRpby4KICAgU3VidGl0bGVzIGNhbiBiZSB1c2Vk IG9ubHkgdG9nZXRoZXIgd2l0aCBhdWRpbyBhbmQgdmlkZW8uICBWaWRlbyBpcwogICByZWNvbW1l bmRlZCB0byBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggc3VidGl0bGVzLgoKCgoKCgoKCgoKCgoKCgoK CgoKU2NobWlkdCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjIsIDIwMDcgICAgICAg ICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU0RQIERlcGVuZGVu Y3kgYXR0cmlidXRlICAgICAgICAgICAgSmFudWFyeSAyMDA3CgoKNy4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zCgogICBBbiBhdHRhY2tlciBtYXkgYXR0ZW1wdCB0byBhZGQsIG1vZGlmeSwgb3Ig cmVtb3ZlICJkZXBlbmRlbmN5IgogICBhdHRyaWJ1dGVzIGZyb20gYSBzZXNzaW9uIGRlc2NyaXB0 aW9uLiAgVGhpcyBjb3VsZCByZXN1bHQgaW4gYW4KICAgYXBwbGljYXRpb24gYmVoYXZpbmcgaW4g YSBub24tZGVzaXJhYmxlIHdheS4gIFNvLCBpdCBpcyBzdHJvbmdseQogICBSRUNPTU1FTkRFRCB0 aGF0IGludGVncml0eSBwcm90ZWN0aW9uIGJlIGFwcGxpZWQgdG8gdGhlIFNEUCBzZXNzaW9uCiAg IGRlc2NyaXB0aW9ucy4gIEZvciBzZXNzaW9uIGRlc2NyaXB0aW9ucyBjYXJyaWVkIGluIFNJUCBS RkMzMjYxIFs2XSwKICAgUy9NSU1FIGlzIHRoZSBuYXR1cmFsIGNob2ljZSB0byBwcm92aWRlIHN1 Y2ggZW5kLXRvLWVuZCBpbnRlZ3JpdHkKICAgcHJvdGVjdGlvbiwgYXMgZGVzY3JpYmVkIGluIFs2 XSBPdGhlciBhcHBsaWNhdGlvbnMgTUFZIHVzZSBhCiAgIGRpZmZlcmVudCBmb3JtIG9mIGludGVn cml0eSBwcm90ZWN0aW9uLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK ClNjaG1pZHQgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDA3ICAgICAgICAg ICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNEUCBEZXBlbmRlbmN5 IGF0dHJpYnV0ZSAgICAgICAgICAgIEphbnVhcnkgMjAwNwoKCjguICBJQU5BIENvbnNpZGVyYXRp b25zCgogICAgICBDb250YWN0IG5hbWU6IE5OIG5uQG5uLmNvbQoKICAgICAgQXR0cmlidXRlIG5h bWU6ICJkZXBlbmRlbmN5Ii4KCiAgICAgIFR5cGUgb2YgYXR0cmlidXRlOiBNZWRpYSBsZXZlbC4K CiAgICAgIFN1YmplY3QgdG8gY2hhcnNldDogTm90LgoKICAgICAgUHVycG9zZSBvZiBhdHRyaWJ1 dGU6IFRoZSAnZGVwZW5kZW5jeScgYXR0cmlidXRlIGFsbG93cyBkZWZpbml0aW9uCiAgICAgIG9m IG1lZGlhIHN0cmVhbSBkZXBlbmRlbmNpZXMgaW4gdGhlIG9mZmVyLiAgVGhlIG1lZGlhIHN0cmVh bQogICAgICBkZXBlbmRlbmNpZXMgYWxsb3cgZXN0YWJsaXNobWVudCBvZiBtdWx0aS1wYXJ0eSBt dWx0aW1lZGlhIHNlc3Npb24KICAgICAgd2hlcmUgYWxsIHBhcnRpY2lwYW50cyBzaGFyZSBhdCBs ZWFzdCBvbmUgY29tbW9uIG1lZGlhIHR5cGUuCgogICAgICBBbGxvd2VkIGF0dHJpYnV0ZSB2YWx1 ZXM6IE1hbmRhdG9yeSBhbmQgb3B0aW9uYWwgbGlzdHMgb2YgdG9rZW5zCiAgICAgIHdpdGggbWVk aWEgc3RyZWFtIGxhYmVscwoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKU2NobWlk dCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMjIsIDIwMDcgICAgICAgICAgICAgICAg W1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU0RQIERlcGVuZGVuY3kgYXR0cmli dXRlICAgICAgICAgICAgSmFudWFyeSAyMDA3CgoKOS4gIEFja25vd2xlZGdlbWVudHMKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpTY2htaWR0ICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAwNyAgICAgICAgICAgICAgICBbUGFnZSAx MV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTRFAgRGVwZW5kZW5jeSBhdHRyaWJ1dGUgICAg ICAgICAgICBKYW51YXJ5IDIwMDcKCgoxMC4gIFJlZmVyZW5jZXMKCiAgIFsxXSAgQnJhZG5lciwg Uy4sICJLZXkgV29yZHMgZm9yIFVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50CiAg ICAgICAgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIFsyXSAgQ3Jv Y2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgKICAgICAg ICBTcGVjaWZpY2F0aW9uczogQUJORiIsIFJGQyAyMjM0LCBOb3ZlbWJlciAxOTk3LgoKICAgWzNd ICBIYW5kbGV5LCBNLiwgSmFjb2Jzb24sIFYuLCBhbmQgQy4gUGVya2lucywgIlNEUDogU2Vzc2lv bgogICAgICAgIERlc2NyaXB0aW9uIFByb3RvY29sIiwgUkZDIDQ1NjYsIEp1bHkgMjAwNi4KCiAg IFs0XSAgUm9zZW5iZXJnLCBKLiBhbmQgSC4gU2NodWx6cmlubmUsICJBbiBPZmZlci9BbnN3ZXIg TW9kZWwgd2l0aAogICAgICAgIHRoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFAp IiwgUkZDIDMyNjQsIEp1bmUgMjAwMi4KCiAgIFs1XSAgUm9zZW5iZXJnLCBKLiwgIkEgRnJhbWV3 b3JrIGZvciBDb25mZXJlbmNpbmcgd2l0aCB0aGUgU2Vzc2lvbgogICAgICAgIEluaXRpYXRpb24g UHJvdG9jb2wgKFNJUCkiLCBSRkMgNDM1MywgRmVicnVhcnkgMjAwNi4KCiAgIFs2XSAgUm9zZW5i ZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBDYW1hcmlsbG8sIEcuLCBKb2huc3RvbiwgQS4sCiAg ICAgICAgUGV0ZXJzb24sIEouLCBTcGFya3MsIFIuLCBIYW5kbGV5LCBNLiwgYW5kIEUuIFNjaG9v bGVyLCAiU0lQOgogICAgICAgIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCIsIFJGQyAzMjYx LCBKdW5lIDIwMDIuCgogICBbN10gIExldmluLCBPLiBhbmQgRy4gQ2FtYXJpbGxvLCAiVGhlIFNl c3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wKICAgICAgICAoU0RQKSBMYWJlbCBBdHRyaWJ1dGUi LCBBdWd1c3QgMjAwNi4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClNjaG1pZHQgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDIyLCAyMDA3ICAgICAgICAgICAgICAgIFtQYWdlIDEy XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNEUCBEZXBlbmRlbmN5IGF0dHJpYnV0ZSAgICAg ICAgICAgIEphbnVhcnkgMjAwNwoKCkF1dGhvcidzIEFkZHJlc3MKCiAgIENocmlzdGlhbiBTY2ht aWR0CiAgIFNpZW1lbnMgTmV0d29ya3MKICAgU3QuLU1hcnRpbi1TdHIuNzYKICAgTXVuaWNoICA4 MTYxNwogICBHZXJtYW55CgogICBQaG9uZTogKzQ5IDg5IDYzNiA3NTE5MgogICBFbWFpbDogY2hy aXN0aWFuLXNjaG1pZHRAc2llbWVucy5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgpTY2htaWR0ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAyMiwgMjAw NyAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTRFAg RGVwZW5kZW5jeSBhdHRyaWJ1dGUgICAgICAgICAgICBKYW51YXJ5IDIwMDcKCgpGdWxsIENvcHly aWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLgoK ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCBy ZXN0cmljdGlvbnMKICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9y dGggdGhlcmVpbiwgdGhlIGF1dGhvcnMKICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuCgogICBU aGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJv dmlkZWQgb24gYW4KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JH QU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5Z KSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORAogICBUSEUgSU5URVJO RVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVT UwogICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YKICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZS SU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVECiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoKCkludGVsbGVjdHVh bCBQcm9wZXJ0eQoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2 YWxpZGl0eSBvciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBv ciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhl IGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4KICAg dGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1 Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0 IHJlcHJlc2VudCB0aGF0IGl0IGhhcwogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8g aWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHByb2NlZHVy ZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQogICBmb3Vu ZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFk ZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5z ZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBt YWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNl IG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBv ZiB0aGlzCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24t bGluZSBJUFIgcmVwb3NpdG9yeSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRo ZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVu dGlvbiBhbnkKICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBv ciBvdGhlciBwcm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0 aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFz ZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRm Lm9yZy4KCgpBY2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVu Y3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYKICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBB Y3Rpdml0eSAoSUFTQSkuCgoKCgoKU2NobWlkdCAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMjIsIDIwMDcgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKCg== ------_=_NextPart_001_01C73BC1.D7385145 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C73BC1.D7385145-- From mmusic-bounces@ietf.org Fri Jan 19 13:41:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yfN-0001Mg-4L; Fri, 19 Jan 2007 13:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yfL-0001Ma-Tr for mmusic@ietf.org; Fri, 19 Jan 2007 13:40:43 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7yfI-0007Kj-8E for mmusic@ietf.org; Fri, 19 Jan 2007 13:40:43 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2007 10:40:39 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0JIedSm020516; Fri, 19 Jan 2007 10:40:39 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0JIednF017409; Fri, 19 Jan 2007 10:40:39 -0800 (PST) From: "Dan Wing" To: "'Schmidt, Christian'" Subject: RE: [MMUSIC] New ID, related to media stream dependencies Date: Fri, 19 Jan 2007 10:40:38 -0800 Message-ID: <052601c73bf9$50c3c050$aaa36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <72963DDDF17D7949ABD18DC5DA58E77001AC8E5D@MCHP7R5A.ww002.siemens.net> Thread-Index: AcE8+q9WSC0EcqjREdWWxAAADv2DOIv9iK3QAACrAzAADco4oA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2416; t=1169232039; x=1170096039; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20New=20ID, =20related=20to=20media=20stream= 20dependencies |Sender:=20; bh=Ly+ITSAVzOaR8saDD8QIpnWFPwN3T/XVPulnWk35Iuk=; b=Uef1cSY+VOf276LzhsOqgO0u919mrINGtVX7U8clxsSKgp/43ZZtPm3mdoL7UZ48L2NXKaYh Ge3e3Ga2rvAsbvEJAF0y+gOjd8IXMHy00Woo2yArnAdykVVks/x94T9Q; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 'MMusic' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org (removed internet-drafts from CC list.) Can draft-ietf-mmusic-sdp-capability-negotiation-00 provide the same functionality? -d > -----Original Message----- > From: Schmidt, Christian [mailto:christian-schmidt@siemens.com]=20 > Sent: Friday, January 19, 2007 4:04 AM > To: internet-drafts@ietf.org > Cc: MMusic; Joerg Ott > Subject: [MMUSIC] New ID, related to media stream dependencies >=20 > Dear editor,=20 >=20 > we would like to submit a new Internet Draft related to work in the=20 > MMUSIC Working Group (although it is not an official product=20 > of the WG).=20 >=20 > <>=20 >=20 > Abstract:=20 > The Session Description Protocol (SDP) was intended for describing=20 > multimedia sessions for the purposes of session announcement, session=20 > invitation, and other forms of multimedia session initiation.=20 > Together with Offer/Answer model it defines a mechanism, how two=20 > entities can reach a common view of a multimedia session between=20 > them.=20 >=20 > In certain cases, there are dependencies between media streams, for=20 > example a text stream for subtitling make sense only together with a=20 > video stream. To avoid senseless connections, the SDP mechanism can=20 > be extended with a new Session Description Protocol (SDP) media-level=20 > attribute: "dependency". The "dependency" attribute allows the=20 > offerer to define dependencies of media streams. The updated offer/=20 > answer mechanism used with new "dependency" attribute can be used=20 > furthermore, that in a multi-party SIP session all participants share=20 > at least one common media type.=20 >=20 > Mit freundlichen Gr=FC=DFen > Christian Schmidt=20 >=20 > Siemens Networks GmbH & Co. KG=20 > St.-Martin-Str. 76=20 > 81541 M=FCnchen, Germany=20 > Tel.: +49 89 636-75192=20 > Fax: +49 89 636-75577=20 > christian-schmidt@siemens.com =20 > =20 > Siemens Networks GmbH & Co. KG=20 > Gesch=E4ftsf=FChrer: Joachim Malterer, Roland Meinzer, Christian=20 > Unterberger=20 > Sitz der Gesellschaft: M=FCnchen=20 > Registergericht: M=FCnchen, HRA 88537=20 > WEEE-Reg.-Nr. DE 52984304=20 > Pers=F6nlich haftende Gesellschafterin: Siemens Networks=20 > Management GmbH=20 > Sitz der Gesellschaft: M=FCnchen=20 > Registergericht: M=FCnchen, HRB 163416=20 > =20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 19 18:16:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H82xt-0005dW-2H; Fri, 19 Jan 2007 18:16:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H82xr-0005dQ-Lt for mmusic@ietf.org; Fri, 19 Jan 2007 18:16:07 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H82xn-0005d2-8z for mmusic@ietf.org; Fri, 19 Jan 2007 18:16:07 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0JNG2YX030812 for ; Fri, 19 Jan 2007 18:16:02 -0500 Received: from [135.148.75.20] ([135.148.75.20]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Jan 2007 16:16:01 -0700 Message-ID: <45B1512F.8050409@avaya.com> Date: Fri, 19 Jan 2007 16:15:59 -0700 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] New ID, related to media stream dependencies References: <052601c73bf9$50c3c050$aaa36b80@amer.cisco.com> In-Reply-To: <052601c73bf9$50c3c050$aaa36b80@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 19 Jan 2007 23:16:01.0561 (UTC) FILETIME=[C8E76890:01C73C1F] X-Scanner: InterScan AntiVirus for Sendmail Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nj300815-ier2.net.avaya.com id l0JNG2YX030812 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: 'MMusic' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dan- As it stands now, the capneg definitions don't support that. Requirement= s 150 and 160 of the requirements draft say: REQ-150: It SHOULD be possible to specify valid combinations of = media lines. For example, an entity may be able to support audio and video= or audio and IM, but not video and IM (or all three). REQ-160: It SHOULD be possible to specify valid combinations of = media formats between media streams. For example, there may be constraints on which combinations o= f audio and video codecs can be supported. I've been thinking about some session-level constraints that might be use= d for REQ-160. For example, one might define a ccons: attribute that listed acceptable combinations of codecs - I was considering the processi= ng- power constraints between specific codecs (e.g., codec a1 and codec v1 or codec a2 and codec v2). Christian's goal is described by REQ-150 - makin= g sure the responder doesn't do something silly like open a subtitles strea= m with no video stream. In that particular case, it's not clear to me that the responder wouldn't know better even without the constraint from the offeror. On the other hand, it would be nice to be able to say "I'll tak= e audio without the video" or "Don't give me audio without the video" - so = the=20 problem doesn't go away. IIRC, we made these requirements "SHOULD" rathe= r than "MUST" because we weren't sure if anyone needed or used them at pres= ent. I'll remind folks that the next meeting of the capability negotiation gro= up is Tues, January 23 at 1000 Eastern Standard Time. We expect to discuss some of the configuration proposals that have been put forward, and we ca= n also discuss the constraints between streams. The bridge info is: US toll free: 866-902-7870 (outside the 408 area code.) everywhere else: +1 408 902 7870 meeting ID: 737227634 All interested parties are invited to attend. -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Dan Wing wrote: > (removed internet-drafts from CC list.) >=20 > Can draft-ietf-mmusic-sdp-capability-negotiation-00 provide the same > functionality? >=20 > -d >=20 >=20 >>-----Original Message----- >>From: Schmidt, Christian [mailto:christian-schmidt@siemens.com]=20 >>Sent: Friday, January 19, 2007 4:04 AM >>To: internet-drafts@ietf.org >>Cc: MMusic; Joerg Ott >>Subject: [MMUSIC] New ID, related to media stream dependencies >> >>Dear editor,=20 >> >>we would like to submit a new Internet Draft related to work in the=20 >>MMUSIC Working Group (although it is not an official product=20 >>of the WG).=20 >> >><>=20 >> >>Abstract:=20 >>The Session Description Protocol (SDP) was intended for describing=20 >>multimedia sessions for the purposes of session announcement, session=20 >>invitation, and other forms of multimedia session initiation.=20 >>Together with Offer/Answer model it defines a mechanism, how two=20 >>entities can reach a common view of a multimedia session between=20 >>them.=20 >> >>In certain cases, there are dependencies between media streams, for=20 >>example a text stream for subtitling make sense only together with a=20 >>video stream. To avoid senseless connections, the SDP mechanism can=20 >>be extended with a new Session Description Protocol (SDP) media-level=20 >>attribute: "dependency". The "dependency" attribute allows the=20 >>offerer to define dependencies of media streams. The updated offer/=20 >>answer mechanism used with new "dependency" attribute can be used=20 >>furthermore, that in a multi-party SIP session all participants share=20 >>at least one common media type.=20 >> >>Mit freundlichen Gr=FC=DFen >>Christian Schmidt=20 >> >>Siemens Networks GmbH & Co. KG=20 >>St.-Martin-Str. 76=20 >>81541 M=FCnchen, Germany=20 >>Tel.: +49 89 636-75192=20 >>Fax: +49 89 636-75577=20 >>christian-schmidt@siemens.com =20 >> =20 >>Siemens Networks GmbH & Co. KG=20 >>Gesch=E4ftsf=FChrer: Joachim Malterer, Roland Meinzer, Christian=20 >>Unterberger=20 >>Sitz der Gesellschaft: M=FCnchen=20 >>Registergericht: M=FCnchen, HRA 88537=20 >>WEEE-Reg.-Nr. DE 52984304=20 >>Pers=F6nlich haftende Gesellschafterin: Siemens Networks=20 >>Management GmbH=20 >>Sitz der Gesellschaft: M=FCnchen=20 >>Registergericht: M=FCnchen, HRB 163416=20 >> =20 >> >> >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jan 20 05:39:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Dch-0005gw-2z; Sat, 20 Jan 2007 05:38:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H84CX-0004vW-Ji for mmusic@ietf.org; Fri, 19 Jan 2007 19:35:21 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H847M-0008MV-Cv for mmusic@ietf.org; Fri, 19 Jan 2007 19:30:03 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2007 16:29:59 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0K0Txos011473; Fri, 19 Jan 2007 16:29:59 -0800 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0K0TunF022725; Fri, 19 Jan 2007 16:29:57 -0800 (PST) From: "Dan Wing" To: "'Jonathan Rosenberg'" Date: Fri, 19 Jan 2007 16:29:56 -0800 Message-ID: <06ba01c73c2a$1c8fd630$aaa36b80@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.3028 Thread-Index: Acc8KhwQ/tH8LRMhQLiptyew7q12Og== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=85444; t=1169252999; x=1170116999; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20review=20of=20ICE-13 |Sender:=20; bh=bo/7F+8E0zJyQL0ThFsdvRTfkeH9tfoAvMoy0Od2+Wg=; b=Z/ouMdkhoXhJdsbUk+JHLAHWptMOEuz8qp4GibfYimFo/n57NsCHZqBkvmy6VawunPoVkEU6 Vr41vfxli+i+9Kf/FnAVantkwroEneIR6cy7hpb9vwuRZOzZ0F+n3UqD; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 3.2 (+++) X-Scan-Signature: bd9d53b0fde977f45cd78e0c1c1bf380 X-Mailman-Approved-At: Sat, 20 Jan 2007 05:38:57 -0500 Cc: 'MMusic' Subject: [MMUSIC] review of ICE-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org An impressive document, Jonathan. Primary comment: * After doing a binding discovery, the agent needs to keep those bindings open until it's sure they're no longer used. Consider the case of a little old lady from Pasadena who takes 35 seconds to type in a phone number; if you obtained the binding as soon as she went offhook, the binding will have timed out by the time the Invite is sent. Similarly, SIP retransmissions could cause a healthy delay in the Invite reaching the called party or all of the called parties (when forking) or the final target (if retargeting). I suggest this keepalive should be a STUN Binding Request, so that if an implementation keeps this binding open for a long time it is aware of a reassignment of public transport address by the NAT (due to NAT crashing, new DHCP lease for the NAT, whatever). General comments: * As Eric said, more headings and lists would be useful; some of these sections run two pages and the text is dense. * I noticed both "lite" and "passive" are used almost interchangably in the document, with the intention they mean the same thing. It would be useful to eliminate one of those terms. * I found using "L" and "R" to refer to the agents a bit confusing because it's difficult to say a sentence like "R takes its local candidate and sends it its remote peer, L". I did notice some of the examples use A and B, and others use L and R. It would be useful to stick with one unless there is a reason to switch between A/B and L/R. * Run http://tools.ietf.org/tools/idnits/ against the document; boilerplate is wrong, a few lines exceed the maximum. * In several places different terminology was used which appears to mean the same thing: - Triggered / tentative - Ignore duplicates / prune / eliminate redundant candidates - Intermediary / media relay / (and "gateway", when talking about the SIP option tag in 12.2). - Active / in-use - Lite / passive / passive-only - Callee / answerer (in section 12) * Is the plan for TURN, or for ICE, to explain that TURN is only needed if the two agents are behind NATs that perform Address and Port Dependent Mapping (previously called "symmetric NAT")? Right now there isn't a discussion of this in ICE, but it might be useful to provide guidance on when the 'provider variance' is permissable. * There isn't a discussion of what happens when a lite implementation encounters a lite implementation. I assume there aren't any connectivity checks sent by either side. (Should be added to 5.2) Detailed nits and suggestions: > Abstract > > This document describes a protocol for Network Address Translator > (NAT) traversal for multimedia session signaling protocols based on > the offer/answer model, such as the Session Initiation Protocol > (SIP). This protocol is called Interactive Connectivity > Establishment (ICE). ICE makes use of the Session Traversal > Utilities for NAT (STUN) protocol, applying its binding discovery and > relay usages, add "and keepalive usage," > in addition to defining a new usage for checking > connectivity between peers. ... > 2. Overview of ICE > Figure Figure 1 shows a typical environment for ICE deployment. The ^^^^^^^^^^^^^^^ duplicated > two endpoints are labelled L and R (for left and right, which helps > visualize call flows). It does help visualizing the flow, but it's also difficult to think of phrases like "R takes its local candidate and sends it its remote peer, L" in your head. A nit, but I would be more comfortable with A and B instead of L and R. > Both L and R are behind NATs -- though as "behind NATs" -> "behind their own respective NATs" ... > 2.1. Gathering Candidate Addresses ... > Note Does this "Note" apply to just the next paragraph, or to the rest of section 2.1? Indenting would help clarify. I think it is intended to only apply to the next paragraph. > "Base" refers to the address you'd send from for a particular > candidate. Thus, as a degenerate case host candidates also have a > base, but it's the same as the host candidate. > > When there are multiple NATs between the agent and the STUN server, > the STUN request will create a binding on each NAT, but only the > outermost server reflexive candidate will be discovered by the agent. > If the agent is not behind a NAT, then the base candidate will be the > same as the server reflexive candidate and the server reflexive > candidate can be ignored. In section 4.1.1, "Gatering Candidates", the text reads: > Next, the agent eliminates redundant candidates. A candidate is > redundant if its transport address equals another candidate, and its > base equals the base of that other candidate. Note that two > candidates can have the same transport address yet have different > bases, and these would not be considered redundant. Is this what you mean by "ignore"? If so, using consistent terminology would help; it seems it isn't really ignored. Question: does learning you're not behind a NAT mean that you MAY, MAY NOT, SHOULD, or MUST go into 'lite' mode? > The final type of candidate is a RELAYED candidate. The STUN Relay > Usage [12] allows a STUN server to act as a media relay, forwarding > traffic between L and R. In order to send traffic to L, R sends > traffic to the media relay which forwards it to L and vice versa. > The same thing happens in the other direction. That last sentence gave me deja vu with vice versa. ... > 2.3. Sorting Candidates > > Because the algorithm above searches all candidate pairs, if a > working pair exists it will eventually find it no matter what order > the candidates are tried in. In order to produce faster (and better) > results, the candidates are sorted in a specified order. The > algorithm is described in Section 4.1.2 but follows two general > principles: > > o Each agent gives its candidates a numeric priority which is sent > along with the candidate to the peer > > o The local and remote priorities are combined so that each agent > has the same ordering for the candidate pairs. > > The second property is important for getting ICE to work when there > are NATs in front of A and B. "A and B" -> "L and R". > Frequently, NATs will not allow packets > in from a host until the agent behind the NAT has sent a packet > towards that host. Consequently, ICE checks in each direction will > not succeed until both sides have sent a check through their > respective NATs. > > In general the priority algorithm is designed so that candidates of > similar type get similar priorities and so that more direct routes add: "(that is, through fewer media relays and through fewer NATs)" > are preferred over indirect ones. Within those guidelines, however, > agents have a fair amount of discretion about how to tune their > algorithms. > > 2.4. Frozen Candidates > > The previous description only addresses the case where the agents > wish to establish a single media component--i.e., a single flow with > a single host-port quartet. However, in many cases (in particular > RTP and RTCP) the agents actually need to establish connectivity for > more than one flow. > > The naive way to attack this problem would be to simply do > independent ICE exchanges for each media component. This is > obviously inefficient because the network properties are likely to be > very similar for each component (especially because RTP and RTCP are > typically run on adjacent ports The port adjacency isn't really why RTP and RTCP are going to take the same path; rather, it's because they're used on the same interface and use the same protocol (UDP). Besides, later in the document you clearly indicate RFC3605 (a=rtcp) is needed, so this port adjacency is moot. I suggest, instead: "(especially because RTP and RTCP are sent and received from the same IP address)" >). Thus, it should be possible to > leverage information from one media component in order to determine > the best candidates for another. ICE does this with a mechanism > called "frozen candidates." ... > 2.5. Security for Checks > > Because ICE is used to discover which addresses can be used to send > media between two agents, it is important to ensure that the process > cannot be hijacked to send media to the wrong location. Each STUN > connectivity check is covered by a message authentication code (MAC) > computed using a key exchanged in the signalling channel. This MAC > provides message integrity and data origin authentication, thus > stopping an attacker from forging or modifying connectivity check > messages. The MAC also aids in disambiguating ICE exchanges from > forked calls. Need a reference to forked calls for readers unfamiliar with this aspect of SIP. It's important for ICE implementations to expect calls to fork and to expect, as a normal event, STUN Connectivity Checks arriving from many different source transport addresses. > 2.6. Concluding ICE > > ICE checks are performed in a specific sequence, so that high > priority pairs "of candidates" > are checked first, followed by lower priority ones. > One way to conclude ICE is to declare victory as soon as a check for > each component of each media stream completes successfully. Indeed, > this is a reasonable algorithm, and details for it are provided > below. However, it is possible that packet losses will cause a > higher priority check to take longer to complete, and allowing ICE to change to: "... check to take longer to complete. In that case, allowing ICE ..." ... > Once ICE is concluded, it can be restarted at any time for one or all > of the media streams by each agent. This is done by sending an ^^^^^^^^^^^^^ I think you want "by either agent". I believe this aspect is only really mentioned here in the overview. If you want "either agent" to be able to send a new offer, it should also be clearly stated in section 9 ("Subsequent Offer/Answer Exchanges" that either agent can generate a new offer and restart ICE. > updated offer indicating a restart. > > 2.7. Lite Implementations > > In order for ICE to be used in a call, both agents need to support > it. However, certain agents, such as those in gateways to the PSTN, > media servers, conferencing servers, and voicemail servers, are known > to not be behind a NAT or firewall. Citing specific examples of equipment is frightening. Consider that most voicemail servers deployed by most enterprises are, in fact, behind the Enterprise's NAT box. Vendors will point to this sentence and explain they are "compliant" with their lite implementation. This is bad. How about, instead, saying that devices which are only ever deployed on the public Internet only need a lite implementation? You had good text in Appendix A that needs to be moved here to section 2.7. It is: Consequently, a lite implementation is only appropriate for devices that will always be connected to the public Internet and have a public IP address at which it can receive packets from any correspondent. ICE will not function when a lite implementation is placed behind a NAT. Consider moving all of Appendix A up here to introduce the difference between a Full and Lite implementation, as it seems too important to hide in the Appendix. ... > Foundation: Each candidate has a foundation, which is an identifier > that is distinct for two candidates that have different types, > different interface IP addresses for their base, and different IP > addresses for their STUN servers. Two candidates have the same > foundation when they are of the same type, their bases have the > same IP address, and, for server reflexive or relayed candidates, > they come from the same STUN server. Foundations are used to > correlate candidates, so that when one candidate is found to be > valid, candidates sharing the same foundation can be tested next, > as they are likely to also be valid. (Wow, that is a complicated definition.) It isn't clear, reading this, if a foundation is something that is communicated in SDP, communicated in the STUN messages between peers, or derived from information in the SDP or STUN messages. > 3. Terminology ... > Server Reflexive Candidate: A candidate obtained by sending a STUN > request from a host candidate to a STUN server, distinct from the > peer, whose address is configured or learned by the client prior ^^^^^^^^^^^^^^^ . The STUN server's address > to an offer/answer exchange. ... > 4. Sending the Initial Offer > > In order to send the initial offer in an offer/answer exchange, an > agent must gather candidates, priorize them, choose ones for > inclusion in the m/c-line, "line" -> "lines" > and then formulate and send the SDP. The > first of these three steps differ for full and lite implementations. I counted 4 or 5 steps, depending on how I count. I agree with Eric -- separate headings would really help, especially for the candidate gathering which you said differs from Lite and Full implementations, but I have to read all 10 paragraphs to see what is different. > 4.1. Full Implementation Requirements > > 4.1.1. Gathering Candidates At about the middle of this section you mention you're describing STUN's Binding Discovery usage. This should be done earlier. ... > Agents SHOULD obtain relayed candidates and MUST obtain server > reflexive candidates. The requirement to obtain relayed candidates > is at SHOULD strength to allow for provider variation. ^^^^^^^^^^^^^^^^^^ The real reason is if you somehow know you aren't behind a Address and Port Dependent Mapping NAT, or if you cannot get a media relay for some reason (costs too much, nobody is your friend, whatever). ... > The agent next pairs each host candidate with the STUN server with > which it is configured or has discovered by some means. This > specification only considers usage of a single STUN server. Every Ta > seconds, the agent chooses another such pair (the order is "seconds" -> "milliseconds" > inconsequential), and sends a STUN request to the server from that > host candidate. "host candidate" -> "base" ?? > If the agent is using both relayed and server > reflexive candidates add "with that STUN server" >, this request MUST be a STUN Allocate request > from the relay usage [12]. If the agent is using only server > reflexive candidates, the request MUST be a STUN Binding request > using the binding discovery usage [11]. Nit: In the two sentences above, they end with "... from the relay usage." and "... using the binding discovery usage." I don't have a preference, but using "from" or "using" would read easier. > The value of Ta SHOULD be configurable, and SHOULD have a default of > 20ms. Provide forward reference to section B.1, "Timing of STUN Transactions". > Note that this pacing applies only to starting STUN > transactions with source and destination transport addresses (i.e., > the host candidate and STUN server respectively) for which a STUN > transaction has not previously been sent. Consequently, > retransmissions of a STUN request are governed entirely by the > retransmission rules defined in [11]. Similarly, retries of a > request due to recoverable errors (such as an authentication > challenge) happen immediately and are not paced by timer Ta. Because > of this pacing, it will take a certain amount of time to obtain all > of the server reflexive and relayed candidates. Implementations > should be aware of the time required to do this, and if the > application requires a time budget, limit the amount of candidates > which are gathered. > > An Allocate Response will provide the agent with a server reflexive Insert at the beginning of this paragraph: "The agent will receive a STUN Binding or Allocate response." > candidate (obtained from the mapped address) and a relayed candidate > in the RELAY-ADDRESS attribute. A Binding Response will provide the > agent with only a server reflexive candidate (also obtained from the > mapped address). The base of the server reflexive candidate is the > host candidate from which the Allocate or Binding request was sent. > The base of a relayed candidate is that candidate itself. A server > reflexive candidate obtained from an Allocate response is the called > the "translation" of the relayed candidate obtained from the same > response. The word "translation" only occurs one other place in the document. Can we nuke it? ... > 4.1.2. Prioritizing Candidates > > The prioritization process results in the assignment of a priority to > each candidate. Each candidate for a media stream MUST have a unique > priority. An agent SHOULD compute the priority by determining a > preference for each type of candidate (server reflexive, peer > reflexive, relayed and host), and, when the agent is multihomed, > choosing a preference for its interfaces. These two preferences are > then combined to compute the priority for a candidate. That priority > SHOULD be computed using the following formula: ^^^^^^ In the overview (section 2), it was said there was leeway in using different schemes. The SHOULD implies that interoperability will break if this formula isn't used. Can you provide additional guidance on the importance of following this formula, or a forward reference to an appendix section that discusses how to use a different priority scheme? > priority = (2^24)*(type preference) + > (2^8)*(local preference) + > (2^0)*(256 - component ID) > > > The type preference MUST be an integer from 0 to 126 inclusive, and > represents the preference for the type of the candidate (where the > types are local, server reflexive, peer reflexive and relayed). A > 126 is the highest preference, and a 0 is the lowest. Setting the > value to a 0 means that candidates of this type will only be used as > a last resort. The type preference MUST be identical for all > candidates of the same type and MUST be different for candidates of > different types. The type preference for peer reflexive candidates > MUST be higher than that of server reflexive candidates. Note that > candidates gathered based on the procedures of Section 4.1.1 will > never be peer reflexive candidates; candidates of these type are > learned from the STUN connectivity checks performed by ICE. The > component ID is the component ID for the candidate, and MUST be > between 1 and 256 inclusive. The local preference MUST be an integer > from 0 to 65535 inclusive. It represents a preference for the > particular interface from which the candidate was obtained, in cases > where an agent is multihomed. 65535 represents the highest > preference, and a zero, the lowest. When there is only a single > interface, this value SHOULD be set to 65535. Generally speaking, if > there are multiple candidates for a particular component for a > particular media stream which have the same type, the local > preference MUST be unique for each one. That last sentence reads: "Generally speaking, ... MUST be unique" Should that be a SHOULD, or can you better qualify the "Generally speaking" into an if/then clause? ... > additional router hops that may be taken. It may increase the cost > of providing service, since media will be routed in and right back > out of an intermediary run by the provider. ^^^^^^^^^^^^^^^ a media relay ... > Another criteria for selection of preferences is IP address family. > ICE works with both IPv4 and IPv6. It therefore provides a > transition mechanism that allows dual-stack hosts to prefer > connectivity over IPv6, but to fall back to IPv4 in case the v6 > networks are disconnected (due, for example, to a failure in a 6to4 > relay) [23]. It can also help with hosts that have both a native > IPv6 address and a 6to4 address. In such a case, lower local ^^^^^ "higher" ? > preferences could be assigned to the v6 interface, followed by the > 6to4 interfaces, followed by the v4 interfaces. This allows a site > to obtain and begin using native v6 addresses immediately, yet still > fallback to 6to4 addresses when communicating with agents in other > sites that do not yet have native v6 connectivity. ... > 4.1.3. Choosing In-Use Candidates ... > An agent MUST choose a set of candidates, one for each component of > each active media stream, to be in-use. A media stream is active if > it does not contain the a=inactive SDP attribute. active = in-use? The paragraph and section 5.7 appear to both be defining in-use, but their definition is different. 5.7 says port 0, bandwidth of 0 mean it's still in-use from ICE's perspective. Section 9.1 prohibits an ICE endpoint from using 0.0.0.0 in a subsequent O/A, and says port=0 means a=candidate can't be used. I expect a=candidate with port=0 is also prohibited in an initial offer, but nothing seems to jump out and say that like 9.1 says it. It would be useful to have an appendix section, which is forward referenced in 4.1.3 and in 9.1, that explains why bandwidth=0, 0.0.0.0, port=0 are all considered 'active' from ICE's perspective. (I believe the reason is so that when the stream becomes active for the endpoint with another O/A, we don't need to restart ICE and wait for ICE's delay). ... > Indeed, the difficulty in picking just one transport address that > will work is the whole problem that motivated the development of this > specification in the first place. As such, it is RECOMMENDED that > agents select relayed candidates to be in-use. insert: " (if relayed candidates are available), server reflexive candidates (if server reflexive candidates are available), and finally host candidates." > 4.2. Lite Implementation > > For each media stream, the agent allocates a single candidate for > each component of the media stream from one of its interfaces. If an > agent is multi-homed, it MUST choose one of its interfaces for a > particular media stream; insert "because with the Lite implementation, " > 4.3. Encoding the SDP > > The process of encoding the SDP is identical between full and lite > implementations. > > The agent includes a single a=candidate media level attribute in the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > SDP for each candidate for that media stream. The use of 'single' was confusing; it reads as if only one a=candidate can be included. How about: "The agent includes an a=candidate media leval attribute for each candidate for each media stream in the SDP". > The a=candidate > attribute contains the IP address, port and transport protocol for > that candidate. A Fully Qualified Domain Name (FQDN) for a host MAY > be used in place of a unicast address. ^^^^^^^^^^^^^^^ This is the only place where "unicast" appears in the document. Can we nuke it? It implies ICE is only useable for unicast (which is probably true). > In that case, when receiving > an offer or answer containing an FQDN in an a=candidate attribute, > the FQDN is looked up in the DNS using an A or AAAA record, and the > resulting IP address is used for the remainder of ICE processing. > The candidate attribute also includes the component ID for that > candidate. For media streams based on RTP, candidates for the actual > RTP media MUST have a component ID of 1, and candidates for RTCP MUST > have a component ID of 2. Other types of media streams which require > multiple components MUST develop specifications which define the > mapping of components to component IDs, and these component IDs MUST > be between 1 and 256. A forward reference to the section 14 ("extensibility considerations") would be useful. There, you should provide guidance on the meaning of the component ID values (the lowest numbered one is attempted first; except ...) ... I noticed that section 9.3.1 has a special meaning for the value 1: > Next, the agent goes through each check list, starting with the > highest priority check. If a check has a state of Succeeded, and it > has a component ID of 1, then all Frozen checks in the same check > list with the same foundation whose component IDs are not one, have > their state set to Waiting. If, for a particular check list, there > are checks for each component of that media stream in the Succeeded > state, the agent moves the state of all Frozen checks for the first > component of all other media streams (and thus in different check > lists) with the same foundation to Waiting. The extensibility section needs to explain if "1" has a special meaning (which it does per 9.3.1). > The candidate attribute also includes the priority and the > foundation. The agent SHOULD include a type for each candidate by > populating the candidate-types production with the appropriate value ^^^^^^^^^^ Nit: I stumbled over the word "production"; RFC4234 (ABNF) doesn't use the term "production". I do see that several RFCs in the 4000's use it with the same meaning you have. RFC4234 recommends enclosing the term in "<>" when used in prose, which seems to help legibility, like this: ... populating with the appropriate value > - "host" for host candidates, "srflx" for server reflexive > candidates, "prflx" for peer reflexive candidates (though these never ^^^^^^^^^^^^^^^^^^ > appear in an initial offer/answer exchange), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A lite implementation would use its "host" candidate in its initial o/a exchange. But even for a full implementation, I don't understand why it wouldn't include a=candidate for its server reflexive candidate -- that's the address on the public side of its NAT. > and "relay" for relayed candidates. As Eric said, and I'd like to re-iterate: what is the reason for doing this? Nothing seems to take advantage of this information. ... > There MUST be a candidate attribute for each component of the media ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^ > stream in the m/c-line. Does this mean that a "component" is a "candidate", or does it mean there is a 1:1 relationship between "component" and "candidate"? > Once an offer or answer are sent, an agent MUST be prepared to > receive both STUN and media packets on each candidate. Vague; does this mean once both an offer and an answer have been sent, or does this mean that from the perspective of each agent, when it sent its offer or it sent its answer? I suggest: Once an agent has sent its offer or sent its answer, that agent MUST be prepared ... > As discussed > in Section 11.1, media packets can be sent to a candidate prior to > its appearence in the m/c-line. add, at the end, "of the original offer/answer or a subsequent offer/answer". > 5. Receiving the Initial Offer > > When an agent receives an initial offer, it will check if the offeror > supports ICE, determine its role, "determints its role" -> "determins the offerer's role" ... > 5.2. Determining Role ... > If one of the agents is a lite implementation, it MUST assume the > controlled role, and its peer (which will be full) MUST assume the > controlling role. We won't ever have a "lite" calling a "lite"? > If the agent and its peer are both full > implementations, the agent which generated the offer which started > the ICE processing takes on the controlling role, and the other takes > the controlled role. > > Based on this definition, once roles are determined for a session, > they persist unless ICE is restarted, as discussed below. A restart > causes a new selection of roles. "An ICE restart [section 9] causes a new selection of roles." > 5.3. Gathering Candidates > > The process for gathering candidates at the answerer is identical to > the process for the offerer as described in Section 4.1.1 for full > implementations and Section 4.2 for lite implementations. It is > RECOMMENDED that this process begin immediately on receipt of the > offer, prior to user acceptance of a session. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Alerting" is used in RFC3261 and in section 12.1 of this document; would "alerting the user" be better than "acceptance of a session"? ... > 5.7. Forming the Check Lists > > Forming check lists is done only by full implementations. Lite > implementations MUST skip the steps defined in this section. > > There is one check list per in-use media stream resulting from the > offer/answer exchange. A media stream is in-use as long as its port > is non-zero (which is used in RFC 3264 to reject a media stream). > Consequently, a media stream is in-use even if it is marked as > a=inactive or has a bandwidth value of zero. Each check list is a > sequence of STUN connectivity checks that are performed by the agent. > To form the check list for a media stream, the agent forms candidate > pairs, computes a candidate pair priority, orders the pairs by > priority, prunes them, and sets their states. These steps are ^^^^^^^^^^^ "pruning" is eliminating duplicates, or something else? ("Prune" and "pruning" appear only twice in the document, and neither normatively explain dried plums (prunes).) > described in this section. Separate headings or bullets would really help this section. This one section has two paragraphs that start with "First, ". ... > Where O-P>A-P?1:0 is an expression whose value is 1 if O-P is greater > than A-P, and 0 otherwise. This formula ensures a unique priority > for each pair in most cases. One the priority is assigned, the agent ^^^ Once > sorts the candidate pairs in decreasing order of priority. If two > pairs have identical priority, the ordering amongst them is > arbitrary. > This sorted list of candidate pairs is used to determine a sequence > of connectivity checks that will be performed. Each check involves > sending a request from a local candidate to a remote candidate. > Since an agent cannot send requests directly from a reflexive > candidate, but only from its base, the agent next goes through the > sorted list of candidate pairs. For each pair where the local > candidate is server reflexive, the server reflexive candidate MUST be > replaced by its base. Once this has been done, the agent MUST remove > redundant pairs. A pair is redundant if its local and remote > candidates are identical to the local and remote candidates of a pair > higher up on the priority list. I believe the last 3 sentences, which are embedded in this paragraph, are describing the "pruning" step (a.k.a. "elimination of duplicates", yes), yes? If so, those sentences need to be pulled into its own header or section or bullet. > The result is called the check list > for that media stream, and each candidate pair on it is called a > check. > > Each check is also said to have a foundation, which is merely the > combination of the foundations of the local and remote candidates in > the check. > > Each check in the check list is associated with a state. This state > is assigned once the check list for each media stream has been > computed. There are five potential values that the state can have: Previous two paragraphs can be simplified and combined, thusly: Each check has a foundation and a state. The foundation is the combination of the local and remote candidates in the check. The state is assigned once the check list for each media stream has been computed. There are five states: ... > First, the agent sets all of the checks in each check list to the > Frozen state. Then, it takes the first check in the check list for > the first media stream (a media stream is the first media stream when > it is described by the first m-line in the SDP offer and answer), This parenthetical comment was important for the offerer to know when it was formings its SDP. It would be useful to place it there (section 4.3), to encourage the offerer to put the media lines it wants ICE to complete first in the front (for example, audio before video before whiteboarding, so we can all say "hello, do you see me yet" or whatever). ... > 5.8. Performing Periodic Checks "Performing Initial Periodic Checks"? > Checks are generated only by full implementations. Lite > implementations MUST skip the steps described in this section. > > An agent performs two types of checks. The first type are periodic > checks. These checks occur periodically for each media stream, and > involve choosing the highest priority check in the Waiting state from > each check list, and performing it. The other type of check is > called a triggered check. This is a check that is performed on > receipt of a connectivity check from the peer. This section > describes how periodic checks are performed. I noticed there is no section called "Performing Triggered Checks". There should be. The text appears to be in section 7.2.1, "Additional Procedures for Full Implementations". > Once the agent has computed the check lists as described in > Section 5.7, it sets a timer for each active check list. The timer > fires every Ta/N seconds, where N is the number of active check lists > (initially, there is only one active check list). Need a discussion of how Ta/N milliseconds was derived, perhaps in an Appendix, with a forward reference. > Implementations > MAY set the timer to fire less frequently than this. Ta is the same > value used to pace the gathering of candidates, as described in > Section 4.1.1. The first timer for each active check list fires > immediately, so that the agent performs a connectivity check the ^^^^^^^^^^^ > moment the offer/answer exchange has been done, followed by the next > periodic check Ta seconds later. This 'immediate' seems to conflict with the 'immediate' in section 5.3, "Gathering Candidates". Is it best to gather candidates first, or send connectivity checks? The end of section 7.2.1 requires the offerer to wait until it sees the SDP (containing the answerer's ICE password), so nothing can really happen until the offerer receives the answer, I guess. Maybe the order isn't important. Question: is the answerer's first binding discovery packet (to its STUN server) paced Ta milliseconds from its first connectivity check to its peer? > When the timer fires, the agent MUST find the highest priority check > in that check list that is in the Waiting state. The agent then > sends a STUN check from the local candidate of that check to the > remote candidate of that check. The procedures for forming the STUN > request for this purpose are described in Section 7.1.1. If none of > the checks in that check list are in the Waiting state, but there are > checks in the Frozen state, the highest priority check in the Frozen > state is moved into the Waiting state, and that check is performed. > When a check is performed, its state is set to In-Progress. If there > are no checks in either the Waiting or Frozen state, then the timer > for that check list is stopped. It's awkward how RFC3489bis's connectivity check retries work with ICE's timer. Not sure how to resolve that, though. > Performing the connectivity check requires the agent to know the > username fragment for the local and remote candidates, and the > password for the remote candidate. For periodic checks, the remote > username fragment and password are learned directly from the SDP > received from the peer, and the local username fragment is known by > the agent. > > 6. Receipt of the Initial Answer > > This section describes the procedures that an agent follows when it > receives the answer from the peer. It verifies that its peer > supports ICE, determines its role, ^^^^^^^^^^^^^^^^^^^ "determines its peer's role," > and for full implementations, > forms the check list and begins performing periodic checks. > > 6.1. Verifying ICE Support > > The answerer will proceed with the ICE procedures defined in this > specification if there is at least one a=candidate attribute for each > media stream in the answer it just received. If this condition is > not met, the agent MUST process the SDP based on normal RFC 3264 > procedures, without using any of the ICE mechanisms described in the > remainder of this specification, with the exception of Section 10, > which describes keepalive procedures. I noticed section 5.1 ("Verifying ICE Support") requires an a=candidate that matches its m/c line, but 6.1 doesn't have that requirement. I assume that's on purpose. > 7. Connectivity Checks > > This section describes how connectivity checks are performed. All > ICE implementations are required to be compliant to [11], as opposed > to the older [14]. However, whereas a full implementation will both > generate checks (acting as a STUN client) and receive them (acting as > a STUN server), a lite implementation will only ever receive checks, > and thus will only act as a STUN server. Should there be a forward reference, from section 5.8, "Performing Periodic Checks", to this section? > 7.1. Client Procedures > > These procedures define how an agent sends a connectivity check, > whether it is a periodic or a triggered check. These procedures are > only applicable to full implementations. > > 7.1.1. Sending the Request > > The agent acting as the client generates a connectivity check either ^^^^^^^^^^ the STUN client? > periodically, or triggered. ^^^^^^^^^ If an agent was triggered, it was acting as a STUN server just a split second ago (it received a connectivity check). Maybe delete that first sentence entirely? > In either case, the check is generated > by sending a Binding Request from a local candidate, to a remote > candidate. The agent must know the username fragment for both ^^^^^^^^^^^^^^^^^ transport address > candidates and the password for the remote candidate. ^^^^^^^^^^^^ local and remote candidates (Knowing the transport address is sortof obvious, but it allows us to explain two ways to "know" it: SDP or a receipt of a connectivity check (which causes us to initiate a triggered check)). ... > 7.1.2. Processing the Response > > If the STUN transaction generates an unrecoverable failure response What is a failure response? I expect it includes ICMP hard errors. Maybe ICMP soft errors? I expect it includes STUN errors. Would be good to enumerate them. > or times out, the agent sets the state of the check to Failed. The > remainder of this section applies to processing of successful > responses (any response from 200 to 299). ^^^^^^^^^^^^ any STUN response ... > 7.2. Server Procedures > > An agent MUST be prepared to receive a Binding Request on the base of > each candidate it included in its most recent offer or answer. > Receipt of a Binding Request on a transport address that the agent > had included in a candidate attribute is an indication that the "a transport address that the agent had included in a candidate attribute" is going to be received by the "base", right? Can we just say "base"? > connectivity check usage applies to the request. The meaning is the same in 17.3, but the wording is different. Here is 17.3: > The server is aware of this usage because it signaled this port > through the offer/answer exchange. Any STUN packets received on this > port will be for the connectivity check usage. It'd be good to have identical wording, or just forward reference 17.3. > The agent MUST use a short term credential to authenticate the > request and perform a message integrity check. The agent MUST accept > a credential if the username consists of two values separated by a > colon, where the first value is equal to the username fragment > generated by the agent in an offer or answer for a session in- > progress, and the password is equal to the password for that username > fragment. The password isn't sent in the STUN packet; rather, the MESSAGE-INTEGRITY is the output of a hash of the password and the STUN packet's contents. > It is possible (and in fact very likely) that an offeror > will receive a Binding Request prior to receiving the answer from its > peer. However, the request can be processed without receiving this > answer, and a response generated. Add: "By doing this, ICE processing completes faster." ... > 7.2.1. Additional Procedures for Full Implementations ... > Assuming a success response, if the source transport address of the > request does not match any existing remote candidates, it represents > a new peer reflexive remote candidate. The full-mode agent gives the > candidate a priority equal to the PRIORITY attribute from the > request. The type of the candidate is equal to peer reflexive. Its > foundation is set to an arbitrary value, different from the > foundation for all other remote candidates. Note that any subsequent > offer/answer exchanges will contain this new peer reflexive candidate > in the SDP, and will signal the actual foundation for the candidate. > This candidate is then added to the list of remote candidates. > However, the agent does not pair this candidate with any local > candidates. Add header, "Triggered Check" > Next, the agent constructs a tentative check in the reverse ^^^^^^^^^^^^^^^ Tentative check = triggered check? > direction, called a triggered check. The triggered check has a local > candidate equal to the candidate on which the STUN request was > received, and a remote candidate equal to the source transport > address where the request came from (which may be a new peer- > reflexive remote candidate). Since both candidates are known to the > agent, it can obtain their priorities and compute the candidate pair > priority. This tentative check is then looked up in the check list. > There can be one of several outcomes: > > o If there is already a check on the check list with this same local > and remote candidates, and the state of that check is Waiting or > Frozen, its state is changed to In-Progress and the tentative > check is performed. > > o If there is already a check on the check list with this same local > and remote candidates, and its state was In-Progress, the agent > SHOULD abandon the new tentative check and instead generate an ^^^^^^^^^ triggered? > immediate retransmit of the Binding Request for the check in > progress. This is to facilitate rapid completion of ICE when both > agents are behind NAT. ... > If the tentative check is to be performed, it is constructed and > processed as described in Section 7.1.1. These procedures require > the agent to know the username fragment and password for the peer. ^ transport address, > They are readily determined from the SDP and from the check that was ^^^^^^^^ ^^^^^ The username is source transport address of the STUN request > just received. The username fragment for the remote candidate is > equal to the bottom half (the part after the colon) of the USERNAME ^^^^^^ second I don't like "half", as it implies/requires that both ICE agents have the same length for their usernames. How about just saying: is equal to the part after the colon of the USERNAME > in the Binding Request that was just received. Using that username > fragment, the agent can check the SDP messages received from its peer > (there may be more than one in cases of forking), and find this > username fragment. The corresponding password is then selected. If > agent has not yet received this SDP (a likely case for the offerer in ^ username in > the initial offer/answer exchange), it MUST wait for the SDP to be > received, and then proceed with the triggered check. Add: It must wait because it won't have its peer's ICE password until it has the SDP. ... > 8. Concluding ICE ... > An alternative is called "proactive selection". In this approach, > the controlling agent includes the USE-CANDIDATE attribute in every > check it sends. Once the first check for a component succeeds, it is > used by ICE. ^^^^^^^^^^^ "Used by ICE" means ICE declares itself finished, media starts flowing? (the term is only used a few times in the document, but never with this meaning.) ... > If an agent is controlling and its peer has a lite implementation, an > agent MUST use an introspective selection algorithm. Of course, it > MAY select a favored pair based on ICE's prioritization. The key > requirement is that the agent must complete a successful check before ^^^^ MUST > redoing it with the USE-CANDIDATE attribute. (Is this because a Lite implementation will immediately start sending data when it sees a USE-CANDIDATE? What's the reason for this key requirement?) ... > 9. Subsequent Offer/Answer Exchanges > > An agent MAY generate a subsequent offer at any time. ^^^^^^^^ ^^^^^^^^^^^ "Either agent" ? not while there is an outstanding offer, though; perhaps cite O/A as the canonical rulemaker so that ICE isn't excused from changing O/A rules? > However, the Delete "However," ... > 9.1.2. Additional Procedures for Lite Implementations > > A passive-only agent includes its one and only candidate for each ^^^^^^^^^^^^^^^^^^ Lite implementation > component of each media stream in an a=candidate attribute in any > subsequent offer. This candidate is formed identically to the > procedures for initial offers, as described in Section 4.2. > > 9.2. Receiving the Offer and Generating an Answer > > When receiving a subsequent offer within an existing session, an > agent MUST re-apply the verification procedures in Section 5.1 > without regard to the results of verification from any previous > offer/answer exchanges. Indeed, it is possible that a previous > offer/answer exchange resulted in ICE not being used, but it is used > as a consequence of a subsequent exchange. > > If the offer contained a change in the a=ice-ufrag or a=ice-pwd > attributes compared to the previous SDP from the peer, it is a signal > that ICE is restarting for this media stream. If all media streams > are restarting, than ICE is restarting overall. Procedures for ICE > restarts are discussed below. Unless ICE is restarting for that > media stream, an agent MUST NOT change the a=ice-ufrag or a=ice-pwd > attributes in an answer relative to the last SDP it provided. Such a > change can only take place in an offer. If ICE is restarting, the > a=ice-ufrag and a=ice-pwd attributes MUST be changed. > > An agent MUST NOT change its implementation level from its previous > SDP unless, based on the offer, ICE procedures are being restarted > for all media streams in the offer. In that case, it MAY change its > level. The two paragraphs above would be easier to parse if the allowed and prohibited actions were on bulleted or enumerated lists. > An agent MUST NOT include the a=remote-candidates attribute in an > answer. Is this prohibited only in Subsequent O/A? I would think it's also prohibited in initial O/A, too? > When the answerer generates its answer, it must decide what > candidates to include in the answer, how to populate the m/c-line, > and how to adjust the states of ICE processing. The rules for > inclusion of candidate attributes in an answer are identical to the > rules followed by the offerer as described in Section 9.1 for both > full and lite implementations. For lite implementations, those rules > also apply for setting the m/c-line. However, additional > considerations apply to full implementations. > > 9.2.1. Additional Procedures for Full Implementations > > The computation of the m/c-line additionally depends on the presence > or absence of the a=remote-candidates attribute in a media stream. > If present, it means that the offerer (acting as the controlling > agent) believed that ICE processing has completed for that media > stream. In this case, the remote-candidates attribute contains the > candidates that the answerer is supposed to use. It is possible that > the agent doesn't even know of these candidates yet; they will be ^^^^^^^^^ the answering agent > discovered shortly through a response to an in-progress check. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ a.k.a "triggered check" ?? > full-mode agent MUST populate the m/c-line with the candidates from > the a=remote-candidates attribute. ... > 9.3.1. Additional Procedures for Full Implementations ... > Next, the agent goes through each check list, starting with the > highest priority check. If a check has a state of Succeeded, and it > has a component ID of 1, Why "1" instead of "the lowest-numbered component"? ... > 10. Keepalives ... > If there has been no packet sent on a candidate pair being used for > media for Tr seconds (where packets include media and previous ^^^^^ RTCP isn't "media", but we want keepalives on RTCP if it hasn't been used in awhile, too? (Not usually a problem, as RTCP is sent often enough to keep NATs happy). How about striking "being used for media" and instead say "active candidate pair"? > keepalives), an agent MUST generate a keepalive on that pair. Tr > SHOULD be configurable and SHOULD have a default of 15 seconds. > > If STUN is being used for keepalives, a STUN Binding Indication is > used [11]. The Binding Indication SHOULD NOT contain integrity > checks; since the messages are simply discarded on receipt regardless > of contents. The Indication SHOULD NOT contain the PRIORITY or USE- > CANDIDATE attributes defined here. ^^^^ in this document. ... > 11.1.1. Procedures for Full Implementations > > Agents always send media using a candidate pair. An agent will send > media to the remote candidate in the pair (setting the destination > address and port of the packet equal to that remote candidate), and > will send it from the local candidate. When the local candidate is > server or peer reflexive, media is originated from the base. Media > sent from a relayed candidate is sent through that relay, using ^^^^^^^ from the base to > procedures defined in [12]. > > If the state of a media stream is Running, there is no old Valid list > for that media stream (which would be due to an ICE restart), an > agent MUST NOT send media. The above paragraph is describing the 'check list state' from 5.7? If so, might want to be clearer about that. The previous paragraph needs to justify that MUST; providing a forward reference to the voice hammer section (16.4.1) should be sufficient for that justification. > When an agent sends media, it MUST send it using the highest priority > selected pair for each component in either the old Valid list for a > media stream (if it exists), else the new Valid list for that media > stream. In several cases, this will not be the same candidate pairs > present in the m/c-line. When ICE first completes, if the selected > pairs aren't a match for the m/c-line, an updated offer/answer > exchange will take place to remedy this disparity. However, until > that update offer arrives, there will not be a match. Furthermore, ^^^^^^ updated > in very unusual cases, the m/c-lines in the updated offer/answer will > not be a match. > > ICE has interactions with jitter buffer adaptation mechanisms. An > RTP stream can begin using one candidate, and switch to another one, > though this happens rarely with ICE. The newer candidate may result > in RTP packets taking a different path through the network - one with > different delay characteristics. As discussed below, agents are > encouraged to re-adjust jitter buffers when there are changes in > source or destination address. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ a.k.a. "in-use candidates"? > Furthermore, many audio codecs use > the marker bit provide reference to RFC3550. > to signal the beginning of a talkspurt, for the > purposes of jitter buffer adaptation. For such codecs, it is > RECOMMENDED that the sender change the marker bit when an agent ^^^^^^ set > switches transmission of media from one candidate pair to another. Why do both, I wondered. Then the answer hit: the other endpoint might not always realize we switched transport addresses (because everything is going through a relay, and they're unaware of it). Might want to point that out. The whole previous paragraph, starting with "ICE has interactions with jitter buffer", should be moved into section 11.2, "Receiving media", which also talks about jitter buffers and SSRC collisions and whatnot. > 11.1.2. Procedures for Lite Implementations > > A lite implementation MUST NOT send media until it has a Valid list > that contains a candidate pair for each component of that media > stream. I believe you should do a forward reference to Voice Hammer (16.4.1). ... > 11.2. Receiving Media > > ICE implementations MUST be prepared to receive media on any ^^^^^^^^^^^^^ "Receive and play it out", or do we not want to open that pandora's box? > candidates provided in the most recent offer/answer exchange. What about non-media, like RTCP? Should it expect to see RTCP SR or RR reports? Do those need to be witheld to prevent voice hammer of RTCP traffic (probably so; I don't think that's quite clear if one considers RTP="media", and RTCP="media control"). > 12.1. Latency Guidelines ... > If an offer is received in an INVITE request, the callee SHOULD ^^^^^^ answerer (several occurances of "callee" appear in this section.) > immediately gather its candidates and then generate an answer in a > provisional response. Does this suggestion override the previous 'immediate' suggestions in 5.3 and 5.8? > ICE requires that a provisional response with > an SDP be transmitted reliably. This can be done through the > existing PRACK mechanism [9], or through an optimization that is > specific to ICE. With this optimization, provisional responses > containing an SDP answer that begins ICE processing for one or more > media streams can be sent reliably without RFC 3264. To do this, the > agent retransmits the provisional response with th exponential > backoff timers described in RFC 3262. Retransmits MUST cease on > receipt of a STUN Binding Request for one of the media streams > signaled in that SDP or on transmission of a 2xx response. Add: ", because receipt of a binding request indicates the offerer has received the answer." ... ... > However, prior to this point, any media that needs to be sent towards > the caller (such as SIP early media [25] cannot be transmitted. I believe it's "MUST NOT", rather than "cannot" -- the answerer knows a transport address, and "can" use it. I would change this to "MUST NOT" and provide a forward reference to the voice hammer attack. ... > In addition to uses where the offer is in an INVITE, and the answer > is in the provisional and/or 200 OK, ICE works with cases where the > offer appears in the response. In such cases, which are common in > third party call control, Need a citation to third party call control. > ICE agents SHOULD generate their offers in > a reliable provisional response (which MUST utilize RFC 3262). In > that case, the answer will arrive in a PRACK. This allows for ICE > processing to take place prior to alerting. Once ICE completes, the > agent can alert the user and then generate a 200 OK. 200 OK before the user answers? (Sorry if a silly question; third party call control isn't my best subject.) > The 200 OK > would contain no SDP, since the offer/answer exchange has completed. > Agents MAY place the offer in a 2xx instead (in which case the answer > comes in the ACK). This flow is simpler but results in a poorer user > experience. The previous paragraph, discussing third party call control, should be moved out of this latency section and into the third party call control section (12.5). > As discussed in Section 16, offer/answer exchanges SHOULD be secured > against eavesdropping and man-in-the-middle attacks. To do that, the > usage of SIPS [3] is RECOMMENDED when used in concert with ICE. That last pargraph doesn't belong in the Latency Guidelines section. Perhaps in Security Considerations? ... > 12.3. Interactions with Forking > > ICE interacts very well with forking. Indeed, ICE fixes some of the > problems associated with forking. Without ICE, when a call forks and > the caller receives multiple incoming media streams, it cannot > determine which media stream corresponds to which callee. ^^^^^^ called party > > With ICE, this problem is resolved. The connectivity checks which > occur prior to transmission of media carry username fragments, which > in turn are correlated to a specific callee. Subsequent media ^^^^^^ called party > packets which arrive on the same 5-tuple as the connectivity check ^^^^^^^ this is a new term. How about 'transport address'? > will be associated with that same callee. Thus, the caller can ^^^^^^ called party > perform this correlation as long as it has received an answer. ... > 13. Grammar ... > password = 22*ice-char > ufrag = 4*ice-char To successfully disambiguate forked calls, the username needs to be long enough so that each called party has a chance to pick a unique value without the birthday paradox. I don't think 24 (4*6) bits is sufficient for this. > The "ice-pwd" and "ice-ufrag" attributes can appear at either the > session-level or media-level. When present in both, the value in the > media-level takes precedence. Thus, the value at the session level > is effectively a default that applies to all media streams, unless > overriden by a media-level value. > > The "ice-options" attribute is a session level attribute. It > contains a series of tokens which identify the options supported by > the agent. Its grammar is: > > > ice-options = "ice-options" ":" ice-option-tag > 0*(SP ice-option-tag) > ice-option-tag = 1*ice-char This is the first time ice-options has been introduced. > 15. Example > > Two agents, L and R, are using ICE. Both are full-mode ICE > implementations. Both agents have a single IPv4 interface. For > agent L, it is 10.0.1.1, and for agent R, 192.0.2.1. ^^ ^^ in private address space [RFC1918] on the public Internet > Both are > configured with a single STUN server each (indeed, the same one for > each), Replace that parenthetical comment with: (as shown in this example for simplicity although in practice the agents do not need to use the same STUN server) > which is listening for STUN requests at an IP address of > 192.0.2.2 and port 3478. This STUN server supports only the Binding > Discovery usage; relays are not used in this example. Agent L is > behind a NAT, and agent R is on the public Internet. The NAT has an > endpoint independent mapping property and an address dependent > filtering property. The public side of the NAT has an IP address of > 192.0.2.3. A figure would help: STUN Server | L----[NAT]------+---------R ... > Agents L and R both pair up the candidates. They both initially have > two. However, agent L will prune the pair containing its server ^^^^^^^^^^^^^^ a.k.a. eliminate redundant candidates > reflexive candidate, resulting in just one. At agent L, this pair > (the check) has a local candidate of $L_PRIV_1 and remote candidate > of $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note > that an implementation would represent this as a 64 bit integer so as > not to lose precision). At agent R, there are two checks. The > highest priority has a local candidate of $R_PUB_1 and remote > candidate of $L_PRIV_1 and has a priority of 4.57566E+18, and the > second has a local candidate of $R_PUB_1 and remote candidate of > $NAT_PUB_1 and priority 3.63891E+18. > > Agent R begins its connectivity check (message 9) for the first pair > (between the two host candidates). Since R is the passive agent for > this session, the check omits the USE-CANDIDATE attribute. The host > candidate from agent L is private and behind a different NAT, and ^^^^^^^^^ delete "different" (there is only one NAT) > thus this check is discarded. ^^^^^^^^^ "won't be successful, because the packet cannot be routed from R to L." ... > Upon receipt of the check from agent L (message 11), agent R will ^^^^^ STUN binding request > generate its triggered check. This check happens to match the next > one on its check list - from its host candidate to agent L's server > reflexive candidate. This check (messages 14-17) will succeed. > Consequently, agent R constructs a new candidate pair using the > mapped address from the response as the local candidate (R-PUB-1) and > the destination of the request (NAT-PUB-1) as the remote candidate. > This pair is added to the Valid list for that media stream. Since > the check was generated in the reverse direction of a check that > contained the USE-CANDIDATE attribute, the candidate pair is marked > as selected. Consequently, processing for this stream moves into the > Completed state, and agent R can also send media. L now needs to send an updated offer, correct? > Of the various techniques for creating faked STUN messages described > in [11], many are not applicable for the connectivity checks. > Compromises of STUN servers are not much of a concern, since the STUN > servers are embedded in endpoints and distributed throughout the ^^^^^^^^^^^^ in the endpoint's ICE-aware application software > network. Thus, compromising the STUN server is equivalent to ^^^^^^^^^^^^^^^ the peer's embedded STUN server > comprimising the endpoint, and if that happens, far more problematic > attacks are possible than those against ICE. Similarly, DNS attacks > are usually irrelevant since STUN servers are not typically > discovered via DNS, they are signaled via IP addresses embedded in > SDP. ICE does allow using FQDN, though. But then, so does SDP. Perhaps show how if you're using FQDN with SDP, ICE doesn't make the DNS vulernerability worse than it already was. ... > Forcing the false peer reflexive candidate result with packet replays > is different. The attacker waits until one of the agents sends a > check. It intercepts this request, and replays it towards the other > agent with a faked source IP address. It must also prevent the > original request from reaching the remote agent, either by launching > a DoS attack to cause the packet to be dropped, or forcing it to be > dropped using layer 2 mechanisms. The replayed packet is received at > the other agent, and accepted, since the integrity check passes (the > integrity check cannot and does not cover the source IP address and > port). It is then responded to. This response will contain a XOR- > MAPPED-ADDRESS with the false candidate, and will be sent to that > false candidate. The attacker must then intercept it and relay it ^^^^^^^^^ receive > towards the originator. > > The other agent will then initiate a connectivity check towards that > false candidate. This validation needs to succeed. This requires > the attacker to force a false valid on a false candidate. Injecting > of fake requests or responses to achieve this goal is prevented using > the integrity mechanisms of STUN and the offer/answer exchange. > Thus, this attack can only be launched through replays. To do that, > the attacker must intercept the check towards this false candidate, > and replay it towards the other agent. Then, it must intercept the > response and replay that back as well. > > This attack is very hard to launch unless the attacker themself is > identified by the fake candidate. Considering botnets, I wouldn't say this is a risk or worry to most attackers. > This is because it requires the > attacker to intercept and replay packets sent by two different hosts. > If both agents are on different networks (for example, across the > public Internet), this attack can be hard to coordinate, since it > needs to occur against two different endpoints on different parts of > the network at the same time. I suggest deleting the above paragraph. It's overly optimistic that the attack is difficult. > If the attacker themself is identified by the fake candidate the ^^^^^^^^ Delete "themself" > attack is easier to coordinate. However, if SRTP is used [22], the > attacker will not be able to play the media packets, they will only > be able to discard them, effectively disabling the media stream for > the call. However, this attack requires the agent to disrupt packets > in order to block the connectivity check from reaching the target. > In that case, if the goal is to disrupt the media stream, its much > easier to just disrupt it with the same mechanism, rather than attack > ICE. > > 16.2. Attacks on Address Gathering > > ICE endpoints make use of STUN for gathering candidates rom a STUN "rom" -> "from" > server in the network. This is corresponds to the Binding Discovery > usage of STUN described in [11]. As a consequence, the attacks > against STUN itself that are described in that specification can > still be used against the binding discovery usage when utilized with > ICE. > > However, the additional mechanisms provided by ICE actually > counteract such attacks, making binding discovery with STUN more > secure when combined with ICE than without ICE. > > Consider an attacker which is able to provide an agent with a faked > mapped address in a STUN Binding Request that is used for address > gathering. This is the primary attack primitive described in [11]. > This address will be used as a server reflexive candidate in the ICE > exchange. For this candidate to actually be used for media, the > attacker must also attack the connectivity checks, and in particular, > force a false valid on a false candidate. This attack is very hard > to launch if the false address identifies a third party, L and R are the 1st and 2nd parties. Is the attacker is the 3rd party? Or are you talking about a 4th party (someone other than the attacker)? > and is > prevented by SRTP if it identifies the attacker themself. ... > 16.4.1. The Voice Hammer Attack > > The voice hammer attack is an amplification attack. In this attack, > the attacker initiates sessions to other agents, sends an Invite? (or are you trying to be non-SIP-specific?) > and includes the IP ^ maliciously > address and port of a DoS target in the m/c-line of their SDP. This > causes substantial amplification; a single offer/answer exchange can > create a continuing flood of media packets, possibly at high rates > (consider video sources). This attack is not specific to ICE, but > ICE can help provide remediation. > > Specifically, if ICE is used, the agent receiving the malicious SDP > will first peform connectivity checks to the target of media before > sending it there. If this target is a third party host, the checks ^^ media > will not succeed, and media is never sent. ... > 16.4.2. STUN Amplification Attack > > The STUN amplification attack is similar to the voice hammer. > However, instead of voice packets being directed to the target, STUN > connectivity checks are directed to the target. This attack is > accomplished by having the offerer send an offer with a large number > of candidates, say 50. Nit. Replace last sentence with: "The attaker sends an offer with a large number of candidates, say 50." > The answerer receives the offer, and starts > its checks, which are directed at the target, and consequently, never > generate a response. The answerer will start a new connectivity > check every 20ms, and each check is a STUN transaction consisting of > 7 transmissions of a message 65 bytes in length (plus 28 bytes for > the IP/UDP header) that runs for 7.9 seconds, for a total of 58 > bytes/second per transaction on average. In the worst case, there > can be 395 transactions in progress at once (7.9 seconds divided by > 20ms), for a total of 182 kbps, just for STUN requests. > > It is impossible to eliminate the amplification, but the volume can > be reduced through a variety of heuristics. Agents SHOULD limit the > total number of connectivity checks they perform to 100. > Additionally, agents MAY limit the number of candidates they'll > accept in an offer or answer. The last paragraph needs to be discussed earlier, too, somewhere in section 7, with a forward reference to here. ... > 16.5. Interactions with Application Layer Gateways and SIP > > If an ALG is SIP aware but not ICE aware, ICE will work through it as > long as the ALG correctly modifies the m/c-lines of SDP. In this > case, correctly means that the ALG does not modify m/c-lines with > external addresses. If the m/c-line contains internal addresses, but > ones for which a public binding exists, the ALG replaces the internal > address in the m/c-line with the public binding. That last sentence doesn't parse well. > Unfortunately, many > ALG are known to work poorly in these corner cases. ICE does not try > to work around broken ALGs, as this is outside the scope of its > functionality. ICE can help diagnose these conditions, which often > show up as a mismatch between the set of candidates and the m/c-line. > The a=ice-mismatch parameter is used for this purpose. ^^^^^^^^^^^^^^^^^^^^^^^^ ice-mismatch attribute ... > If an SBC is SIP aware but not ICE aware, the result depends on the > behavior of the SBC. If it is acting as a proper Back-to-Back User > Agent (B2BUA), the SBC will remove any SDP attributes it doesn't > understand, including the ICE attributes. Consequently, the call > will appear to both endpoints as if the other side doesn't support > ICE. This will result in ICE being disabled, and media flowing > through the SBC, if they SBC has requested it. ^^^^ the ?? > If, however, the SBC > passes the ICE attributes without modification, yet modifies the m/c- > lines, this will be detected as an ICE mismatch, and ICE processing > is aborted for the call. It is outside of the scope of ICE for it to > act as a tool for "working around" SBCs. If one is present, ICE will > not be used and the SBC techniques take precedence. > > ... > 17.1. Applicability > > This STUN usage provides a connectivity check between two peers > participating in an offer/answer exchange. This check serves to > validate a pair of candidates for usage of exchange of media. > Connectivity checks also allow agents to discover reflexive > candidates towards their peers, called peer reflexive candidates. > Finally, connectivity checks serve to keep NAT bindings alive. Delete last sentence (keepalives are now done with Binding Indications). > It is fundamental to this STUN usage that the addresses and ports > used for media are the same ones used for the Binding Requests and > responses. Consequently, it will be necessary to demultiplex STUN > traffic from whatever the media traffic is. This demultiplexing is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ other applications on that same port (e.g., RTP or RTCP) > done using the techniques described in [11]. That last paragraph seems a pretty important concept, and something that should be in the Overview section. > 17.2. Client Discovery of Server > > The client does not follow the DNS-based procedures defined in [11]. > Rather, the remote candidate of the check to be performed is used as > the transport address of the STUN server. Note that the STUN server > is a logical entity, and is not a physically distinct server in this > usage. > > 17.3. Server Determination of Usage > > The server is aware of this usage because it signaled this port > through the offer/answer exchange. Any STUN packets received on this > port will be for the connectivity check usage. Add: "Or for the keepalive usage." > 17.4. New Requests or Indications > > This usage does not define any new message types. > > 17.5. New Attributes > > This usage defines two new attributes, PRIORITY and USE-CANDIDATE. > > The PRIORITY attribute indicates the priority that is to be > associated with a peer reflexive candidate, should one be discovered > by this check. It is a 32 bit unsigned integer, and has an attribute > type of 0x0024. ^^^^ value > > The USE-CANDIDATE attribute indicates that the candidate pair > resulting from this check should be used for transmission of media. > The attribute has no content (the Length field of the attribute is > zero); it serves as a flag. It has an attribute type of 0x0025. ^^^^ value ... > 19.5. Issues with Existing NAPT Boxes > > From RFC 3424, any UNSAF proposal must provide: > > Discussion of the impact of the noted practical issues with > existing, deployed NA[P]Ts and experience reports. > > A number of NAT boxes are now being deployed into the market which > try and provide "generic" ALG functionality. These generic ALGs hunt > for IP addresses, either in text or binary form within a packet, and > rewrite them if they match a binding. This interferes with > traditional STUN. However, the update to STUN [11] uses an encoding > which hides these binary addresses from generic ALGs. Since [11] is > required for all ICE implementations, this NAPT problem does not > impact ICE. Delete the last sentence; in this version of ICE, [11] _is_ a requirement, and its XOR-MAPPED-ADDRESS resolves this problem. > Existing NAPT boxes have non-deterministic and typically short > expiration times for UDP-based bindings. This requires > implementations to send periodic keepalives to maintain those > bindings. ICE uses a default of 15s, which is a very conservative > estimate. Eventually, over time, as NAT boxes become compliant to > behave [31], this minimum keepalive will become deterministic and > well-known, and the ICE timers can be adjusted. Having a way to > discover and control the minimum keepalive interval would be far Should provide forward reference to B.1, "Pacing of STUN Transactions". > Appendix A. Lite and Full Implementations > > ICE allows for two types of implementations. A full implementation > supports the controlling and controlled roles in a session, and can > also perform address gathering. In contrast, a lite implementation > is a minimalist implementation that does little but respond to STUN > checks. > > Because ICE requires both endpoints to support it in order to bring > benefits to either endpoint, incremental deployment of ICE in a > network is more complicated. Many sessions involve an endpoint which > is, by itself, not behind a NAT and not one that would worry about > NAT traversal. Examples include gateways to the PSTN, media servers, > conference bridges, and application servers. Same comment I had previously: this provides a get-out-of-jail-free card to vendors building these devices to only built a Lite implementation, even when those devices are known to be behind NATs most of the time. > A very common case is > to have one endpoint that requires NAT traversal (such as a VoIP hard > phone or soft phone) make a call through one of these devices. Even ^^^^^^^ to > if the phone supports a full ICE implementation, ICE won't be used at > all if the other device doesn't support it. The lite implementation > allows for a low-cost entry point for these devices. Once they > support the lite implementation, full implementations can connect to > them and get the full benefits of ICE. > > Consequently, a lite implementation is only appropriate for devices > that will always be connected to the public Internet and have a > public IP address at which it can receive packets from any > correspondent. ICE will not function when a lite implementation is > placed behind a NAT. > > It is important to note that the lite implementation was added to > this specification to provide a stepping stone to full > implementation. Even for devices that are always connected to the > public Internet, a full implementation is preferable if achievable. > A full implementation will reduce call setup times. Full > implementations also obtain the security benefits of ICE unrelated to > NAT traversal; in particular, the voice hammer attack described in > Section 16 is prevented only for full implementations, not lite. > Finally, it is often the case that a device which finds itself with a > public address today will be placed in a network tomorrow where it > will be behind a NAT. It is difficult to definitively know, over the > lifetime of a device or product, that it will always be used on the > public Internet. Full implementation provides assurance that > communications will always work. The last two paragraphs ("Consequently, ..." and "It is important") are too important to put down here. I would bring them up to the Overview, when Lite is introduced. Might be good to just move all of Appendix A up to the Overview, in fact. ... > B.1. Pacing of STUN Transactions > > STUN transactions used to gather candidates and to verify > connectivity are paced out at an approximate rate of one new > transaction every Ta seconds, where Ta has a default of 20ms. Why ^^^^^^^ milliseconds > are these transactions paced, and why was 20ms chosen as default? ... > B.4. Importance of the STUN Username ... > An unfortunate consequence of the non-uniqueness of IP addresses is > that, in the above example, B might not even be an ICE agent. It > could be any host, and the port to which the STUN packet is directed > could be any ephemeral port on that host. If there is an application > listening on this socket for packets, and it is not prepared to > handle malformed packets for whatever protocol is in use, the > operation of that application could be affected. Fortunately, since > the ports exchanged in SDP are ephemeral and usually drawn from the > dynamic or registered range, the odds are good that the port is not > used to run a server on host B, but rather is the agent side of some > protocol. This decreases the probability of hitting a port in-use, > due to the transient nature of port usage in this range. However, > the possibility of a problem does exist, and network deployers should > be prepared for it. Note that this is not a problem specific to ICE; > stray packets can arrive at a port at any time for any type of > protocol, especially ones on the public Internet. As such, this > requirement is just restating a general design guideline for Internet > applications - be prepared for unknown packets on any port. Should the above paragraph be in IAB considerations? It's a pretty damning part of ICE, which we have all long accepted, but it's going to surprise a goodly number of people. Perhaps in the "Brittleness Introduced by ICE" section some mention could be made with a forward reference to this detailed Design Motivation. ... > B.11. Why are Binding Indications Used for Keepalives? ... > Additionally, using a Binding Indication allows integrity to be > disabled, allowing for better performance. This is useful for large > scale endpoints, such as PSTN gateways. and SBCs. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jan 21 03:45:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8YJp-0002eC-Hf; Sun, 21 Jan 2007 03:44:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8YJo-0002e7-7O for mmusic@ietf.org; Sun, 21 Jan 2007 03:44:52 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8YJk-0001S4-Hu for mmusic@ietf.org; Sun, 21 Jan 2007 03:44:52 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B7E0C205DA; Sun, 21 Jan 2007 09:44:39 +0100 (CET) X-AuditID: c1b4fb3c-af6a2bb000003b9d-b0-45b327f7d449 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A4377205C3; Sun, 21 Jan 2007 09:44:39 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jan 2007 09:44:39 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jan 2007 09:44:38 +0100 Received: from [131.160.126.192] (rvi2-126-192.lmf.ericsson.se [131.160.126.192]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 66A66236E; Sun, 21 Jan 2007 10:44:38 +0200 (EET) Message-ID: <45B327F5.2010507@ericsson.com> Date: Sun, 21 Jan 2007 10:44:37 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jonathan Rosenberg References: <458263F0.4050206@ericsson.com> <459D4F54.6030305@cisco.com> In-Reply-To: <459D4F54.6030305@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2007 08:44:38.0702 (UTC) FILETIME=[62B7BCE0:01C73D38] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mmusic Subject: [MMUSIC] Re: Comment on TCP ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Jonathan, yes, please, go ahead add text clarifying the issue. The thing is that some sessions actually have media streams that end way before the session (e.g., a file transfer). We need to be clear on what to do if one needs to terminate a, say, TCP connection in the middle of a session and is using ICE. Cheers, Gonzalo Jonathan Rosenberg wrote: > Sorry for the long delay in responding to all of these. I am finally > getting back to work on this after a work-based hiatus. > > inline. > > Gonzalo Camarillo wrote: > >> Hi, >> >> the TCP ICE spec changes the way TCP connection reestablishment works in >> RFC 4145. RFC 4145 allows applications to close a TCP connection without >> requiring a new offer/answer exchange. However, a new offer/answer >> exchange is required to reestablish (i.e., repair) a connection. >> >> TCP ICE, on the other hand, requires a new offer/answer exchange to >> close a TCP connection, but does not require it to repair a connection. > > It is not the intent that a new exchange is required to close a > connection. The intention is that once a connection is up and in use for > media, it will stay up and should not normally be closed. However, if > the client needs to close it, or it closes due to some temporary glitch, > thats fine - no new o/a exchange is needed to reopen one. The only case > in which you would normally close a connection is when a media stream > ends, which does require a new O/A exchange. > > >> >> The ICE TCP spec says: >> >> "Unlike RFC 4145, additional signaling is not required to repair a >> closed connection." >> >> I believe that the ICE TCP spec needs to give a slightly longer >> explanation about it so that implementers understand both differences. >> Maybe an extra paragraph along the lines of this email. > > I think clearly explanation is needed. If the above sounds OK to you, I > will add text clarifying that. > > -Jonathan R. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jan 21 03:46:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8YLA-0003ln-2n; Sun, 21 Jan 2007 03:46:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8YL9-0003kF-4R for mmusic@ietf.org; Sun, 21 Jan 2007 03:46:15 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8YL3-0001Xt-Ib for mmusic@ietf.org; Sun, 21 Jan 2007 03:46:15 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E2262203B0; Sun, 21 Jan 2007 09:46:00 +0100 (CET) X-AuditID: c1b4fb3e-a80eabb000002522-ca-45b32848199b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D620A201BF; Sun, 21 Jan 2007 09:46:00 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jan 2007 09:46:00 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jan 2007 09:45:55 +0100 Received: from [131.160.126.192] (rvi2-126-192.lmf.ericsson.se [131.160.126.192]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 41983236E; Sun, 21 Jan 2007 10:45:55 +0200 (EET) Message-ID: <45B32842.6010800@ericsson.com> Date: Sun, 21 Jan 2007 10:45:54 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jonathan Rosenberg References: <4581A5E9.3040801@ericsson.com> <459D502A.5040104@cisco.com> In-Reply-To: <459D502A.5040104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2007 08:46:00.0119 (UTC) FILETIME=[933EFC70:01C73D38] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mmusic Subject: [MMUSIC] Re: Passive and passive-only terminology in ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, yes, a clarification along these lines will be great. Thanks, Gonzalo Jonathan Rosenberg wrote: > We had a separate thread on this. We agreed to change the terminology to > the following. > > There are two different types of implementations: passive-only and full. > A full implementation can operate in one of two modes - controlling or > controlled. A passive-only operates in only one mode - passive. In > passive mode, no triggered or periodic checks are sent. However, both > are sent in controlled mode. > > One wrinkle I ran into is that there is also a minor variation in the > controlling mode. If an agent is controlling, and its peer is in passive > mode, its behavior is slightly different than when its controlling and > its peer is controlled. Namely, it cannot use the done flag in a stun > transaction on a pair which hasn't completed succesfully yet. It will > also see incoming stun requests. I debated whether to describe this as a > different mode, but I think its close enough that it doesn't warrant it. > Rather I'll describe this exception as part of the desription of the > controlling mode operation. > > Thanks, > Jonathan R. > > Gonzalo Camarillo wrote: > >> Hi, >> >> a passive agent (as opposed to a controlling agent) generates periodic >> connectivity checks. However, a passive-only agent does not (need to) >> generate them. >> >> Using the same terminology for both (i.e., passive) may be confusing. >> It may lead some readers to think that passive agents do not perform >> periodic checks, for instance. >> >> This is no big deal, but if somebody else agrees that this may be >> confusing, we could think of using a different term for one of those >> concepts. >> >> Cheers, >> >> Gonzalo >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 22 07:44:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8yWJ-0004Op-2f; Mon, 22 Jan 2007 07:43:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8yWH-0004Oi-J2 for mmusic@ietf.org; Mon, 22 Jan 2007 07:43:29 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8yWE-0001l5-Tu for mmusic@ietf.org; Mon, 22 Jan 2007 07:43:29 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l0MChGO2028803; Mon, 22 Jan 2007 13:43:16 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l0MChF6I020145; Mon, 22 Jan 2007 13:43:15 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 13:43:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [MMUSIC] New ID, related to media stream dependencies Date: Mon, 22 Jan 2007 13:43:14 +0100 Message-ID: <72963DDDF17D7949ABD18DC5DA58E77001AC919A@MCHP7R5A.ww002.siemens.net> In-Reply-To: <45B1512F.8050409@avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] New ID, related to media stream dependencies Thread-Index: Acc8H8zNJbXzGBzKRoS2GWZPg7PXzQCArFNA From: "Schmidt, Christian" To: "Robert R. Gilman" , "Dan Wing" X-OriginalArrivalTime: 22 Jan 2007 12:43:15.0573 (UTC) FILETIME=[E2A6A250:01C73E22] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: MMusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org =20 Hi Robert and Dan, =20 the example with the subtitle may be not the best one, but I can imagine = cases, where the offerer has dependency information, not available to = the receiver. For example in case of media streaming, the key for = decryption could be send via instant messaging. In this case, the = offerer can provide this information via dependency attribute. The = receiption of video media without the proper decryption information = would make no sense.=20 =20 Furthermore, a possible application for the dependency attribute could = be used for the selection of mendatory media streams, all participants = of a conference are able to share. =20 The dependency information can be seen as capability negotiation, = therefore it would make sense to include it to the current activites for = capability negotation. What do you think? The related requirement could = look like: =20 REQ-155: It SHOULD be possible to specify dependencies between media = lines, based on the decision of the offerer. The receiver should accept = media lines only if he is willing and able to accept all mandatory = dependent media lines as well. This could avoid redundant call attempts = and for example increase interoperability in conferences. =20 On Tuesday, I will try to attend the planned confcall. Best Regards Christian Schmidt =20 -----Urspr=FCngliche Nachricht----- Von: Robert R. Gilman [mailto:rrg@avaya.com]=20 Gesendet: Samstag, 20. Januar 2007 00:16 An: Dan Wing Cc: Schmidt, Christian; 'MMusic' Betreff: Re: [MMUSIC] New ID, related to media stream dependencies Dan- As it stands now, the capneg definitions don't support that. = Requirements 150 and 160 of the requirements draft say: REQ-150: It SHOULD be possible to specify valid combinations of = media lines. For example, an entity may be able to support audio and = video or audio and IM, but not video and IM (or all three). REQ-160: It SHOULD be possible to specify valid combinations of = media formats between media streams. For example, there may be constraints on which combinations = of audio and video codecs can be supported. I've been thinking about some session-level constraints that might be = used for REQ-160. For example, one might define a ccons: attribute that listed acceptable combinations of codecs - I was considering the = processing- power constraints between specific codecs (e.g., codec a1 and codec v1 = or codec a2 and codec v2). Christian's goal is described by REQ-150 - = making sure the responder doesn't do something silly like open a subtitles = stream with no video stream. In that particular case, it's not clear to me = that the responder wouldn't know better even without the constraint from the offeror. On the other hand, it would be nice to be able to say "I'll = take audio without the video" or "Don't give me audio without the video" - so = the=20 problem doesn't go away. IIRC, we made these requirements "SHOULD" = rather than "MUST" because we weren't sure if anyone needed or used them at = present. I'll remind folks that the next meeting of the capability negotiation = group is Tues, January 23 at 1000 Eastern Standard Time. We expect to discuss some of the configuration proposals that have been put forward, and we = can also discuss the constraints between streams. The bridge info is: US toll free: 866-902-7870 (outside the 408 area code.) everywhere else: +1 408 902 7870 meeting ID: 737227634 All interested parties are invited to attend. -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Dan Wing wrote: > (removed internet-drafts from CC list.) >=20 > Can draft-ietf-mmusic-sdp-capability-negotiation-00 provide the same > functionality? >=20 > -d >=20 >=20 >>-----Original Message----- >>From: Schmidt, Christian [mailto:christian-schmidt@siemens.com]=20 >>Sent: Friday, January 19, 2007 4:04 AM >>To: internet-drafts@ietf.org >>Cc: MMusic; Joerg Ott >>Subject: [MMUSIC] New ID, related to media stream dependencies >> >>Dear editor,=20 >> >>we would like to submit a new Internet Draft related to work in the=20 >>MMUSIC Working Group (although it is not an official product=20 >>of the WG).=20 >> >><>=20 >> >>Abstract:=20 >>The Session Description Protocol (SDP) was intended for describing=20 >>multimedia sessions for the purposes of session announcement, session=20 >>invitation, and other forms of multimedia session initiation.=20 >>Together with Offer/Answer model it defines a mechanism, how two=20 >>entities can reach a common view of a multimedia session between=20 >>them.=20 >> >>In certain cases, there are dependencies between media streams, for=20 >>example a text stream for subtitling make sense only together with a=20 >>video stream. To avoid senseless connections, the SDP mechanism can=20 >>be extended with a new Session Description Protocol (SDP) media-level=20 >>attribute: "dependency". The "dependency" attribute allows the=20 >>offerer to define dependencies of media streams. The updated offer/=20 >>answer mechanism used with new "dependency" attribute can be used=20 >>furthermore, that in a multi-party SIP session all participants share=20 >>at least one common media type.=20 >> >>Mit freundlichen Gr=FC=DFen >>Christian Schmidt=20 >> >>Siemens Networks GmbH & Co. KG=20 >>St.-Martin-Str. 76=20 >>81541 M=FCnchen, Germany=20 >>Tel.: +49 89 636-75192=20 >>Fax: +49 89 636-75577=20 >>christian-schmidt@siemens.com =20 >> =20 >>Siemens Networks GmbH & Co. KG=20 >>Gesch=E4ftsf=FChrer: Joachim Malterer, Roland Meinzer, Christian=20 >>Unterberger=20 >>Sitz der Gesellschaft: M=FCnchen=20 >>Registergericht: M=FCnchen, HRA 88537=20 >>WEEE-Reg.-Nr. DE 52984304=20 >>Pers=F6nlich haftende Gesellschafterin: Siemens Networks=20 >>Management GmbH=20 >>Sitz der Gesellschaft: M=FCnchen=20 >>Registergericht: M=FCnchen, HRB 163416=20 >> =20 >> >> >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 22 08:50:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zYV-0008RT-3W; Mon, 22 Jan 2007 08:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zYU-0008R0-0B for mmusic@ietf.org; Mon, 22 Jan 2007 08:49:50 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8zYQ-0005kW-IY for mmusic@ietf.org; Mon, 22 Jan 2007 08:49:49 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JC900K9GVQA0P@siemenscomms.co.uk> for mmusic@ietf.org; Mon, 22 Jan 2007 13:49:22 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Jan 2007 13:49:20 +0000 Content-return: allowed Date: Mon, 22 Jan 2007 13:49:19 +0000 From: "Elwell, John" To: mmusic@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670AD291FC@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [MMUSIC] Capability negotiation and best effort SRTP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1882039651==" Errors-To: mmusic-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1882039651== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_kZKypyVX4gWTLOaLO6p3Gw)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_kZKypyVX4gWTLOaLO6p3Gw) Content-type: text/plain Content-transfer-encoding: 7BIT Am I alone in this, or does anyone else share my concern that the design team seems to be producing a rather complicated solution to capability negotiation? Whilst this might satisfy a whole bunch of requirements, the one important requirement that I and some others really needed a quick and simple solution for - best effort SRTP - seems to be getting drowned. My concerns are: - the complexity of the solution means that it will not be a trivial RFC, and therefore will require several iterations of review, perhaps spread over the period of several IETF meetings; - the complexity will make it more difficult to implement and test; - the complexity may deter vendors from implementing it, with a strong risk that it will not become the industry standard. I would urge the design team to consider a quick and simple solution to best effort SRTP that can be extended later to cover additional requirements. I don't have a specific proposal, but that is partly because I haven't managed to get my brain around the complexity of what is being proposed at present. Defence shields in place! John --Boundary_(ID_kZKypyVX4gWTLOaLO6p3Gw) Content-type: text/html Content-transfer-encoding: 7BIT Capability negotiation and best effort SRTP

Am I alone in this, or does anyone else share my concern that the design team seems to be producing a rather complicated solution to capability negotiation? Whilst this might satisfy a whole bunch of requirements, the one important requirement that I and some others really needed a quick and simple solution for - best effort SRTP - seems to be getting drowned. My concerns are:

- the complexity of the solution means that it will not be a trivial RFC, and therefore will require several iterations of review, perhaps spread over the period of several IETF meetings;

- the complexity will make it more difficult to implement and test;
- the complexity may deter vendors from implementing it, with a strong risk that it will not become the industry standard.

I would urge the design team to consider a quick and simple solution to best effort SRTP that can be extended later to cover additional requirements. I don't have a specific proposal, but that is partly because I haven't managed to get my brain around the complexity of what is being proposed at present.

Defence shields in place!

John

--Boundary_(ID_kZKypyVX4gWTLOaLO6p3Gw)-- --===============1882039651== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1882039651==-- From mmusic-bounces@ietf.org Mon Jan 22 10:57:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91Xm-0004Ou-UG; Mon, 22 Jan 2007 10:57:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H91Xk-0004Oj-OS for mmusic@ietf.org; Mon, 22 Jan 2007 10:57:12 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H91XW-0007Uk-9a for mmusic@ietf.org; Mon, 22 Jan 2007 10:57:12 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zqx.siemens.at with ESMTP id l0MFrxgA001841 for ; Mon, 22 Jan 2007 16:53:59 +0100 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l0MFupvZ005995 for ; Mon, 22 Jan 2007 16:56:52 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jan 2007 16:56:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] Capability negotiation and best effort SRTP Date: Mon, 22 Jan 2007 16:56:49 +0100 Message-ID: In-Reply-To: <50B1CBA96870A34799A506B2313F26670AD291FC@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Capability negotiation and best effort SRTP Thread-Index: Acc+LIU0BvRXXeupQ6OYjqBVV9+JRQAEKLPQ From: "Stach, Thomas" To: "Elwell, John" , X-OriginalArrivalTime: 22 Jan 2007 15:56:51.0646 (UTC) FILETIME=[EE5EB5E0:01C73E3D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070122165359-3D414BB0-036C5D53/0-0/0-15 X-purgate-size: 31511/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 419681661a5a61835a9a79996a04e3e9 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0737926906==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0737926906== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73E3D.EDE7ED99" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73E3D.EDE7ED99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, =20 thanks for your initiative.=20 Here are some thoughts on doing only best-effort negotiation based on the current work on SDP capability negotiation=20 =20 Recap of the current discussion =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Fleming's draft draft-ietf-mmusic-sdp-capability-negotiation-00.txt defines a lot of new attributes. =20 The proposed new attributes are: A new attribute ("a=3Dcver") that lists the version of the SDP --> based on telco result this is no longer needed A new attribute ("a=3Dcsup") that lists the supported capabilities of = the negotiation framework A new attribute ("a=3Dcreq") that lists the capabilities that are = required A new attribute ("a=3Dcmed") that related to the media types/format as capabilities=20 A new attribute ("a=3Dcapar") that defines attribute parameter values (e.g. a=3Dcrypto: ) as capabilities A new attribute ("a=3Dctrpr") that defines how to list transport = protocols (e.g. RTP/AVP) as capabilities A new attribute ("a=3Dpcfg") that lists the potential configurations supported A new attribute ("a=3Dacfg") to be used in an answer SDP for actually = used potential configurations =20 The a=3Dcapar: attribute can carry everything that was specified as SDP attribute, ranging e.g. from a=3Dcrypto:, a=3Dkeymgmt: to the media = related a=3Dfmtp: attribute.=20 =20 The combinations between mentiond attribute are indeed quite complex and intransparent, at least at first sight.=20 =20 Bob Gilman's extended proposal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Bob proposes some modification on the definition of the original = a=3Dcmed attribute (e.g. mime subtypes for media) and even more new attributes related to media capabilities:=20 "a=3Dcenc:" This line defines encoding attributes for the media mime subtype "a=3Dcfmt:" This line defines format parameters for the media mime subtype "a=3Dcptmap:" This line defines the mapping payload type(s) and media = mime subtype =20 These new attributes would carry media related data that were supposed to be carried in the a=3Dcapar: attribute in Fleming's original = proposal. Basically, I like this proposal since it distinguishes between media-related and other attributes. However, it makes things even less transparent and more complex. =20 Thinking how this can be simplified in order to match the currently urgent need for standardised best effort SRTP I have the following thoughts. =20 Application to best-effort SRTP from Fleming's draft =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =20 Below are the essentials of the example offer from Fleming's draft for best-effort SRTP=20 =20 m=3Daudio 3456 RTP/AVP 0 18 =20 a=3Dctrpr:1 RTP/SAVP RTP/AVP=20 a=3Dcapar:1 a=3Dcrypto: ... a=3Dpcfg: p=3D1 a=3D1=20 a=3Dpcfg: p=3D2 =20 =20 The answer could look like=20 =20 m=3Daudio 4567 RTP/SAVP 0 18 =20 a=3Dcrypto: ... a=3Dacfg: p=3D1 a=3D1=20 =20 Possible simplification =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Based on this example one would just need to support the attributes a=3Dctrpr: for RTP/AVP vs. RTP/SAVP a=3Dcapar: for carrying a=3Dcrypto: (for sDescriptios) or a=3Dkeymgmt: = (for MIKEY) a=3Dpcfg: for offering the supported alternatives a=3Dacfg: for indicating the chosen alternative in the SDP answer =20 All the other attributes from above are more or less related to media capabilities. =20 If we sort the capabilities according to their purpose we get: =20 1) attributes for basic negotiation and extensibility --> a=3Dcsup:, a=3Dcreq:, a=3Dpcfg: and a=3Dacfg: 2) attribute for negotiation of the transport protocol --> a=3Dctrpr: RTP/AVP RTP/SAVP RTP/AVPF RTP/SAVPF ... 3) attribute for negotiation of attributes a=3Dcapar:=20 Following Bob's proposal, only usage for SDP security descriptions or MIKEY would currently remain here =20 (Unless the AVPF profiles require some attributes, needs to be checked). 4) attributes for negotiation of media capabilities a=3Dcmed:, = a=3Dcenc:, a=3Dcfmt:, a=3Dcptmap:=20 =20 Now negotiation of transport profiles for SRTP vs RTP requires 1), 2) and 3). Negotiation of media needs 1) and 4) if Bob's proposal gets accepted. =20 The support both alternatives could be indicated in the a=3Dcsup: attribute, e.g "a=3Dcsup: trpr" for the first case, "a=3Dcsup: med" for = the second case and "a=3Dcsup: med,trpr" for both together. Negotiating these capabilities could be done based on the content of the a=3Dcsup: attribute in SDP offer and SDP answer.=20 =20 Is this a considerable simplification? Should the design team just focus on the best-effort part, since this is currently a pressing issue? I assume that a stable draft on best-effort-only could be achieved quite quickly, whereas the media related work will surely take much more time and could probably be done in a separate document defining an extension to the framework. =20 =20 Regards Thomas ________________________________ From: Elwell, John=20 Sent: Monday, January 22, 2007 2:49 PM To: mmusic@ietf.org Subject: [MMUSIC] Capability negotiation and best effort SRTP =09 =09 Am I alone in this, or does anyone else share my concern that the design team seems to be producing a rather complicated solution to capability negotiation? Whilst this might satisfy a whole bunch of requirements, the one important requirement that I and some others really needed a quick and simple solution for - best effort SRTP - seems to be getting drowned. My concerns are: - the complexity of the solution means that it will not be a trivial RFC, and therefore will require several iterations of review, perhaps spread over the period of several IETF meetings; - the complexity will make it more difficult to implement and test;=20 - the complexity may deter vendors from implementing it, with a strong risk that it will not become the industry standard. I would urge the design team to consider a quick and simple solution to best effort SRTP that can be extended later to cover additional requirements. I don't have a specific proposal, but that is partly because I haven't managed to get my brain around the complexity of what is being proposed at present. Defence shields in place!=20 John=20 ------_=_NextPart_001_01C73E3D.EDE7ED99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Capability negotiation and best effort SRTP

Hi John,

 

thanks for your initiative. =

Here are some thoughts = on doing=20 only best-effort negotiation based on the current work on SDP capability = negotiation 

 

Recap of the = current=20 discussion

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Fleming's draft=20 draft-ietf-mmusic-sdp-capability-negotiation-00.txt defines a lot of new = attributes.

 

The proposed new = attributes=20 are:

A new attribute = ("a=3Dcver")=20 that lists the version of the SDP --> based on telco result this is = no longer=20 needed

A new attribute = ("a=3Dcsup")=20 that lists the supported capabilities of the negotiation=20 framework

A new attribute = ("a=3Dcreq")=20 that lists the capabilities that are required

A new attribute = ("a=3Dcmed")=20 that related to the media types/format as capabilities =

A new attribute = ("a=3Dcapar")=20 that defines attribute parameter values (e.g. a=3Dcrypto: ) as=20 capabilities

A new attribute = ("a=3Dctrpr")=20 that defines how to list transport protocols (e.g. RTP/AVP) as=20 capabilities

A new attribute = ("a=3Dpcfg")=20 that lists the potential configurations supported

A new attribute = ("a=3Dacfg")=20 to be used in an answer SDP for actually used potential=20 configurations

 

The a=3Dcapar: = attribute can=20 carry everything that was specified as SDP attribute, ranging e.g. from=20 a=3Dcrypto:, a=3Dkeymgmt: to the media related a=3Dfmtp: attribute.=20

 

The combinations = between=20 mentiond attribute are indeed quite complex and intransparent, at least = at first=20 sight.

 

Bob Gilman’s = extended=20 proposal

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Bob proposes some=20 modification on the definition of the original a=3Dcmed attribute (e.g. = mime=20 subtypes for media) and even more new attributes related to media = capabilities:=20

"a=3Dcenc:"   This line defines = encoding=20 attributes for the media mime subtype

"a=3Dcfmt:"   This line defines format = parameters for the media mime subtype

"a=3Dcptmap:" This = line=20 defines the mapping payload type(s) and media mime = subtype

 

These new = attributes would=20 carry media related data that were supposed to be carried in the = a=3Dcapar:=20 attribute in Fleming's original proposal. Basically, I like this = proposal since=20 it distinguishes between media-related and other attributes. However, it = makes=20 things even less transparent and more complex.

 

Thinking how this = can be=20 simplified in order to match the currently urgent need for standardised = best=20 effort SRTP I have the following thoughts.

 

Application to = best-effort=20 SRTP from Fleming's = draft

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

Below are the = essentials of=20 the example offer from Fleming's draft for best-effort SRTP=20

 

m=3Daudio 3456 = RTP/AVP 0=20 18 

a=3Dctrpr:1 = RTP/SAVP RTP/AVP=20

a=3Dcapar:1 = a=3Dcrypto:=20 ...

a=3Dpcfg: p=3D1 = a=3D1=20

a=3Dpcfg: = p=3D2 

 

The = answer could look like

 

m=3Daudio 4567 = RTP/SAVP 0=20 18 

a=3Dcrypto:=20 ...

a=3Dacfg: p=3D1 = a=3D1=20

 

Possible=20 simplification

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 

Based on this=20 example one would just need = to=20 support the attributes

a=3Dctrpr: for = RTP/AVP vs.=20 RTP/SAVP

a=3Dcapar: for = carrying=20 a=3Dcrypto: (for sDescriptios) or a=3Dkeymgmt: (for = MIKEY)

a=3Dpcfg: for = offering the=20 supported alternatives

a=3Dacfg: for = indicating the=20 chosen alternative in the SDP answer

 

All the other = attributes=20 from above are more or less related to media = capabilities.

 

If we sort the = capabilities=20 according to their purpose we get:

 

1) attributes for = basic=20 negotiation and extensibility --> a=3Dcsup:, a=3Dcreq:, a=3Dpcfg: and = a=3Dacfg:

2) attribute for = negotiation=20 of the transport protocol --> a=3Dctrpr: RTP/AVP RTP/SAVP RTP/AVPF = RTP/SAVPF=20 ...

3) attribute for = negotiation=20 of attributes a=3Dcapar:

   Following Bob's proposal, only usage for SDP = security=20 descriptions or MIKEY would currently remain here=20  

   (Unless the AVPF = profiles require=20 some attributes, needs to be checked).

4) attributes for=20 negotiation of media capabilities a=3Dcmed:, a=3Dcenc:, a=3Dcfmt:, = a=3Dcptmap:=20

 

Now negotiation of = transport=20 profiles for SRTP vs RTP requires 1), 2) and 3).

Negotiation of = media needs=20 1) and 4) if Bob's proposal gets accepted.

 

The support both=20 alternatives could be indicated in the a=3Dcsup: attribute, e.g = "a=3Dcsup: trpr" for=20 the first case, "a=3Dcsup: med" for the second case and "a=3Dcsup: = med,trpr" for=20 both together.

Negotiating these=20 capabilities could be done based on the content of the a=3Dcsup: = attribute in SDP=20 offer and SDP answer.

 

Is this a = considerable=20 simplification?

Should the design = team just=20 focus on the best-effort part, since this is currently a pressing=20 issue?

I assume that a = stable draft=20 on best-effort-only could be achieved quite quickly, whereas the media = related=20 work will surely take much more time = and=20 could=20 probably be done in a separate document defining an extension to the = framework.

 

 

Regards

Thomas


From: Elwell, John =
Sent: Monday,=20 January 22, 2007 2:49 PM
To: = mmusic@ietf.org
Subject:=20 [MMUSIC] Capability negotiation and best effort = SRTP

Am I alone in this, or does anyone else = share my=20 concern that the design team seems to be producing a rather = complicated=20 solution to capability negotiation? Whilst this might satisfy a whole = bunch of=20 requirements, the one important requirement that I and some others = really=20 needed a quick and simple solution for - best effort SRTP - seems to = be=20 getting drowned. My concerns are:

- the complexity of the solution means = that it will=20 not be a trivial RFC, and therefore will require several iterations of = review,=20 perhaps spread over the period of several IETF meetings;

- the complexity will make it more = difficult to=20 implement and test;
- the = complexity may=20 deter vendors from implementing it, with a strong risk that it will = not become=20 the industry standard.

I would urge the design team to = consider a quick=20 and simple solution to best effort SRTP that can be extended later to = cover=20 additional requirements. I don't have a specific proposal, but that is = partly=20 because I haven't managed to get my brain around the complexity of = what is=20 being proposed at present.

Defence shields in place!

John =

------_=_NextPart_001_01C73E3D.EDE7ED99-- --===============0737926906== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0737926906==-- From mmusic-bounces@ietf.org Mon Jan 22 12:00:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92X0-0007ZS-Go; Mon, 22 Jan 2007 12:00:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H92Wy-0007ZI-Kf for mmusic@ietf.org; Mon, 22 Jan 2007 12:00:28 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H92Ww-0003Kv-2D for mmusic@ietf.org; Mon, 22 Jan 2007 12:00:28 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0MH0O4C028944 for ; Mon, 22 Jan 2007 12:00:25 -0500 Received: from [135.9.42.38] ([135.9.42.38]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Jan 2007 10:00:22 -0700 Message-ID: <45B4EDA4.4030508@avaya.com> Date: Mon, 22 Jan 2007 10:00:20 -0700 From: "Robert R. Gilman" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Schmidt, Christian" Subject: Re: AW: [MMUSIC] New ID, related to media stream dependencies References: <72963DDDF17D7949ABD18DC5DA58E77001AC919A@MCHP7R5A.ww002.siemens.net> In-Reply-To: <72963DDDF17D7949ABD18DC5DA58E77001AC919A@MCHP7R5A.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 22 Jan 2007 17:00:22.0688 (UTC) FILETIME=[CDED9200:01C73E46] X-Scanner: InterScan AntiVirus for Sendmail Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by co300216-ier2.net.avaya.com id l0MH0O4C028944 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: MMusic , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Christian- I interpret REQ-150 to include your REQ-155. For example, if 'a' and 'b'= are media streams, then the valid combinations might be a+b and a, which woul= d exclude "b without a". Also, remember that either party may wish to expr= ess dependencies, especially for latent capabilities. -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Schmidt, Christian wrote: >=20 > Hi Robert and Dan, >=20 > the example with the subtitle may be not the best one, but I can imagin= e > cases, where the offerer has dependency information, not available to t= he > receiver. For example in case of media streaming, the key for decryptio= n > could be send via instant messaging. In this case, the offerer can prov= ide > this information via dependency attribute. The receiption of video medi= a > without the proper decryption information would make no sense. >=20 > Furthermore, a possible application for the dependency attribute could = be > used for the selection of mendatory media streams, all participants of = a > conference are able to share. >=20 > The dependency information can be seen as capability negotiation, there= fore > it would make sense to include it to the current activites for capabili= ty > negotation. What do you think? The related requirement could look like: >=20 > REQ-155: It SHOULD be possible to specify dependencies between media li= nes, > based on the decision of the offerer. The receiver should accept media = lines > only if he is willing and able to accept all mandatory dependent media = lines > as well. This could avoid redundant call attempts and for example incre= ase > interoperability in conferences. >=20 > On Tuesday, I will try to attend the planned confcall. >=20 > Best Regards Christian Schmidt >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- Von: Robert R. Gilman > [mailto:rrg@avaya.com] Gesendet: Samstag, 20. Januar 2007 00:16 An: Dan= Wing=20 > Cc: Schmidt, Christian; 'MMusic' Betreff: Re: [MMUSIC] New ID, related = to > media stream dependencies >=20 > Dan- As it stands now, the capneg definitions don't support that. > Requirements 150 and 160 of the requirements draft say: >=20 > REQ-150: It SHOULD be possible to specify valid combinations of media l= ines. >=20 > For example, an entity may be able to support audio and video or audio = and > IM, but not video and IM (or all three). >=20 > REQ-160: It SHOULD be possible to specify valid combinations of media f= ormats > between media streams. >=20 > For example, there may be constraints on which combinations of audio an= d > video codecs can be supported. >=20 > I've been thinking about some session-level constraints that might be u= sed=20 > for REQ-160. For example, one might define a ccons: attribute that lis= ted > acceptable combinations of codecs - I was considering the processing- p= ower > constraints between specific codecs (e.g., codec a1 and codec v1 or cod= ec a2 > and codec v2). Christian's goal is described by REQ-150 - making sure = the > responder doesn't do something silly like open a subtitles stream with = no > video stream. In that particular case, it's not clear to me that the > responder wouldn't know better even without the constraint from the off= eror. > On the other hand, it would be nice to be able to say "I'll take audio > without the video" or "Don't give me audio without the video" - so the=20 > problem doesn't go away. IIRC, we made these requirements "SHOULD" rat= her=20 > than "MUST" because we weren't sure if anyone needed or used them at pr= esent. >=20 >=20 > I'll remind folks that the next meeting of the capability negotiation g= roup=20 > is Tues, January 23 at 1000 Eastern Standard Time. We expect to discus= s some > of the configuration proposals that have been put forward, and we can a= lso > discuss the constraints between streams. The bridge info is: US toll fr= ee: > 866-902-7870 (outside the 408 area code.) everywhere else: +1 408 902 7= 870=20 > meeting ID: 737227634 All interested parties are invited to attend. -Bo= b=20 > ---------------------------------------------------- Bob Gilman > rrg@avaya.com +1 303 538 3868 >=20 > Dan Wing wrote: >=20 >> (removed internet-drafts from CC list.) >>=20 >> Can draft-ietf-mmusic-sdp-capability-negotiation-00 provide the same=20 >> functionality? >>=20 >> -d >>=20 >>=20 >>=20 >>> -----Original Message----- From: Schmidt, Christian >>> [mailto:christian-schmidt@siemens.com] Sent: Friday, January 19, 2007 >>> 4:04 AM To: internet-drafts@ietf.org Cc: MMusic; Joerg Ott Subject: >>> [MMUSIC] New ID, related to media stream dependencies >>>=20 >>> Dear editor, >>>=20 >>> we would like to submit a new Internet Draft related to work in the=20 >>> MMUSIC Working Group (although it is not an official product of the = WG). >>>=20 >>>=20 >>> <> >>>=20 >>> Abstract: The Session Description Protocol (SDP) was intended for >>> describing multimedia sessions for the purposes of session announceme= nt, >>> session invitation, and other forms of multimedia session initiation.= =20 >>> Together with Offer/Answer model it defines a mechanism, how two enti= ties >>> can reach a common view of a multimedia session between them. >>>=20 >>> In certain cases, there are dependencies between media streams, for=20 >>> example a text stream for subtitling make sense only together with a=20 >>> video stream. To avoid senseless connections, the SDP mechanism can = be >>> extended with a new Session Description Protocol (SDP) media-level=20 >>> attribute: "dependency". The "dependency" attribute allows the offer= er >>> to define dependencies of media streams. The updated offer/ answer >>> mechanism used with new "dependency" attribute can be used furthermor= e, >>> that in a multi-party SIP session all participants share at least one >>> common media type. >>>=20 >>> Mit freundlichen Gr=FC=DFen Christian Schmidt >>>=20 >>> Siemens Networks GmbH & Co. KG St.-Martin-Str. 76 81541 M=FCnchen, Ge= rmany >>> Tel.: +49 89 636-75192 Fax: +49 89 636-75577=20 >>> christian-schmidt@siemens.com >>>=20 >>> Siemens Networks GmbH & Co. KG Gesch=E4ftsf=FChrer: Joachim Malterer,= Roland >>> Meinzer, Christian Unterberger Sitz der Gesellschaft: M=FCnchen=20 >>> Registergericht: M=FCnchen, HRA 88537 WEEE-Reg.-Nr. DE 52984304 Pers=F6= nlich >>> haftende Gesellschafterin: Siemens Networks Management GmbH Sitz der >>> Gesellschaft: M=FCnchen Registergericht: M=FCnchen, HRB 163416 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ mmusic mailing list=20 >> mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 22 18:39:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98kd-0000Ev-Se; Mon, 22 Jan 2007 18:38:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H98kc-0000Ed-6j for mmusic@ietf.org; Mon, 22 Jan 2007 18:38:58 -0500 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H98ka-000518-Vw for mmusic@ietf.org; Mon, 22 Jan 2007 18:38:58 -0500 Received: by wr-out-0506.google.com with SMTP id i22so810383wra for ; Mon, 22 Jan 2007 15:38:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=PfvVIo9QbAfUKxk5jKJGFKRsH9+NIQejYd0u5N9xjg2agugVzfNpSKh1z7ns7jgzjleMYlNmlvoLAuUKWac+qzsPXdI6TUGCA98N0BBUyZ+GVz9dNTEfD1aTh0I1M7A+qAcOApNVsELfGoJbsP3T5Ro4jwRk0BLPQNSeIaTkRqE= Received: by 10.78.178.5 with SMTP id a5mr12017huf.1169509135549; Mon, 22 Jan 2007 15:38:55 -0800 (PST) Received: by 10.78.150.1 with HTTP; Mon, 22 Jan 2007 15:38:55 -0800 (PST) Message-ID: Date: Mon, 22 Jan 2007 15:38:55 -0800 From: "nicolas catania" To: mmusic@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [MMUSIC] RTSP support for streaming raw container X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1998946934==" Errors-To: mmusic-bounces@ietf.org --===============1998946934== Content-Type: multipart/alternative; boundary="----=_Part_26216_1769911.1169509135522" ------=_Part_26216_1769911.1169509135522 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am new to RTSP/RTP but this question hopefully makes sense: Is it possible to stream a video file container (say avi) straight on RTP? If yes, what type/profile should be used in SDP and RTP? Basically, I want to be able to stream a video from a very lightweight server. I'd rather not have to write an avi parser to extract the video and audio streams. Hopefully, I should be able to send the avi file as is and the player should be able to figure out how to play it. Thanks. Niko ------=_Part_26216_1769911.1169509135522 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am new to RTSP/RTP but this question hopefully makes sense:

Is it possible to stream a video file container (say avi) straight on RTP?
If yes, what type/profile should be used in SDP and RTP?

Basically, I want to be able to stream a video from a very lightweight server.
I'd rather not have to write an avi parser to extract the video and audio streams.
Hopefully, I should be able to send the avi file as is and the player should be
able to figure out how to play it.

Thanks.

Niko
------=_Part_26216_1769911.1169509135522-- --===============1998946934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1998946934==-- From mmusic-bounces@ietf.org Tue Jan 23 02:53:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9GSn-0003gT-41; Tue, 23 Jan 2007 02:53:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9GSl-0003ep-KK for mmusic@ietf.org; Tue, 23 Jan 2007 02:53:03 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9GSj-0002A0-SZ for mmusic@ietf.org; Tue, 23 Jan 2007 02:53:03 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l0N7quIb032655; Tue, 23 Jan 2007 08:52:56 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l0N7qtY0012722; Tue, 23 Jan 2007 08:52:55 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 08:52:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [MMUSIC] New ID, related to media stream dependencies Date: Tue, 23 Jan 2007 08:52:54 +0100 Message-ID: <72963DDDF17D7949ABD18DC5DA58E77001AC9352@MCHP7R5A.ww002.siemens.net> In-Reply-To: <45B4EDA4.4030508@avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [MMUSIC] New ID, related to media stream dependencies Thread-Index: Acc+RudLxPZHHkaBSa6G7Ah8+YEjgAAeROmQ From: "Schmidt, Christian" To: "Robert R. Gilman" X-OriginalArrivalTime: 23 Jan 2007 07:52:55.0809 (UTC) FILETIME=[7E135710:01C73EC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: MMusic , Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Bob >For example, if 'a' and 'b' are >media streams, then the valid combinations might be a+b and a, which = would >exclude "b without a".=20 Thats correct, it is the case, when b is mandatory dependent from a. >I interpret REQ-150 to include your REQ-155. Good point, the requirement should be extended to reflect this new = feature: "REQ-150: It SHOULD be possible to specify valid combinations of media = lines. Media lines in those combination can be optional or mandatory." >Also, remember that either party may wish to express=20 >dependencies, especially for latent capabilities. With the dependency attribute, this should be possible. Regards Christian =20 -----Urspr=FCngliche Nachricht----- Von: Robert R. Gilman [mailto:rrg@avaya.com]=20 Gesendet: Montag, 22. Januar 2007 18:00 An: Schmidt, Christian Cc: Dan Wing; MMusic Betreff: Re: AW: [MMUSIC] New ID, related to media stream dependencies Christian- I interpret REQ-150 to include your REQ-155. For example, if 'a' and = 'b' are media streams, then the valid combinations might be a+b and a, which = would exclude "b without a". Also, remember that either party may wish to = express dependencies, especially for latent capabilities. -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868 Schmidt, Christian wrote: >=20 > Hi Robert and Dan, >=20 > the example with the subtitle may be not the best one, but I can = imagine > cases, where the offerer has dependency information, not available to = the > receiver. For example in case of media streaming, the key for = decryption > could be send via instant messaging. In this case, the offerer can = provide > this information via dependency attribute. The receiption of video = media > without the proper decryption information would make no sense. >=20 > Furthermore, a possible application for the dependency attribute could = be > used for the selection of mendatory media streams, all participants of = a > conference are able to share. >=20 > The dependency information can be seen as capability negotiation, = therefore > it would make sense to include it to the current activites for = capability > negotation. What do you think? The related requirement could look = like: >=20 > REQ-155: It SHOULD be possible to specify dependencies between media = lines, > based on the decision of the offerer. The receiver should accept media = lines > only if he is willing and able to accept all mandatory dependent media = lines > as well. This could avoid redundant call attempts and for example = increase > interoperability in conferences. >=20 > On Tuesday, I will try to attend the planned confcall. >=20 > Best Regards Christian Schmidt >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- Von: Robert R. Gilman > [mailto:rrg@avaya.com] Gesendet: Samstag, 20. Januar 2007 00:16 An: = Dan Wing=20 > Cc: Schmidt, Christian; 'MMusic' Betreff: Re: [MMUSIC] New ID, related = to > media stream dependencies >=20 > Dan- As it stands now, the capneg definitions don't support that. > Requirements 150 and 160 of the requirements draft say: >=20 > REQ-150: It SHOULD be possible to specify valid combinations of media = lines. >=20 > For example, an entity may be able to support audio and video or audio = and > IM, but not video and IM (or all three). >=20 > REQ-160: It SHOULD be possible to specify valid combinations of media = formats > between media streams. >=20 > For example, there may be constraints on which combinations of audio = and > video codecs can be supported. >=20 > I've been thinking about some session-level constraints that might be = used=20 > for REQ-160. For example, one might define a ccons: attribute that = listed > acceptable combinations of codecs - I was considering the processing- = power > constraints between specific codecs (e.g., codec a1 and codec v1 or = codec a2 > and codec v2). Christian's goal is described by REQ-150 - making sure = the > responder doesn't do something silly like open a subtitles stream with = no > video stream. In that particular case, it's not clear to me that the > responder wouldn't know better even without the constraint from the = offeror. > On the other hand, it would be nice to be able to say "I'll take audio > without the video" or "Don't give me audio without the video" - so the = > problem doesn't go away. IIRC, we made these requirements "SHOULD" = rather=20 > than "MUST" because we weren't sure if anyone needed or used them at = present. >=20 >=20 > I'll remind folks that the next meeting of the capability negotiation = group=20 > is Tues, January 23 at 1000 Eastern Standard Time. We expect to = discuss some > of the configuration proposals that have been put forward, and we can = also > discuss the constraints between streams. The bridge info is: US toll = free: > 866-902-7870 (outside the 408 area code.) everywhere else: +1 408 902 = 7870=20 > meeting ID: 737227634 All interested parties are invited to attend. = -Bob=20 > ---------------------------------------------------- Bob Gilman > rrg@avaya.com +1 303 538 3868 >=20 > Dan Wing wrote: >=20 >> (removed internet-drafts from CC list.) >>=20 >> Can draft-ietf-mmusic-sdp-capability-negotiation-00 provide the same=20 >> functionality? >>=20 >> -d >>=20 >>=20 >>=20 >>> -----Original Message----- From: Schmidt, Christian >>> [mailto:christian-schmidt@siemens.com] Sent: Friday, January 19, = 2007 >>> 4:04 AM To: internet-drafts@ietf.org Cc: MMusic; Joerg Ott Subject: >>> [MMUSIC] New ID, related to media stream dependencies >>>=20 >>> Dear editor, >>>=20 >>> we would like to submit a new Internet Draft related to work in the = >>> MMUSIC Working Group (although it is not an official product of the = WG). >>>=20 >>>=20 >>> <> >>>=20 >>> Abstract: The Session Description Protocol (SDP) was intended for >>> describing multimedia sessions for the purposes of session = announcement, >>> session invitation, and other forms of multimedia session = initiation.=20 >>> Together with Offer/Answer model it defines a mechanism, how two = entities >>> can reach a common view of a multimedia session between them. >>>=20 >>> In certain cases, there are dependencies between media streams, for=20 >>> example a text stream for subtitling make sense only together with a = >>> video stream. To avoid senseless connections, the SDP mechanism can = be >>> extended with a new Session Description Protocol (SDP) media-level=20 >>> attribute: "dependency". The "dependency" attribute allows the = offerer >>> to define dependencies of media streams. The updated offer/ answer >>> mechanism used with new "dependency" attribute can be used = furthermore, >>> that in a multi-party SIP session all participants share at least = one >>> common media type. >>>=20 >>> Mit freundlichen Gr=FC=DFen Christian Schmidt >>>=20 >>> Siemens Networks GmbH & Co. KG St.-Martin-Str. 76 81541 M=FCnchen, = Germany >>> Tel.: +49 89 636-75192 Fax: +49 89 636-75577=20 >>> christian-schmidt@siemens.com >>>=20 >>> Siemens Networks GmbH & Co. KG Gesch=E4ftsf=FChrer: Joachim = Malterer, Roland >>> Meinzer, Christian Unterberger Sitz der Gesellschaft: M=FCnchen=20 >>> Registergericht: M=FCnchen, HRA 88537 WEEE-Reg.-Nr. DE 52984304 = Pers=F6nlich >>> haftende Gesellschafterin: Siemens Networks Management GmbH Sitz der >>> Gesellschaft: M=FCnchen Registergericht: M=FCnchen, HRB 163416 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ mmusic mailing list=20 >> mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 03:40:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HCq-0008NU-NZ; Tue, 23 Jan 2007 03:40:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HCp-0008NO-3x for mmusic@ietf.org; Tue, 23 Jan 2007 03:40:39 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9HCn-0000oX-Qe for mmusic@ietf.org; Tue, 23 Jan 2007 03:40:39 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61163 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1H9HCl-00053v-2Q; Tue, 23 Jan 2007 08:40:35 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1DE8EC8A-6305-4F76-A6AB-F967B252A04A@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP Date: Tue, 23 Jan 2007 08:40:32 +0000 To: "Stach, Thomas" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 22 Jan 2007, at 15:56, Stach, Thomas wrote: ... > Below are the essentials of the example offer from Fleming's draft > for best-effort SRTP > > m=audio 3456 RTP/AVP 0 18 > a=ctrpr:1 RTP/SAVP RTP/AVP > a=capar:1 a=crypto: ... > a=pcfg: p=1 a=1 > a=pcfg: p=2 > > The answer could look like > > m=audio 4567 RTP/SAVP 0 18 > a=crypto: ... > a=acfg: p=1 a=1 Why do we need to specify the actual ("m=" line configuration) as a potential configuration? I'd like to signal: m=audio 3456 RTP/AVP 0 18 a=ctrpr:1 RTP/SAVP a=capar:1 a=crypto: ... a=pcfg: p=1 a=1 as the offer, with an implied potential configuration 0 for RTP/AVP. That comes close to the simplicity of the best-effort-srtp draft for that use case, but with more extensibility. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 03:44:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HGf-0001fQ-E5; Tue, 23 Jan 2007 03:44:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HGd-0001fA-Gp for mmusic@ietf.org; Tue, 23 Jan 2007 03:44:35 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9HGc-0001SE-Q5 for mmusic@ietf.org; Tue, 23 Jan 2007 03:44:35 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61168 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1H9HGb-0005L9-U5; Tue, 23 Jan 2007 08:44:34 +0000 In-Reply-To: <45AD68F1.2080402@avaya.com> References: <45AD68F1.2080402@avaya.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Modified Proposal for Capability Negotiations Date: Tue, 23 Jan 2007 08:44:32 +0000 To: Robert R. Gilman X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I like this... but it's a big change to the SDP semantics. If we were starting from scratch, or weren't under such time pressure, it would definitely be worth serious configuration. For the current design team, where we need something ready for working group last call before the Prague meeting, I'm concerned that we need something closer to the current semantics. Colin On 17 Jan 2007, at 00:08, Robert R. Gilman wrote: > I've been playing with a means to make the cmed attribute line > independent > of payload types, so it can be use at the session level or media > level to > define media encodings. These can be combined with transport > protocols > at the session or media levels, and payload types at the media level. > Here's an approach that doesn't simply replicate the existing m- > line in a > cmed attribute. It builds up the capabilities from mime type/ > subtypes, > encoding parameters, and format parameters. Note that the cenc and > cfmt > lines are tied directly into the subtypes listed in the cmed line > via the > subtype ordinal; they are implicitly incorporated in the pcfg > attribute > by reference to their subtype ordinal(s). One of the advantages of > doing > this binding early is that an endpoint can offer a particular codec > with > different format parameters (e.g., G.729 and G.729B). > > Define/redefine the following new attributes: > > a=cmed: > This line defines the set of codecs supported, and assigns > an ordinal to each codec. The codecs are referenced via their > ordinals in pcfg or acfg lines (via the m= parameter), and in > cenc and cfmt attributes. > If the first subtype ordinal is 's', say, the the first mime > subtype corresponds to "subtyp s", the next to "s+1", and > so on. > example: a=cmed:1 PCMU G729 G729 iLBC events > ; PCMU=1, G729=2, G729=3 iLBC=4, events=5 > > a=ctrpr: > This line defines the transport protocols/profiles supported; > the pcfg line will refer to one of these via "p=" > example: a=ctrpr:1 RTP/AVP RTP/SAVP => RTP/AVP=1 RTP/SAVP=2 > > a=cenc: [/] > This line defines encoding attributes for the specified mime subtype. > It is effectively incorporated as part of the codec with the > specified > ordinal. > example: a=cenc:4 8000 ;sample rate for iLBC > > a=cfmt: > This line defines format parameters for the specified mime subtype. > It is effectively incorporated as part of the codec with the > specified > ordinal. > example: a=cfmt:2 annexb:no ;codec 2 doesn't support > comfort noise > > a=cptmap: : type> pairs> > This line defines the payload type(s) to be used with a particular > configuration and referenced via "ptm=". It may only be used by > offered configurations, not latent configurations. > example: a=cptmap:1 2:99 3:100 ; maps G.729 to PT 99, iLBC > to PT 100 > > The remaining attributes (pcfg, acfg, capar) are defined as in > Flemming's draft: > . > > Then we might have an offer like the following. This announces > support > for 4 audio codecs (G.711mu-law, G.729, G.729B, iLBC) and in-band > telephony > events for DTMF and Flash. > ... (skipping over initial session lines) > 1) a=cmed:1 audio PCMU G729 G729 iLBC events > 2) a=cenc:4 8000 ;iLBC with 8K sample > rate > 3) a=ctrpr:1 RTP/AVP RTP/SAVP ;transport profiles > 4) a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20| > 1:32 > 5) a=cfmt:2 annexb:no ;no comfort noise for > G.729 > 6) a=cfmt:5 0-15,16 ;DTMF plus flash events > 7) a=pcfg:1 m=3,5|4,5 t=1 ;a latent AVP capset > 8) a=pcfg:2 m=3,5|4,5 t=2 a=1 ;a latent SAVP capset > 9) m=audio 22222 AVT/RTP 0 18 100 ; standard audio line > 10) a=rtpmap:100 events > 11) a=fmt:100 0-15 > 12) a=cptmap:1 1:101 2:102 5:103 > 13) a=pcfg:3 m=1,5|2,5 p=2 a=1 ptm=1 ;(SRTP option) > > Notes: > 1) This cmed line defines a set of audio codecs numbered 1-5. > 2) This cenc line defines adds encoding rate information for codec 3. > 3) This ctpr line defines two transport profiles numbered 1-2. > 4) This capar line defines an SDES crypto attribute. > 5) This cfmt line defines format parameters for codec 3 (G.729) > 6) This cfmt line defines the telephony event parameters for > "codec 5", > the telephony events. > 7) This pcfg line defines a latent AVP capset with any one of the > four > audio codecs plus DTMF telephony events. > 8) This pcfg line defines a latent SAVP capset with the same > combinations > of codecs/tlephony events. > 9) This is the conventional media line for audio with G.711mu-law, > G.729B, > and a dynamic payload type. > 10) "Traditional" SDP for backward compatibility. > 11) "Traditional" SDP for backward compatibility. > 9)-11) In case the receiver understands capability negotiation, but > wishes to > choose the AVT/RTP offer rather than encryption, we define > that the m= line defines "pcfg:0", "cptmap:0", transport > type "0", and > the media codecs are assigned the next codec ordinals > following those > defined at the session level (codecs defined at the media > level via cmed > attributes will be numbered following those defined on the > m=line). > Thus, the m= line and the following rtpmap and fmtp lines > are equivalent > to: > a=cmed:6 PCMU G729 event > a=cptmap:0 8:100 > a=pcfg:0 m=6,7,8 p=0 ptm=0 > Any pcfg: line at the media level may refer to the codecs > and transports > defined by the current m= line. > 12) This line provides the payload types for each cmed codec for > this media > stream. The payload types are chosen, in this case, so that > the receiver > can use them to tell which choices the answerer made if media > is received > by the offeror before the answer arrives. > 13) This line specifies an alternative media stream using SRTP. > p=2 invokes the second transport protocol (RTP/SAVP) from the > ctrpr > line. > a=1 identifies the SDES crypto attribute > ptm=1 identifies the payload map. I've used "1" to identify the > entire line, but we could use numbers to identify each > mapping, > as ptm=1,2,3 > Note that there are no references to the cfmt or cenc > attributes - they're > always attached to their respective media subtypes. > > Given an offer in the above form, a endpoint that doesn't > understand the capneg > attributes will respond with the usual m= line and attributes. If > the endpoint > does understand capneg, it is expected to reply with the m=line and > the > particular configuration it has chosen in an acfg attribute. If it > chooses the > unencrypted media as described above with PCMU encoding, it might > follow the m= > line with > a=acfg:0 m=6,8 p=0 ptm=0 > In either case, the answering endpoint can include latent > configurations as > well. > > In the simple case that the offeror doesn't want to offer any > latent media > configurations, but does want to offer the SRTP alternative, the > SDP could be > reduced to the following: > ... (skipping over initial session lines) > 9) m=audio 22222 AVT/RTP 0 18 100 ; standard audio line > 10) a=rtpmap:100 events > 11) a=fmt:100 0-15 > 3) a=ctrpr:1 RTP/SAVP ;transport profile > 4) a=capar:1 a=crypto:1 AES_CM_128_HMAC_SHA1_32 > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20| > 1:32 > 12) a=cptmap:1 1:101 2:102 3:103 > 13) a=pcfg:1 m=1,3|2,3 p=1 a=1 ptm=1 ;(SRTP option) > > Line 12, and the ptm=1 parameter in line 13, could be eliminated if > the > offeror doesn't need to use the payload types to decide early media > can > be rendered. > > My apologies for numbering errors, etc. Please reply with any > comments, > corrections, additions, etc. > -Bob > ---------------------------------------------------- > Bob Gilman rrg@avaya.com +1 303 538 3868 > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 03:48:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HJv-0003Qt-CK; Tue, 23 Jan 2007 03:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HJt-0003OG-CN for mmusic@ietf.org; Tue, 23 Jan 2007 03:47:57 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9HJr-00027f-Vj for mmusic@ietf.org; Tue, 23 Jan 2007 03:47:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Capability negotiation and best effort SRTP Date: Tue, 23 Jan 2007 10:47:53 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C043D858C@IsrExch01.israel.polycom.com> In-Reply-To: <1DE8EC8A-6305-4F76-A6AB-F967B252A04A@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Capability negotiation and best effort SRTP Thread-Index: Acc+ylf0KG5+yGJiRz2dK1jUlCED4QAAKnag From: "Even, Roni" To: "Colin Perkins" , "Stach, Thomas" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Colin, Your example is the same as the example in section 2.1 of the draft Roni > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Tuesday, January 23, 2007 10:41 AM > To: Stach, Thomas > Cc: Elwell, John; mmusic@ietf.org > Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP >=20 > On 22 Jan 2007, at 15:56, Stach, Thomas wrote: > ... > > Below are the essentials of the example offer from Fleming's draft > > for best-effort SRTP > > > > m=3Daudio 3456 RTP/AVP 0 18 > > a=3Dctrpr:1 RTP/SAVP RTP/AVP > > a=3Dcapar:1 a=3Dcrypto: ... > > a=3Dpcfg: p=3D1 a=3D1 > > a=3Dpcfg: p=3D2 > > > > The answer could look like > > > > m=3Daudio 4567 RTP/SAVP 0 18 > > a=3Dcrypto: ... > > a=3Dacfg: p=3D1 a=3D1 >=20 > Why do we need to specify the actual ("m=3D" line configuration) as a > potential configuration? I'd like to signal: >=20 > m=3Daudio 3456 RTP/AVP 0 18 > a=3Dctrpr:1 RTP/SAVP > a=3Dcapar:1 a=3Dcrypto: ... > a=3Dpcfg: p=3D1 a=3D1 >=20 > as the offer, with an implied potential configuration 0 for RTP/AVP. > That comes close to the simplicity of the best-effort-srtp draft for > that use case, but with more extensibility. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 04:16:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Hkz-00084P-9o; Tue, 23 Jan 2007 04:15:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Hky-00084H-4k for mmusic@ietf.org; Tue, 23 Jan 2007 04:15:56 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Hkw-0000Fc-Ph for mmusic@ietf.org; Tue, 23 Jan 2007 04:15:56 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61356 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1H9Hkw-0001wM-18; Tue, 23 Jan 2007 09:15:54 +0000 In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C043D858C@IsrExch01.israel.polycom.com> References: <144ED8561CE90C41A3E5908EDECE315C043D858C@IsrExch01.israel.polycom.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <902E2C61-6DEE-43F1-939B-9DF659FF2062@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP Date: Tue, 23 Jan 2007 09:15:51 +0000 To: "Even, Roni" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "Stach, Thomas" , "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Roni, I'm not sure which example you're refering to? The example I see in section 2.1 is significantly more complex. Colin On 23 Jan 2007, at 08:47, Even, Roni wrote: > Colin, > Your example is the same as the example in section 2.1 of the draft > Roni > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Tuesday, January 23, 2007 10:41 AM >> To: Stach, Thomas >> Cc: Elwell, John; mmusic@ietf.org >> Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP >> >> On 22 Jan 2007, at 15:56, Stach, Thomas wrote: >> ... >>> Below are the essentials of the example offer from Fleming's draft >>> for best-effort SRTP >>> >>> m=audio 3456 RTP/AVP 0 18 >>> a=ctrpr:1 RTP/SAVP RTP/AVP >>> a=capar:1 a=crypto: ... >>> a=pcfg: p=1 a=1 >>> a=pcfg: p=2 >>> >>> The answer could look like >>> >>> m=audio 4567 RTP/SAVP 0 18 >>> a=crypto: ... >>> a=acfg: p=1 a=1 >> >> Why do we need to specify the actual ("m=" line configuration) as a >> potential configuration? I'd like to signal: >> >> m=audio 3456 RTP/AVP 0 18 >> a=ctrpr:1 RTP/SAVP >> a=capar:1 a=crypto: ... >> a=pcfg: p=1 a=1 >> >> as the offer, with an implied potential configuration 0 for RTP/AVP. >> That comes close to the simplicity of the best-effort-srtp draft for >> that use case, but with more extensibility. >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 04:16:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Hls-0000Cn-43; Tue, 23 Jan 2007 04:16:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Hlq-0000Cc-PR for mmusic@ietf.org; Tue, 23 Jan 2007 04:16:50 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Hlh-0000QS-CO for mmusic@ietf.org; Tue, 23 Jan 2007 04:16:50 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zqx.siemens.at with ESMTP id l0N9DdpB022004; Tue, 23 Jan 2007 10:13:39 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l0N9GW2Z017194; Tue, 23 Jan 2007 10:16:33 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 10:16:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Capability negotiation and best effort SRTP Date: Tue, 23 Jan 2007 10:16:30 +0100 Message-ID: In-Reply-To: <1DE8EC8A-6305-4F76-A6AB-F967B252A04A@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Capability negotiation and best effort SRTP Thread-Index: Acc+yiz+FiiXviSGRtmoE4ojXYST0AABEWFw From: "Stach, Thomas" To: "Colin Perkins" X-OriginalArrivalTime: 23 Jan 2007 09:16:32.0806 (UTC) FILETIME=[2C705460:01C73ECF] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070123101339-3D41EBB0-0ABE6236/0-0/0-15 X-purgate-size: 1343/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org =20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: Tuesday, January 23, 2007 9:41 AM > To: Stach, Thomas > Cc: Elwell, John; mmusic@ietf.org > Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP >=20 > On 22 Jan 2007, at 15:56, Stach, Thomas wrote: > ... > > Below are the essentials of the example offer from Fleming's draft =20 > > for best-effort SRTP > > > > m=3Daudio 3456 RTP/AVP 0 18 > > a=3Dctrpr:1 RTP/SAVP RTP/AVP > > a=3Dcapar:1 a=3Dcrypto: ... > > a=3Dpcfg: p=3D1 a=3D1 > > a=3Dpcfg: p=3D2 > > > > The answer could look like > > > > m=3Daudio 4567 RTP/SAVP 0 18 > > a=3Dcrypto: ... > > a=3Dacfg: p=3D1 a=3D1 >=20 > Why do we need to specify the actual ("m=3D" line configuration) as a = > potential configuration? I'd like to signal: >=20 > m=3Daudio 3456 RTP/AVP 0 18 > a=3Dctrpr:1 RTP/SAVP > a=3Dcapar:1 a=3Dcrypto: ... > a=3Dpcfg: p=3D1 a=3D1 >=20 > as the offer, with an implied potential configuration 0 for RTP/AVP. =20 > That comes close to the simplicity of the best-effort-srtp draft for =20 > that use case, but with more extensibility. Colin, that's fine with me.=20 I just took the example from section 3.1. as a basis. Regards Thomas >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 04:24:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ht7-00047M-18; Tue, 23 Jan 2007 04:24:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ht6-00047C-7J for mmusic@ietf.org; Tue, 23 Jan 2007 04:24:20 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Ht3-0002hz-Q5 for mmusic@ietf.org; Tue, 23 Jan 2007 04:24:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Capability negotiation and best effort SRTP Date: Tue, 23 Jan 2007 11:24:13 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C043D859C@IsrExch01.israel.polycom.com> In-Reply-To: <902E2C61-6DEE-43F1-939B-9DF659FF2062@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Capability negotiation and best effort SRTP Thread-Index: Acc+z4qr+84/18MdRwSiFsvbkuADjwAAGbog From: "Even, Roni" To: "Colin Perkins" X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "Stach, Thomas" , "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Colin, What I meant is that this example is showing that you do not need to list AVP in the ctrpr and if you do not have p=3D in the pcfg than it means that you offer AVP Roni > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Tuesday, January 23, 2007 11:16 AM > To: Even, Roni > Cc: Stach, Thomas; Elwell, John; mmusic@ietf.org > Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP >=20 > Roni, >=20 > I'm not sure which example you're refering to? The example I see in > section 2.1 is significantly more complex. >=20 > Colin >=20 >=20 >=20 > On 23 Jan 2007, at 08:47, Even, Roni wrote: > > Colin, > > Your example is the same as the example in section 2.1 of the draft > > Roni > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@csperkins.org] > >> Sent: Tuesday, January 23, 2007 10:41 AM > >> To: Stach, Thomas > >> Cc: Elwell, John; mmusic@ietf.org > >> Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP > >> > >> On 22 Jan 2007, at 15:56, Stach, Thomas wrote: > >> ... > >>> Below are the essentials of the example offer from Fleming's draft > >>> for best-effort SRTP > >>> > >>> m=3Daudio 3456 RTP/AVP 0 18 > >>> a=3Dctrpr:1 RTP/SAVP RTP/AVP > >>> a=3Dcapar:1 a=3Dcrypto: ... > >>> a=3Dpcfg: p=3D1 a=3D1 > >>> a=3Dpcfg: p=3D2 > >>> > >>> The answer could look like > >>> > >>> m=3Daudio 4567 RTP/SAVP 0 18 > >>> a=3Dcrypto: ... > >>> a=3Dacfg: p=3D1 a=3D1 > >> > >> Why do we need to specify the actual ("m=3D" line configuration) as = a > >> potential configuration? I'd like to signal: > >> > >> m=3Daudio 3456 RTP/AVP 0 18 > >> a=3Dctrpr:1 RTP/SAVP > >> a=3Dcapar:1 a=3Dcrypto: ... > >> a=3Dpcfg: p=3D1 a=3D1 > >> > >> as the offer, with an implied potential configuration 0 for RTP/AVP. > >> That comes close to the simplicity of the best-effort-srtp draft for > >> that use case, but with more extensibility. > >> > >> -- > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 08:05:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9LK5-0002Va-Lh; Tue, 23 Jan 2007 08:04:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9LK4-0002VR-9P for mmusic@ietf.org; Tue, 23 Jan 2007 08:04:24 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9LK2-0003ph-QM for mmusic@ietf.org; Tue, 23 Jan 2007 08:04:24 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:58665) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1H9LK1-0002QE-Vj; Tue, 23 Jan 2007 13:04:21 +0000 In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C043D859C@IsrExch01.israel.polycom.com> References: <144ED8561CE90C41A3E5908EDECE315C043D859C@IsrExch01.israel.polycom.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <524AD311-CA4C-4DE5-99A1-540AFEC55F64@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP Date: Tue, 23 Jan 2007 13:04:19 +0000 To: "Even, Roni" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: "Stach, Thomas" , "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Okay - my main point is that showing how this can simply solve the best effort srtp example is important. Colin On 23 Jan 2007, at 09:24, Even, Roni wrote: > Colin, > What I meant is that this example is showing that you do not need to > list AVP in the ctrpr and if you do not have p= in the pcfg than it > means that you offer AVP > Roni > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Tuesday, January 23, 2007 11:16 AM >> To: Even, Roni >> Cc: Stach, Thomas; Elwell, John; mmusic@ietf.org >> Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP >> >> Roni, >> >> I'm not sure which example you're refering to? The example I see in >> section 2.1 is significantly more complex. >> >> Colin >> >> >> >> On 23 Jan 2007, at 08:47, Even, Roni wrote: >>> Colin, >>> Your example is the same as the example in section 2.1 of the draft >>> Roni >>> >>>> -----Original Message----- >>>> From: Colin Perkins [mailto:csp@csperkins.org] >>>> Sent: Tuesday, January 23, 2007 10:41 AM >>>> To: Stach, Thomas >>>> Cc: Elwell, John; mmusic@ietf.org >>>> Subject: Re: [MMUSIC] Capability negotiation and best effort SRTP >>>> >>>> On 22 Jan 2007, at 15:56, Stach, Thomas wrote: >>>> ... >>>>> Below are the essentials of the example offer from Fleming's draft >>>>> for best-effort SRTP >>>>> >>>>> m=audio 3456 RTP/AVP 0 18 >>>>> a=ctrpr:1 RTP/SAVP RTP/AVP >>>>> a=capar:1 a=crypto: ... >>>>> a=pcfg: p=1 a=1 >>>>> a=pcfg: p=2 >>>>> >>>>> The answer could look like >>>>> >>>>> m=audio 4567 RTP/SAVP 0 18 >>>>> a=crypto: ... >>>>> a=acfg: p=1 a=1 >>>> >>>> Why do we need to specify the actual ("m=" line configuration) as a >>>> potential configuration? I'd like to signal: >>>> >>>> m=audio 3456 RTP/AVP 0 18 >>>> a=ctrpr:1 RTP/SAVP >>>> a=capar:1 a=crypto: ... >>>> a=pcfg: p=1 a=1 >>>> >>>> as the offer, with an implied potential configuration 0 for > RTP/AVP. >>>> That comes close to the simplicity of the best-effort-srtp draft > for >>>> that use case, but with more extensibility. >>>> >>>> -- >>>> Colin Perkins >>>> http://csperkins.org/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >> >> -- >> Colin Perkins >> http://csperkins.org/ >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 08:41:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Lu0-0002hL-Lw; Tue, 23 Jan 2007 08:41:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ltz-0002hF-2m for mmusic@ietf.org; Tue, 23 Jan 2007 08:41:31 -0500 Received: from mxs2.siemens.at ([194.138.12.133] helo=atvies1zrx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Ltq-0004Ny-8P for mmusic@ietf.org; Tue, 23 Jan 2007 08:41:31 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by atvies1zrx.siemens.at with ESMTP id l0NDeSZ3005484; Tue, 23 Jan 2007 14:40:29 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l0NDf81O009300; Tue, 23 Jan 2007 14:41:08 +0100 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 14:41:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations Date: Tue, 23 Jan 2007 14:41:06 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Modified Proposal for Capability Negotiations Thread-Index: Acc+ytRKWN3SYnRSThW8MaTX2lPv8AACWV+Q From: "Stach, Thomas" To: "Colin Perkins" , "Robert R. Gilman" X-OriginalArrivalTime: 23 Jan 2007 13:41:08.0462 (UTC) FILETIME=[231130E0:01C73EF4] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070123144028-73E3BBB0-14F6D853/0-0/0-15 X-purgate-size: 10820/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Colin, Bob, I like the proposal as well since it clearly separates media capabilities from the rest of the attributes in the a=3Dcapar: line that Fleming's original proposal had defined as container for all attribute lines. =20 I also share the concern about time pressure.=20 So, what about moving the media related work to a separate document? This would leave the basic negotiation framework, extensibility and a solution for best effort SRTP for an initial step. With this limited scope the document could be ready for a last call quite soon. Regards Thomas > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: Tuesday, January 23, 2007 9:45 AM > To: Robert R. Gilman > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Modified Proposal for Capability Negotiations >=20 > I like this... but it's a big change to the SDP semantics. >=20 > If we were starting from scratch, or weren't under such time =20 > pressure, it would definitely be worth serious configuration.=20 > For the =20 > current design team, where we need something ready for working group =20 > last call before the Prague meeting, I'm concerned that we need =20 > something closer to the current semantics. >=20 > Colin >=20 >=20 >=20 > On 17 Jan 2007, at 00:08, Robert R. Gilman wrote: > > I've been playing with a means to make the cmed attribute line =20 > > independent > > of payload types, so it can be use at the session level or media =20 > > level to > > define media encodings. These can be combined with transport =20 > > protocols > > at the session or media levels, and payload types at the=20 > media level. > > Here's an approach that doesn't simply replicate the existing m-=20 > > line in a > > cmed attribute. It builds up the capabilities from mime type/=20 > > subtypes, > > encoding parameters, and format parameters. Note that the=20 > cenc and =20 > > cfmt > > lines are tied directly into the subtypes listed in the cmed line =20 > > via the > > subtype ordinal; they are implicitly incorporated in the pcfg =20 > > attribute > > by reference to their subtype ordinal(s). One of the=20 > advantages of =20 > > doing > > this binding early is that an endpoint can offer a=20 > particular codec =20 > > with > > different format parameters (e.g., G.729 and G.729B). > > > > Define/redefine the following new attributes: > > > > a=3Dcmed: subtypes> > > This line defines the set of codecs supported, and assigns > > an ordinal to each codec. The codecs are referenced via their > > ordinals in pcfg or acfg lines (via the m=3D parameter), and in > > cenc and cfmt attributes. > > If the first subtype ordinal is 's', say, the the first mime > > subtype corresponds to "subtyp s", the next to "s+1", and =20 > > so on. > > example: a=3Dcmed:1 PCMU G729 G729 iLBC events > > ; PCMU=3D1, G729=3D2, G729=3D3 iLBC=3D4, events=3D5 > > > > a=3Dctrpr: > > This line defines the transport protocols/profiles supported; > > the pcfg line will refer to one of these via "p=3D" > > example: a=3Dctrpr:1 RTP/AVP RTP/SAVP =3D> RTP/AVP=3D1 = RTP/SAVP=3D2 > > > > a=3Dcenc: [/] > > This line defines encoding attributes for the specified=20 > mime subtype. > > It is effectively incorporated as part of the codec with the =20 > > specified > > ordinal. > > example: a=3Dcenc:4 8000 ;sample rate for iLBC > > > > a=3Dcfmt: > > This line defines format parameters for the specified=20 > mime subtype. > > It is effectively incorporated as part of the codec with the =20 > > specified > > ordinal. > > example: a=3Dcfmt:2 annexb:no ;codec 2 doesn't support =20 > > comfort noise > > > > a=3Dcptmap: : > type> pairs> > > This line defines the payload type(s) to be used with a=20 > particular > > configuration and referenced via "ptm=3D". It may only be used by > > offered configurations, not latent configurations. > > example: a=3Dcptmap:1 2:99 3:100 ; maps G.729 to PT 99, iLBC = =20 > > to PT 100 > > > > The remaining attributes (pcfg, acfg, capar) are defined as in =20 > > Flemming's draft: > > . > > > > Then we might have an offer like the following. This announces =20 > > support > > for 4 audio codecs (G.711mu-law, G.729, G.729B, iLBC) and in-band =20 > > telephony > > events for DTMF and Flash. > > ... (skipping over initial session lines) > > 1) a=3Dcmed:1 audio PCMU G729 G729 iLBC events > > 2) a=3Dcenc:4 8000 ;iLBC with 8K sample = =20 > > rate > > 3) a=3Dctrpr:1 RTP/AVP RTP/SAVP ;transport profiles > > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|=20 > > 1:32 > > 5) a=3Dcfmt:2 annexb:no ;no comfort=20 > noise for =20 > > G.729 > > 6) a=3Dcfmt:5 0-15,16 ;DTMF plus=20 > flash events > > 7) a=3Dpcfg:1 m=3D3,5|4,5 t=3D1 ;a latent AVP = capset > > 8) a=3Dpcfg:2 m=3D3,5|4,5 t=3D2 a=3D1 ;a latent SAVP = capset > > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard audio line > > 10) a=3Drtpmap:100 events > > 11) a=3Dfmt:100 0-15 > > 12) a=3Dcptmap:1 1:101 2:102 5:103 > > 13) a=3Dpcfg:3 m=3D1,5|2,5 p=3D2 a=3D1 ptm=3D1 ;(SRTP = option) > > > > Notes: > > 1) This cmed line defines a set of audio codecs numbered 1-5. > > 2) This cenc line defines adds encoding rate information=20 > for codec 3. > > 3) This ctpr line defines two transport profiles numbered 1-2. > > 4) This capar line defines an SDES crypto attribute. > > 5) This cfmt line defines format parameters for codec 3 (G.729) > > 6) This cfmt line defines the telephony event parameters for =20 > > "codec 5", > > the telephony events. > > 7) This pcfg line defines a latent AVP capset with any one of the =20 > > four > > audio codecs plus DTMF telephony events. > > 8) This pcfg line defines a latent SAVP capset with the same =20 > > combinations > > of codecs/tlephony events. > > 9) This is the conventional media line for audio with=20 > G.711mu-law, =20 > > G.729B, > > and a dynamic payload type. > > 10) "Traditional" SDP for backward compatibility. > > 11) "Traditional" SDP for backward compatibility. > > 9)-11) In case the receiver understands capability=20 > negotiation, but =20 > > wishes to > > choose the AVT/RTP offer rather than encryption, we define > > that the m=3D line defines "pcfg:0", "cptmap:0", transport =20 > > type "0", and > > the media codecs are assigned the next codec ordinals =20 > > following those > > defined at the session level (codecs defined at the media =20 > > level via cmed > > attributes will be numbered following those defined on the =20 > > m=3Dline). > > Thus, the m=3D line and the following rtpmap and fmtp lines =20 > > are equivalent > > to: > > a=3Dcmed:6 PCMU G729 event > > a=3Dcptmap:0 8:100 > > a=3Dpcfg:0 m=3D6,7,8 p=3D0 ptm=3D0 > > Any pcfg: line at the media level may refer to the codecs =20 > > and transports > > defined by the current m=3D line. > > 12) This line provides the payload types for each cmed codec for =20 > > this media > > stream. The payload types are chosen, in this case, so that =20 > > the receiver > > can use them to tell which choices the answerer made if media =20 > > is received > > by the offeror before the answer arrives. > > 13) This line specifies an alternative media stream using SRTP. > > p=3D2 invokes the second transport protocol (RTP/SAVP) from the = > > ctrpr > > line. > > a=3D1 identifies the SDES crypto attribute > > ptm=3D1 identifies the payload map. I've used "1" to identify = the > > entire line, but we could use numbers to identify each =20 > > mapping, > > as ptm=3D1,2,3 > > Note that there are no references to the cfmt or cenc =20 > > attributes - they're > > always attached to their respective media subtypes. > > > > Given an offer in the above form, a endpoint that doesn't =20 > > understand the capneg > > attributes will respond with the usual m=3D line and attributes. If = =20 > > the endpoint > > does understand capneg, it is expected to reply with the=20 > m=3Dline and =20 > > the > > particular configuration it has chosen in an acfg=20 > attribute. If it =20 > > chooses the > > unencrypted media as described above with PCMU encoding, it might =20 > > follow the m=3D > > line with > > a=3Dacfg:0 m=3D6,8 p=3D0 ptm=3D0 > > In either case, the answering endpoint can include latent =20 > > configurations as > > well. > > > > In the simple case that the offeror doesn't want to offer any =20 > > latent media > > configurations, but does want to offer the SRTP alternative, the =20 > > SDP could be > > reduced to the following: > > ... (skipping over initial session lines) > > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard audio line > > 10) a=3Drtpmap:100 events > > 11) a=3Dfmt:100 0-15 > > 3) a=3Dctrpr:1 RTP/SAVP ;transport profile > > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|=20 > > 1:32 > > 12) a=3Dcptmap:1 1:101 2:102 3:103 > > 13) a=3Dpcfg:1 m=3D1,3|2,3 p=3D1 a=3D1 ptm=3D1 ;(SRTP = option) > > > > Line 12, and the ptm=3D1 parameter in line 13, could be=20 > eliminated if =20 > > the > > offeror doesn't need to use the payload types to decide=20 > early media =20 > > can > > be rendered. > > > > My apologies for numbering errors, etc. Please reply with any =20 > > comments, > > corrections, additions, etc. > > -Bob > > ---------------------------------------------------- > > Bob Gilman rrg@avaya.com +1 303 538 3868 > > > > > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 09:28:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Mdk-0000hz-NH; Tue, 23 Jan 2007 09:28:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Mdj-0000fs-Uf for mmusic@ietf.org; Tue, 23 Jan 2007 09:28:47 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Mdj-0008GG-3J for mmusic@ietf.org; Tue, 23 Jan 2007 09:28:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations Date: Tue, 23 Jan 2007 16:28:34 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C043D8668@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Modified Proposal for Capability Negotiations Thread-Index: Acc+ytRKWN3SYnRSThW8MaTX2lPv8AACWV+QAAlq5CA= From: "Even, Roni" To: "Stach, Thomas" , "Colin Perkins" , "Robert R. Gilman" X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, I am not sure what you mean about the media related work. Everything here is about media. Bob tried to address a way to support session level attributes so that they can be mapped to a PT in the media line. As for the timeline, I have not heard from the design team any concerns about time. The design team charter agreed in San Diego was to look at general solution.=20 Being able to know the media capabilities of the remote side separately from the current negotiated media session is already a problem for changing codec in mid calls. So it is not only the issue of best-effort SRTP Roni Even=20 > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@siemens.com] > Sent: Tuesday, January 23, 2007 3:41 PM > To: Colin Perkins; Robert R. Gilman > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations >=20 > Colin, Bob, >=20 > I like the proposal as well since it clearly separates media > capabilities from the rest of the attributes in the a=3Dcapar: line = that > Fleming's original proposal had defined as container for all attribute > lines. >=20 > I also share the concern about time pressure. > So, what about moving the media related work to a separate document? > This would leave the basic negotiation framework, extensibility and a > solution for best effort SRTP for an initial step. > With this limited scope the document could be ready for a last call > quite soon. >=20 >=20 > Regards > Thomas >=20 >=20 > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: Tuesday, January 23, 2007 9:45 AM > > To: Robert R. Gilman > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Modified Proposal for Capability Negotiations > > > > I like this... but it's a big change to the SDP semantics. > > > > If we were starting from scratch, or weren't under such time > > pressure, it would definitely be worth serious configuration. > > For the > > current design team, where we need something ready for working group > > last call before the Prague meeting, I'm concerned that we need > > something closer to the current semantics. > > > > Colin > > > > > > > > On 17 Jan 2007, at 00:08, Robert R. Gilman wrote: > > > I've been playing with a means to make the cmed attribute line > > > independent > > > of payload types, so it can be use at the session level or media > > > level to > > > define media encodings. These can be combined with transport > > > protocols > > > at the session or media levels, and payload types at the > > media level. > > > Here's an approach that doesn't simply replicate the existing m- > > > line in a > > > cmed attribute. It builds up the capabilities from mime type/ > > > subtypes, > > > encoding parameters, and format parameters. Note that the > > cenc and > > > cfmt > > > lines are tied directly into the subtypes listed in the cmed line > > > via the > > > subtype ordinal; they are implicitly incorporated in the pcfg > > > attribute > > > by reference to their subtype ordinal(s). One of the > > advantages of > > > doing > > > this binding early is that an endpoint can offer a > > particular codec > > > with > > > different format parameters (e.g., G.729 and G.729B). > > > > > > Define/redefine the following new attributes: > > > > > > a=3Dcmed: > subtypes> > > > This line defines the set of codecs supported, and assigns > > > an ordinal to each codec. The codecs are referenced via their > > > ordinals in pcfg or acfg lines (via the m=3D parameter), and in > > > cenc and cfmt attributes. > > > If the first subtype ordinal is 's', say, the the first mime > > > subtype corresponds to "subtyp s", the next to "s+1", and > > > so on. > > > example: a=3Dcmed:1 PCMU G729 G729 iLBC events > > > ; PCMU=3D1, G729=3D2, G729=3D3 iLBC=3D4, events=3D5 > > > > > > a=3Dctrpr: > > > This line defines the transport protocols/profiles supported; > > > the pcfg line will refer to one of these via "p=3D" > > > example: a=3Dctrpr:1 RTP/AVP RTP/SAVP =3D> RTP/AVP=3D1 = RTP/SAVP=3D2 > > > > > > a=3Dcenc: [/] > > > This line defines encoding attributes for the specified > > mime subtype. > > > It is effectively incorporated as part of the codec with the > > > specified > > > ordinal. > > > example: a=3Dcenc:4 8000 ;sample rate for iLBC > > > > > > a=3Dcfmt: > > > This line defines format parameters for the specified > > mime subtype. > > > It is effectively incorporated as part of the codec with the > > > specified > > > ordinal. > > > example: a=3Dcfmt:2 annexb:no ;codec 2 doesn't support > > > comfort noise > > > > > > a=3Dcptmap: : > > type> pairs> > > > This line defines the payload type(s) to be used with a > > particular > > > configuration and referenced via "ptm=3D". It may only be used = by > > > offered configurations, not latent configurations. > > > example: a=3Dcptmap:1 2:99 3:100 ; maps G.729 to PT 99, = iLBC > > > to PT 100 > > > > > > The remaining attributes (pcfg, acfg, capar) are defined as in > > > Flemming's draft: > > > . > > > > > > Then we might have an offer like the following. This announces > > > support > > > for 4 audio codecs (G.711mu-law, G.729, G.729B, iLBC) and in-band > > > telephony > > > events for DTMF and Flash. > > > ... (skipping over initial session lines) > > > 1) a=3Dcmed:1 audio PCMU G729 G729 iLBC events > > > 2) a=3Dcenc:4 8000 ;iLBC with 8K = sample > > > rate > > > 3) a=3Dctrpr:1 RTP/AVP RTP/SAVP ;transport = profiles > > > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20| > > > 1:32 > > > 5) a=3Dcfmt:2 annexb:no ;no comfort > > noise for > > > G.729 > > > 6) a=3Dcfmt:5 0-15,16 ;DTMF plus > > flash events > > > 7) a=3Dpcfg:1 m=3D3,5|4,5 t=3D1 ;a latent AVP = capset > > > 8) a=3Dpcfg:2 m=3D3,5|4,5 t=3D2 a=3D1 ;a latent = SAVP capset > > > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard audio = line > > > 10) a=3Drtpmap:100 events > > > 11) a=3Dfmt:100 0-15 > > > 12) a=3Dcptmap:1 1:101 2:102 5:103 > > > 13) a=3Dpcfg:3 m=3D1,5|2,5 p=3D2 a=3D1 ptm=3D1 ;(SRTP = option) > > > > > > Notes: > > > 1) This cmed line defines a set of audio codecs numbered 1-5. > > > 2) This cenc line defines adds encoding rate information > > for codec 3. > > > 3) This ctpr line defines two transport profiles numbered 1-2. > > > 4) This capar line defines an SDES crypto attribute. > > > 5) This cfmt line defines format parameters for codec 3 (G.729) > > > 6) This cfmt line defines the telephony event parameters for > > > "codec 5", > > > the telephony events. > > > 7) This pcfg line defines a latent AVP capset with any one of the > > > four > > > audio codecs plus DTMF telephony events. > > > 8) This pcfg line defines a latent SAVP capset with the same > > > combinations > > > of codecs/tlephony events. > > > 9) This is the conventional media line for audio with > > G.711mu-law, > > > G.729B, > > > and a dynamic payload type. > > > 10) "Traditional" SDP for backward compatibility. > > > 11) "Traditional" SDP for backward compatibility. > > > 9)-11) In case the receiver understands capability > > negotiation, but > > > wishes to > > > choose the AVT/RTP offer rather than encryption, we define > > > that the m=3D line defines "pcfg:0", "cptmap:0", transport > > > type "0", and > > > the media codecs are assigned the next codec ordinals > > > following those > > > defined at the session level (codecs defined at the media > > > level via cmed > > > attributes will be numbered following those defined on the > > > m=3Dline). > > > Thus, the m=3D line and the following rtpmap and fmtp lines > > > are equivalent > > > to: > > > a=3Dcmed:6 PCMU G729 event > > > a=3Dcptmap:0 8:100 > > > a=3Dpcfg:0 m=3D6,7,8 p=3D0 ptm=3D0 > > > Any pcfg: line at the media level may refer to the codecs > > > and transports > > > defined by the current m=3D line. > > > 12) This line provides the payload types for each cmed codec for > > > this media > > > stream. The payload types are chosen, in this case, so that > > > the receiver > > > can use them to tell which choices the answerer made if media > > > is received > > > by the offeror before the answer arrives. > > > 13) This line specifies an alternative media stream using SRTP. > > > p=3D2 invokes the second transport protocol (RTP/SAVP) from = the > > > ctrpr > > > line. > > > a=3D1 identifies the SDES crypto attribute > > > ptm=3D1 identifies the payload map. I've used "1" to identify the > > > entire line, but we could use numbers to identify each > > > mapping, > > > as ptm=3D1,2,3 > > > Note that there are no references to the cfmt or cenc > > > attributes - they're > > > always attached to their respective media subtypes. > > > > > > Given an offer in the above form, a endpoint that doesn't > > > understand the capneg > > > attributes will respond with the usual m=3D line and attributes. = If > > > the endpoint > > > does understand capneg, it is expected to reply with the > > m=3Dline and > > > the > > > particular configuration it has chosen in an acfg > > attribute. If it > > > chooses the > > > unencrypted media as described above with PCMU encoding, it might > > > follow the m=3D > > > line with > > > a=3Dacfg:0 m=3D6,8 p=3D0 ptm=3D0 > > > In either case, the answering endpoint can include latent > > > configurations as > > > well. > > > > > > In the simple case that the offeror doesn't want to offer any > > > latent media > > > configurations, but does want to offer the SRTP alternative, the > > > SDP could be > > > reduced to the following: > > > ... (skipping over initial session lines) > > > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard audio = line > > > 10) a=3Drtpmap:100 events > > > 11) a=3Dfmt:100 0-15 > > > 3) a=3Dctrpr:1 RTP/SAVP ;transport profile > > > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20| > > > 1:32 > > > 12) a=3Dcptmap:1 1:101 2:102 3:103 > > > 13) a=3Dpcfg:1 m=3D1,3|2,3 p=3D1 a=3D1 ptm=3D1 ;(SRTP = option) > > > > > > Line 12, and the ptm=3D1 parameter in line 13, could be > > eliminated if > > > the > > > offeror doesn't need to use the payload types to decide > > early media > > > can > > > be rendered. > > > > > > My apologies for numbering errors, etc. Please reply with any > > > comments, > > > corrections, additions, etc. > > > -Bob > > > ---------------------------------------------------- > > > Bob Gilman rrg@avaya.com +1 303 538 3868 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 09:57:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9N57-0006kv-9Q; Tue, 23 Jan 2007 09:57:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9N54-0006en-VE for mmusic@ietf.org; Tue, 23 Jan 2007 09:57:03 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9N52-0006yq-7N for mmusic@ietf.org; Tue, 23 Jan 2007 09:57:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations Date: Tue, 23 Jan 2007 16:56:48 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C043D8676@IsrExch01.israel.polycom.com> In-Reply-To: <45AD68F1.2080402@avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Modified Proposal for Capability Negotiations Thread-Index: Acc5zE0KZWfzCdx1SZK9O5+N4wY4UgFMOCmg From: "Even, Roni" To: "Robert R. Gilman" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Bob, Comments You use the pcfg with an ordinance number in lines 7, 8, 13. The current draft does not have ordinance number and all pcfgs are after the media m line by preference order. Why change Your usage of the pcfg in the document is different and not needed. The order of AVP or SAVP will be done by using two pcfg after the m line one with p=3D1 for AVP and the other with p=3D2 for SAVP, the order is the preference. In line 12 where are the PT mapping for G729 and G729B Some nits 2) This cenc line defines adds encoding rate information for codec 3. - you mean 4 5) This cfmt line defines format parameters for codec 3 (G.729) - you mean 2 Roni > -----Original Message----- > From: Robert R. Gilman [mailto:rrg@avaya.com] > Sent: Wednesday, January 17, 2007 2:08 AM > To: mmusic@ietf.org > Subject: [MMUSIC] Modified Proposal for Capability Negotiations >=20 > I've been playing with a means to make the cmed attribute line independent > of payload types, so it can be use at the session level or media level to > define media encodings. These can be combined with transport protocols > at the session or media levels, and payload types at the media level. > Here's an approach that doesn't simply replicate the existing m-line in a > cmed attribute. It builds up the capabilities from mime type/subtypes, > encoding parameters, and format parameters. Note that the cenc and cfmt > lines are tied directly into the subtypes listed in the cmed line via the > subtype ordinal; they are implicitly incorporated in the pcfg attribute > by reference to their subtype ordinal(s). One of the advantages of doing > this binding early is that an endpoint can offer a particular codec with > different format parameters (e.g., G.729 and G.729B). >=20 > Define/redefine the following new attributes: >=20 > a=3Dcmed: > This line defines the set of codecs supported, and assigns > an ordinal to each codec. The codecs are referenced via their > ordinals in pcfg or acfg lines (via the m=3D parameter), and in > cenc and cfmt attributes. > If the first subtype ordinal is 's', say, the the first mime > subtype corresponds to "subtyp s", the next to "s+1", and so on. > example: a=3Dcmed:1 PCMU G729 G729 iLBC events > ; PCMU=3D1, G729=3D2, G729=3D3 iLBC=3D4, events=3D5 >=20 > a=3Dctrpr: > This line defines the transport protocols/profiles supported; > the pcfg line will refer to one of these via "p=3D" > example: a=3Dctrpr:1 RTP/AVP RTP/SAVP =3D> RTP/AVP=3D1 = RTP/SAVP=3D2 >=20 > a=3Dcenc: [/] > This line defines encoding attributes for the specified mime > subtype. > It is effectively incorporated as part of the codec with the > specified > ordinal. > example: a=3Dcenc:4 8000 ;sample rate for iLBC >=20 > a=3Dcfmt: > This line defines format parameters for the specified mime subtype. > It is effectively incorporated as part of the codec with the > specified > ordinal. > example: a=3Dcfmt:2 annexb:no ;codec 2 doesn't support = comfort > noise >=20 > a=3Dcptmap: : > pairs> > This line defines the payload type(s) to be used with a particular > configuration and referenced via "ptm=3D". It may only be used by > offered configurations, not latent configurations. > example: a=3Dcptmap:1 2:99 3:100 ; maps G.729 to PT 99, iLBC = to PT > 100 >=20 > The remaining attributes (pcfg, acfg, capar) are defined as in Flemming's > draft: > . >=20 > Then we might have an offer like the following. This announces support > for 4 audio codecs (G.711mu-law, G.729, G.729B, iLBC) and in-band > telephony > events for DTMF and Flash. > ... (skipping over initial session lines) > 1) a=3Dcmed:1 audio PCMU G729 G729 iLBC events > 2) a=3Dcenc:4 8000 ;iLBC with 8K sample rate > 3) a=3Dctrpr:1 RTP/AVP RTP/SAVP ;transport profiles > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 > 5) a=3Dcfmt:2 annexb:no ;no comfort noise for G.729 > 6) a=3Dcfmt:5 0-15,16 ;DTMF plus flash = events > 7) a=3Dpcfg:1 m=3D3,5|4,5 t=3D1 ;a latent AVP = capset > 8) a=3Dpcfg:2 m=3D3,5|4,5 t=3D2 a=3D1 ;a latent SAVP = capset > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard audio line > 10) a=3Drtpmap:100 events > 11) a=3Dfmt:100 0-15 > 12) a=3Dcptmap:1 1:101 2:102 5:103 > 13) a=3Dpcfg:3 m=3D1,5|2,5 p=3D2 a=3D1 ptm=3D1 ;(SRTP = option) >=20 > Notes: > 1) This cmed line defines a set of audio codecs numbered 1-5. > 2) This cenc line defines adds encoding rate information for codec 3. > 3) This ctpr line defines two transport profiles numbered 1-2. > 4) This capar line defines an SDES crypto attribute. > 5) This cfmt line defines format parameters for codec 3 (G.729) > 6) This cfmt line defines the telephony event parameters for "codec 5", > the telephony events. > 7) This pcfg line defines a latent AVP capset with any one of the four > audio codecs plus DTMF telephony events. > 8) This pcfg line defines a latent SAVP capset with the same combinations > of codecs/tlephony events. > 9) This is the conventional media line for audio with G.711mu-law, > G.729B, > and a dynamic payload type. > 10) "Traditional" SDP for backward compatibility. > 11) "Traditional" SDP for backward compatibility. > 9)-11) In case the receiver understands capability negotiation, but wishes > to > choose the AVT/RTP offer rather than encryption, we define > that the m=3D line defines "pcfg:0", "cptmap:0", transport = type "0", > and > the media codecs are assigned the next codec ordinals following > those > defined at the session level (codecs defined at the media level > via cmed > attributes will be numbered following those defined on the > m=3Dline). > Thus, the m=3D line and the following rtpmap and fmtp lines = are > equivalent > to: > a=3Dcmed:6 PCMU G729 event > a=3Dcptmap:0 8:100 > a=3Dpcfg:0 m=3D6,7,8 p=3D0 ptm=3D0 > Any pcfg: line at the media level may refer to the codecs and > transports > defined by the current m=3D line. > 12) This line provides the payload types for each cmed codec for this > media > stream. The payload types are chosen, in this case, so that the > receiver > can use them to tell which choices the answerer made if media is > received > by the offeror before the answer arrives. > 13) This line specifies an alternative media stream using SRTP. > p=3D2 invokes the second transport protocol (RTP/SAVP) from the ctrpr > line. > a=3D1 identifies the SDES crypto attribute > ptm=3D1 identifies the payload map. I've used "1" to identify = the > entire line, but we could use numbers to identify each mapping, > as ptm=3D1,2,3 > Note that there are no references to the cfmt or cenc attributes - > they're > always attached to their respective media subtypes. >=20 > Given an offer in the above form, a endpoint that doesn't understand the > capneg > attributes will respond with the usual m=3D line and attributes. If = the > endpoint > does understand capneg, it is expected to reply with the m=3Dline and the > particular configuration it has chosen in an acfg attribute. If it > chooses the > unencrypted media as described above with PCMU encoding, it might follow > the m=3D > line with > a=3Dacfg:0 m=3D6,8 p=3D0 ptm=3D0 > In either case, the answering endpoint can include latent configurations > as > well. >=20 > In the simple case that the offeror doesn't want to offer any latent media > configurations, but does want to offer the SRTP alternative, the SDP could > be > reduced to the following: > ... (skipping over initial session lines) > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard audio line > 10) a=3Drtpmap:100 events > 11) a=3Dfmt:100 0-15 > 3) a=3Dctrpr:1 RTP/SAVP ;transport profile > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 > 12) a=3Dcptmap:1 1:101 2:102 3:103 > 13) a=3Dpcfg:1 m=3D1,3|2,3 p=3D1 a=3D1 ptm=3D1 ;(SRTP = option) >=20 > Line 12, and the ptm=3D1 parameter in line 13, could be eliminated if the > offeror doesn't need to use the payload types to decide early media can > be rendered. >=20 > My apologies for numbering errors, etc. Please reply with any comments, > corrections, additions, etc. > -Bob > ---------------------------------------------------- > Bob Gilman rrg@avaya.com +1 303 538 3868 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 11:15:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9OIo-0005kt-QB; Tue, 23 Jan 2007 11:15:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9OIh-0005ce-Hx for mmusic@ietf.org; Tue, 23 Jan 2007 11:15:12 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9OFJ-0005xp-Fv for mmusic@ietf.org; Tue, 23 Jan 2007 11:11:42 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2007 11:11:41 -0500 X-IronPort-AV: i="4.13,226,1167627600"; d="scan'208"; a="112308863:sNHT50162524" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0NGBfRf027880; Tue, 23 Jan 2007 11:11:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0NGBfVT006598; Tue, 23 Jan 2007 11:11:41 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 11:11:40 -0500 Received: from [161.44.174.190] ([161.44.174.190]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 11:11:40 -0500 Message-ID: <45B633BC.4070900@cisco.com> Date: Tue, 23 Jan 2007 11:11:40 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [MMUSIC] Re: Comment on TCP ICE References: <458263F0.4050206@ericsson.com> <459D4F54.6030305@cisco.com> <45B327F5.2010507@ericsson.com> In-Reply-To: <45B327F5.2010507@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2007 16:11:40.0672 (UTC) FILETIME=[2AAF1000:01C73F09] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2909; t=1169568701; x=1170432701; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20Comment=20on=20TCP=20ICE |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=2IvjafhMwTbv49d/quuNJIAIAgQXLXx9rDNtRRKNGF4=; b=UBoMPP65/A6Tg8A8J7I8ljGAQo8tSkZwrQoCrWAOSdAKg848MmtNP5wL1ZRJnbpBJXaDW09c XMunZJhpf5t5xKVVBndniDDpaB14t6PEI1OEzQen5yD773QvgPed+gNB; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org What are the implications here? How are the cases to be distinguished: closed because no longer needed so reopen not desired, vs closed inadvertently and reopen desired. Its no problem if both ends agree on the intent. But if they don't agree then there are small issues. For one side it is a matter of whether to attempt to reopen or not, and for the other side it is whether to be listening or not. Presumably things won't be too awful if they disagree - no connection will be reestablished. But one side or the other will be doing work that is wasted. Do we just leave it to the application to know whether reopening is appropriate? Paul Gonzalo Camarillo wrote: > Hi Jonathan, > > yes, please, go ahead add text clarifying the issue. The thing is that > some sessions actually have media streams that end way before the > session (e.g., a file transfer). We need to be clear on what to do if > one needs to terminate a, say, TCP connection in the middle of a session > and is using ICE. > > Cheers, > > Gonzalo > > Jonathan Rosenberg wrote: >> Sorry for the long delay in responding to all of these. I am finally >> getting back to work on this after a work-based hiatus. >> >> inline. >> >> Gonzalo Camarillo wrote: >> >>> Hi, >>> >>> the TCP ICE spec changes the way TCP connection reestablishment works in >>> RFC 4145. RFC 4145 allows applications to close a TCP connection without >>> requiring a new offer/answer exchange. However, a new offer/answer >>> exchange is required to reestablish (i.e., repair) a connection. >>> >>> TCP ICE, on the other hand, requires a new offer/answer exchange to >>> close a TCP connection, but does not require it to repair a connection. >> >> It is not the intent that a new exchange is required to close a >> connection. The intention is that once a connection is up and in use >> for media, it will stay up and should not normally be closed. However, >> if the client needs to close it, or it closes due to some temporary >> glitch, thats fine - no new o/a exchange is needed to reopen one. The >> only case in which you would normally close a connection is when a >> media stream ends, which does require a new O/A exchange. >> >> >>> >>> The ICE TCP spec says: >>> >>> "Unlike RFC 4145, additional signaling is not required to repair a >>> closed connection." >>> >>> I believe that the ICE TCP spec needs to give a slightly longer >>> explanation about it so that implementers understand both differences. >>> Maybe an extra paragraph along the lines of this email. >> >> I think clearly explanation is needed. If the above sounds OK to you, >> I will add text clarifying that. >> >> -Jonathan R. >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 14:35:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RQK-0003xr-Mp; Tue, 23 Jan 2007 14:35:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9RQI-0003xl-SL for mmusic@ietf.org; Tue, 23 Jan 2007 14:35:14 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9RQH-0002BT-An for mmusic@ietf.org; Tue, 23 Jan 2007 14:35:14 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l0NJZ9q09671; Tue, 23 Jan 2007 14:35:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations Date: Tue, 23 Jan 2007 13:35:07 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0EDBCCC4@zrc2hxm0.corp.nortel.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C043D8668@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Modified Proposal for Capability Negotiations Thread-Index: Acc+ytRKWN3SYnRSThW8MaTX2lPv8AACWV+QAAlq5CAACuaioA== From: "Francois Audet" To: "Even, Roni" , "Stach, Thomas" , "Colin Perkins" , "Robert R. Gilman" X-Spam-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org It was clearly agreed in San Diego AND in Montreal, that time was a huge concern for best-effort SRTP.=20 > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il]=20 > Sent: Tuesday, January 23, 2007 06:29 > To: Stach, Thomas; Colin Perkins; Robert R. Gilman > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations >=20 > Hi, > I am not sure what you mean about the media related work.=20 > Everything here is about media. > Bob tried to address a way to support session level=20 > attributes so that they can be mapped to a PT in the media line. >=20 > As for the timeline, I have not heard from the design team=20 > any concerns about time. The design team charter agreed in=20 > San Diego was to look at general solution.=20 >=20 > Being able to know the media capabilities of the remote side=20 > separately from the current negotiated media session is=20 > already a problem for changing codec in mid calls. So it is=20 > not only the issue of best-effort SRTP >=20 > Roni Even=20 >=20 >=20 > > -----Original Message----- > > From: Stach, Thomas [mailto:thomas.stach@siemens.com] > > Sent: Tuesday, January 23, 2007 3:41 PM > > To: Colin Perkins; Robert R. Gilman > > Cc: mmusic@ietf.org > > Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations > >=20 > > Colin, Bob, > >=20 > > I like the proposal as well since it clearly separates media=20 > > capabilities from the rest of the attributes in the=20 > a=3Dcapar: line that=20 > > Fleming's original proposal had defined as container for=20 > all attribute=20 > > lines. > >=20 > > I also share the concern about time pressure. > > So, what about moving the media related work to a separate document? > > This would leave the basic negotiation framework,=20 > extensibility and a=20 > > solution for best effort SRTP for an initial step. > > With this limited scope the document could be ready for a last call=20 > > quite soon. > >=20 > >=20 > > Regards > > Thomas > >=20 > >=20 > > > -----Original Message----- > > > From: Colin Perkins [mailto:csp@csperkins.org] > > > Sent: Tuesday, January 23, 2007 9:45 AM > > > To: Robert R. Gilman > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Modified Proposal for Capability=20 > Negotiations > > > > > > I like this... but it's a big change to the SDP semantics. > > > > > > If we were starting from scratch, or weren't under such time=20 > > > pressure, it would definitely be worth serious configuration. > > > For the > > > current design team, where we need something ready for=20 > working group=20 > > > last call before the Prague meeting, I'm concerned that we need=20 > > > something closer to the current semantics. > > > > > > Colin > > > > > > > > > > > > On 17 Jan 2007, at 00:08, Robert R. Gilman wrote: > > > > I've been playing with a means to make the cmed attribute line=20 > > > > independent of payload types, so it can be use at the session=20 > > > > level or media level to define media encodings. These can be=20 > > > > combined with transport protocols at the session or=20 > media levels,=20 > > > > and payload types at the > > > media level. > > > > Here's an approach that doesn't simply replicate the=20 > existing m-=20 > > > > line in a cmed attribute. It builds up the=20 > capabilities from mime=20 > > > > type/ subtypes, encoding parameters, and format=20 > parameters. Note=20 > > > > that the > > > cenc and > > > > cfmt > > > > lines are tied directly into the subtypes listed in the=20 > cmed line=20 > > > > via the subtype ordinal; they are implicitly=20 > incorporated in the=20 > > > > pcfg attribute by reference to their subtype=20 > ordinal(s). One of=20 > > > > the > > > advantages of > > > > doing > > > > this binding early is that an endpoint can offer a > > > particular codec > > > > with > > > > different format parameters (e.g., G.729 and G.729B). > > > > > > > > Define/redefine the following new attributes: > > > > > > > > a=3Dcmed: > > subtypes> > > > > This line defines the set of codecs supported,=20 > and assigns > > > > an ordinal to each codec. The codecs are=20 > referenced via their > > > > ordinals in pcfg or acfg lines (via the m=3D=20 > parameter), and in > > > > cenc and cfmt attributes. > > > > If the first subtype ordinal is 's', say, the=20 > the first mime > > > > subtype corresponds to "subtyp s", the next to=20 > "s+1", and=20 > > > > so on. > > > > example: a=3Dcmed:1 PCMU G729 G729 iLBC events > > > > ; PCMU=3D1, G729=3D2, G729=3D3 iLBC=3D4, events=3D5 > > > > > > > > a=3Dctrpr: protocols> > > > > This line defines the transport=20 > protocols/profiles supported; > > > > the pcfg line will refer to one of these via "p=3D" > > > > example: a=3Dctrpr:1 RTP/AVP RTP/SAVP =3D> RTP/AVP=3D1=20 > RTP/SAVP=3D2 > > > > > > > > a=3Dcenc: [/ parameters>] > > > > This line defines encoding attributes for the specified > > > mime subtype. > > > > It is effectively incorporated as part of the=20 > codec with the=20 > > > > specified > > > > ordinal. > > > > example: a=3Dcenc:4 8000 ;sample rate for iLBC > > > > > > > > a=3Dcfmt: > > > > This line defines format parameters for the specified > > > mime subtype. > > > > It is effectively incorporated as part of the=20 > codec with the=20 > > > > specified > > > > ordinal. > > > > example: a=3Dcfmt:2 annexb:no ;codec 2 doesn't support > > > > comfort noise > > > > > > > > a=3Dcptmap: number>: > > > type> pairs> > > > > This line defines the payload type(s) to be used with a > > > particular > > > > configuration and referenced via "ptm=3D". It=20 > may only be used by > > > > offered configurations, not latent configurations. > > > > example: a=3Dcptmap:1 2:99 3:100 ; maps G.729 to=20 > PT 99, iLBC > > > > to PT 100 > > > > > > > > The remaining attributes (pcfg, acfg, capar) are defined as in=20 > > > > Flemming's draft: > > > > . > > > > > > > > Then we might have an offer like the following. This announces=20 > > > > support for 4 audio codecs (G.711mu-law, G.729, G.729B,=20 > iLBC) and=20 > > > > in-band telephony events for DTMF and Flash. > > > > ... (skipping over initial session lines) > > > > 1) a=3Dcmed:1 audio PCMU G729 G729 iLBC events > > > > 2) a=3Dcenc:4 8000 ;iLBC=20 > with 8K sample > > > > rate > > > > 3) a=3Dctrpr:1 RTP/AVP RTP/SAVP =20 > ;transport profiles > > > > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > > > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20| > > > > 1:32 > > > > 5) a=3Dcfmt:2 annexb:no ;no comfort > > > noise for > > > > G.729 > > > > 6) a=3Dcfmt:5 0-15,16 ;DTMF plus > > > flash events > > > > 7) a=3Dpcfg:1 m=3D3,5|4,5 t=3D1 ;a latent=20 > AVP capset > > > > 8) a=3Dpcfg:2 m=3D3,5|4,5 t=3D2 a=3D1 ;a latent = SAVP > capset > > > > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard=20 > audio line > > > > 10) a=3Drtpmap:100 events > > > > 11) a=3Dfmt:100 0-15 > > > > 12) a=3Dcptmap:1 1:101 2:102 5:103 > > > > 13) a=3Dpcfg:3 m=3D1,5|2,5 p=3D2 a=3D1 ptm=3D1 ;(SRTP = option) > > > > > > > > Notes: > > > > 1) This cmed line defines a set of audio codecs numbered 1-5. > > > > 2) This cenc line defines adds encoding rate information > > > for codec 3. > > > > 3) This ctpr line defines two transport profiles numbered 1-2. > > > > 4) This capar line defines an SDES crypto attribute. > > > > 5) This cfmt line defines format parameters for codec 3 (G.729) > > > > 6) This cfmt line defines the telephony event parameters for=20 > > > > "codec 5", > > > > the telephony events. > > > > 7) This pcfg line defines a latent AVP capset with any=20 > one of the=20 > > > > four > > > > audio codecs plus DTMF telephony events. > > > > 8) This pcfg line defines a latent SAVP capset with the same=20 > > > > combinations > > > > of codecs/tlephony events. > > > > 9) This is the conventional media line for audio with > > > G.711mu-law, > > > > G.729B, > > > > and a dynamic payload type. > > > > 10) "Traditional" SDP for backward compatibility. > > > > 11) "Traditional" SDP for backward compatibility. > > > > 9)-11) In case the receiver understands capability > > > negotiation, but > > > > wishes to > > > > choose the AVT/RTP offer rather than encryption,=20 > we define > > > > that the m=3D line defines "pcfg:0", "cptmap:0", = transport=20 > > > > type "0", and > > > > the media codecs are assigned the next codec ordinals=20 > > > > following those > > > > defined at the session level (codecs defined at=20 > the media=20 > > > > level via cmed > > > > attributes will be numbered following those=20 > defined on the=20 > > > > m=3Dline). > > > > Thus, the m=3D line and the following rtpmap and=20 > fmtp lines=20 > > > > are equivalent > > > > to: > > > > a=3Dcmed:6 PCMU G729 event > > > > a=3Dcptmap:0 8:100 > > > > a=3Dpcfg:0 m=3D6,7,8 p=3D0 ptm=3D0 > > > > Any pcfg: line at the media level may refer to=20 > the codecs=20 > > > > and transports > > > > defined by the current m=3D line. > > > > 12) This line provides the payload types for each cmed=20 > codec for=20 > > > > this media > > > > stream. The payload types are chosen, in this=20 > case, so that=20 > > > > the receiver > > > > can use them to tell which choices the answerer=20 > made if media=20 > > > > is received > > > > by the offeror before the answer arrives. > > > > 13) This line specifies an alternative media stream using SRTP. > > > > p=3D2 invokes the second transport protocol=20 > (RTP/SAVP) from the=20 > > > > ctrpr > > > > line. > > > > a=3D1 identifies the SDES crypto attribute > > > > ptm=3D1 identifies the payload map. I've used "1" to = identify > the > > > > entire line, but we could use numbers to=20 > identify each=20 > > > > mapping, > > > > as ptm=3D1,2,3 > > > > Note that there are no references to the cfmt or cenc=20 > > > > attributes - they're > > > > always attached to their respective media subtypes. > > > > > > > > Given an offer in the above form, a endpoint that doesn't=20 > > > > understand the capneg attributes will respond with the usual = m=3D=20 > > > > line and attributes. If the endpoint does understand=20 > capneg, it=20 > > > > is expected to reply with the > > > m=3Dline and > > > > the > > > > particular configuration it has chosen in an acfg > > > attribute. If it > > > > chooses the > > > > unencrypted media as described above with PCMU=20 > encoding, it might=20 > > > > follow the m=3D line with > > > > a=3Dacfg:0 m=3D6,8 p=3D0 ptm=3D0 > > > > In either case, the answering endpoint can include latent=20 > > > > configurations as well. > > > > > > > > In the simple case that the offeror doesn't want to offer any=20 > > > > latent media configurations, but does want to offer the SRTP=20 > > > > alternative, the SDP could be reduced to the following: > > > > ... (skipping over initial session lines) > > > > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard=20 > audio line > > > > 10) a=3Drtpmap:100 events > > > > 11) a=3Dfmt:100 0-15 > > > > 3) a=3Dctrpr:1 RTP/SAVP ;transport = profile > > > > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > > > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20| > > > > 1:32 > > > > 12) a=3Dcptmap:1 1:101 2:102 3:103 > > > > 13) a=3Dpcfg:1 m=3D1,3|2,3 p=3D1 a=3D1 ptm=3D1 ;(SRTP = option) > > > > > > > > Line 12, and the ptm=3D1 parameter in line 13, could be > > > eliminated if > > > > the > > > > offeror doesn't need to use the payload types to decide > > > early media > > > > can > > > > be rendered. > > > > > > > > My apologies for numbering errors, etc. Please reply with any=20 > > > > comments, corrections, additions, etc. > > > > -Bob > > > > ---------------------------------------------------- > > > > Bob Gilman rrg@avaya.com +1 303 538 3868 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > -- > > > Colin Perkins > > > http://csperkins.org/ > > > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jan 23 17:26:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9U5L-0004iK-Hk; Tue, 23 Jan 2007 17:25:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9U5L-0004iF-0q for mmusic@ietf.org; Tue, 23 Jan 2007 17:25:47 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9U5J-00083H-Kp for mmusic@ietf.org; Tue, 23 Jan 2007 17:25:47 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 23 Jan 2007 14:25:46 -0800 X-IronPort-AV: i="4.13,226,1167638400"; d="scan'208"; a="357496946:sNHT43786812" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0NMPiIg026512 for ; Tue, 23 Jan 2007 14:25:44 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0NMPiGo004284 for ; Tue, 23 Jan 2007 14:25:44 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 14:25:44 -0800 Received: from [128.107.101.2] ([128.107.101.2]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 14:25:44 -0800 Message-ID: <45B68B68.50400@cisco.com> Date: Tue, 23 Jan 2007 17:25:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jan 2007 22:25:44.0580 (UTC) FILETIME=[6C4BA440:01C73F3D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1235; t=1169591145; x=1170455145; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Cisco=20IPR=20claims=20on=20ICE,=20ICE-tcp |Sender:=20; bh=LIL/o7ULsa4TZcdxZmrJOul7osx03gCPbGl+74ste60=; b=Dn5/iWBE5Kkcg+1aP0mXx2HW9Su72ttumbNknc60cBH47VPiKOlJfqLkmfPZiFBJaYRyFkVy VE+PVvZ3KS3A3iXJYuSSU3ODFICVtSyt2KGesIpErunRj5BppbjnNpi3; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [MMUSIC] Cisco IPR claims on ICE, ICE-tcp X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I wanted to let the working group know about two IPR claims that Cisco just made on ICE and ICE-tcp: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=799 https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=798 These are actually just an update of a claim that was made on the very first version of ICE: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=112 which was submitted back in March of 2003. These claims are based on patent work done by other folks within Cisco, not myself. Indeed, the claims predate my employment there, and I only recently became aware of the claim made against the original ICE draft. The good news in all of this is that the original claim was RAND, but the newly updated one is of the "free-if-you-don't-sue-us" variety. Consequently, this is a huge improvement from what we had before. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 24 01:42:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9bpr-0001mM-S1; Wed, 24 Jan 2007 01:42:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9bpq-0001fd-6V for mmusic@ietf.org; Wed, 24 Jan 2007 01:42:18 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9bpo-0000w9-5c for mmusic@ietf.org; Wed, 24 Jan 2007 01:42:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations Date: Wed, 24 Jan 2007 08:42:10 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C043D873F@IsrExch01.israel.polycom.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0EDBCCC4@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Modified Proposal for Capability Negotiations Thread-Index: Acc+ytRKWN3SYnRSThW8MaTX2lPv8AACWV+QAAlq5CAACuaioAAXSH+g From: "Even, Roni" To: "Francois Audet" , "Stach, Thomas" , "Colin Perkins" , "Robert R. Gilman" X-Spam-Score: 0.1 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Francois, I am sorry if did not understand what I meant. My meaning was that the design team did not show any concerns about being able to finish in time. Roni > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, January 23, 2007 9:35 PM > To: Even, Roni; Stach, Thomas; Colin Perkins; Robert R. Gilman > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations >=20 > It was clearly agreed in San Diego AND in Montreal, that time was a huge > concern for best-effort SRTP. >=20 > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tuesday, January 23, 2007 06:29 > > To: Stach, Thomas; Colin Perkins; Robert R. Gilman > > Cc: mmusic@ietf.org > > Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations > > > > Hi, > > I am not sure what you mean about the media related work. > > Everything here is about media. > > Bob tried to address a way to support session level > > attributes so that they can be mapped to a PT in the media line. > > > > As for the timeline, I have not heard from the design team > > any concerns about time. The design team charter agreed in > > San Diego was to look at general solution. > > > > Being able to know the media capabilities of the remote side > > separately from the current negotiated media session is > > already a problem for changing codec in mid calls. So it is > > not only the issue of best-effort SRTP > > > > Roni Even > > > > > > > -----Original Message----- > > > From: Stach, Thomas [mailto:thomas.stach@siemens.com] > > > Sent: Tuesday, January 23, 2007 3:41 PM > > > To: Colin Perkins; Robert R. Gilman > > > Cc: mmusic@ietf.org > > > Subject: RE: [MMUSIC] Modified Proposal for Capability Negotiations > > > > > > Colin, Bob, > > > > > > I like the proposal as well since it clearly separates media > > > capabilities from the rest of the attributes in the > > a=3Dcapar: line that > > > Fleming's original proposal had defined as container for > > all attribute > > > lines. >=20 > > > > > > I also share the concern about time pressure. > > > So, what about moving the media related work to a separate document? > > > This would leave the basic negotiation framework, > > extensibility and a > > > solution for best effort SRTP for an initial step. > > > With this limited scope the document could be ready for a last call > > > quite soon. > > > > > > > > > Regards > > > Thomas > > > > > > > > > > -----Original Message----- > > > > From: Colin Perkins [mailto:csp@csperkins.org] > > > > Sent: Tuesday, January 23, 2007 9:45 AM > > > > To: Robert R. Gilman > > > > Cc: mmusic@ietf.org > > > > Subject: Re: [MMUSIC] Modified Proposal for Capability > > Negotiations > > > > > > > > I like this... but it's a big change to the SDP semantics. > > > > > > > > If we were starting from scratch, or weren't under such time > > > > pressure, it would definitely be worth serious configuration. > > > > For the > > > > current design team, where we need something ready for > > working group > > > > last call before the Prague meeting, I'm concerned that we need > > > > something closer to the current semantics. > > > > > > > > Colin > > > > > > > > > > > > > > > > On 17 Jan 2007, at 00:08, Robert R. Gilman wrote: > > > > > I've been playing with a means to make the cmed attribute line > > > > > independent of payload types, so it can be use at the session > > > > > level or media level to define media encodings. These can be > > > > > combined with transport protocols at the session or > > media levels, > > > > > and payload types at the > > > > media level. > > > > > Here's an approach that doesn't simply replicate the > > existing m- > > > > > line in a cmed attribute. It builds up the > > capabilities from mime > > > > > type/ subtypes, encoding parameters, and format > > parameters. Note > > > > > that the > > > > cenc and > > > > > cfmt > > > > > lines are tied directly into the subtypes listed in the > > cmed line > > > > > via the subtype ordinal; they are implicitly > > incorporated in the > > > > > pcfg attribute by reference to their subtype > > ordinal(s). One of > > > > > the > > > > advantages of > > > > > doing > > > > > this binding early is that an endpoint can offer a > > > > particular codec > > > > > with > > > > > different format parameters (e.g., G.729 and G.729B). > > > > > > > > > > Define/redefine the following new attributes: > > > > > > > > > > a=3Dcmed: > > > subtypes> > > > > > This line defines the set of codecs supported, > > and assigns > > > > > an ordinal to each codec. The codecs are > > referenced via their > > > > > ordinals in pcfg or acfg lines (via the m=3D > > parameter), and in > > > > > cenc and cfmt attributes. > > > > > If the first subtype ordinal is 's', say, the > > the first mime > > > > > subtype corresponds to "subtyp s", the next to > > "s+1", and > > > > > so on. > > > > > example: a=3Dcmed:1 PCMU G729 G729 iLBC events > > > > > ; PCMU=3D1, G729=3D2, G729=3D3 iLBC=3D4, = events=3D5 > > > > > > > > > > a=3Dctrpr: > protocols> > > > > > This line defines the transport > > protocols/profiles supported; > > > > > the pcfg line will refer to one of these via "p=3D" > > > > > example: a=3Dctrpr:1 RTP/AVP RTP/SAVP =3D> RTP/AVP=3D1 > > RTP/SAVP=3D2 > > > > > > > > > > a=3Dcenc: [/ > parameters>] > > > > > This line defines encoding attributes for the specified > > > > mime subtype. > > > > > It is effectively incorporated as part of the > > codec with the > > > > > specified > > > > > ordinal. > > > > > example: a=3Dcenc:4 8000 ;sample rate for iLBC > > > > > > > > > > a=3Dcfmt: > > > > > This line defines format parameters for the specified > > > > mime subtype. > > > > > It is effectively incorporated as part of the > > codec with the > > > > > specified > > > > > ordinal. > > > > > example: a=3Dcfmt:2 annexb:no ;codec 2 doesn't = support > > > > > comfort noise > > > > > > > > > > a=3Dcptmap: > number>: > > > > type> pairs> > > > > > This line defines the payload type(s) to be used with a > > > > particular > > > > > configuration and referenced via "ptm=3D". It > > may only be used by > > > > > offered configurations, not latent configurations. > > > > > example: a=3Dcptmap:1 2:99 3:100 ; maps G.729 to > > PT 99, iLBC > > > > > to PT 100 > > > > > > > > > > The remaining attributes (pcfg, acfg, capar) are defined as in > > > > > Flemming's draft: > > > > > . > > > > > > > > > > Then we might have an offer like the following. This announces > > > > > support for 4 audio codecs (G.711mu-law, G.729, G.729B, > > iLBC) and > > > > > in-band telephony events for DTMF and Flash. > > > > > ... (skipping over initial session lines) > > > > > 1) a=3Dcmed:1 audio PCMU G729 G729 iLBC events > > > > > 2) a=3Dcenc:4 8000 ;iLBC > > with 8K sample > > > > > rate > > > > > 3) a=3Dctrpr:1 RTP/AVP RTP/SAVP > > ;transport profiles > > > > > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > > > > > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20| > > > > > 1:32 > > > > > 5) a=3Dcfmt:2 annexb:no ;no comfort > > > > noise for > > > > > G.729 > > > > > 6) a=3Dcfmt:5 0-15,16 ;DTMF plus > > > > flash events > > > > > 7) a=3Dpcfg:1 m=3D3,5|4,5 t=3D1 ;a latent > > AVP capset > > > > > 8) a=3Dpcfg:2 m=3D3,5|4,5 t=3D2 a=3D1 ;a = latent SAVP > > capset > > > > > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard > > audio line > > > > > 10) a=3Drtpmap:100 events > > > > > 11) a=3Dfmt:100 0-15 > > > > > 12) a=3Dcptmap:1 1:101 2:102 5:103 > > > > > 13) a=3Dpcfg:3 m=3D1,5|2,5 p=3D2 a=3D1 ptm=3D1 = ;(SRTP option) > > > > > > > > > > Notes: > > > > > 1) This cmed line defines a set of audio codecs numbered 1-5. > > > > > 2) This cenc line defines adds encoding rate information > > > > for codec 3. > > > > > 3) This ctpr line defines two transport profiles numbered 1-2. > > > > > 4) This capar line defines an SDES crypto attribute. > > > > > 5) This cfmt line defines format parameters for codec 3 (G.729) > > > > > 6) This cfmt line defines the telephony event parameters for > > > > > "codec 5", > > > > > the telephony events. > > > > > 7) This pcfg line defines a latent AVP capset with any > > one of the > > > > > four > > > > > audio codecs plus DTMF telephony events. > > > > > 8) This pcfg line defines a latent SAVP capset with the same > > > > > combinations > > > > > of codecs/tlephony events. > > > > > 9) This is the conventional media line for audio with > > > > G.711mu-law, > > > > > G.729B, > > > > > and a dynamic payload type. > > > > > 10) "Traditional" SDP for backward compatibility. > > > > > 11) "Traditional" SDP for backward compatibility. > > > > > 9)-11) In case the receiver understands capability > > > > negotiation, but > > > > > wishes to > > > > > choose the AVT/RTP offer rather than encryption, > > we define > > > > > that the m=3D line defines "pcfg:0", "cptmap:0", transport > > > > > type "0", and > > > > > the media codecs are assigned the next codec ordinals > > > > > following those > > > > > defined at the session level (codecs defined at > > the media > > > > > level via cmed > > > > > attributes will be numbered following those > > defined on the > > > > > m=3Dline). > > > > > Thus, the m=3D line and the following rtpmap and > > fmtp lines > > > > > are equivalent > > > > > to: > > > > > a=3Dcmed:6 PCMU G729 event > > > > > a=3Dcptmap:0 8:100 > > > > > a=3Dpcfg:0 m=3D6,7,8 p=3D0 ptm=3D0 > > > > > Any pcfg: line at the media level may refer to > > the codecs > > > > > and transports > > > > > defined by the current m=3D line. > > > > > 12) This line provides the payload types for each cmed > > codec for > > > > > this media > > > > > stream. The payload types are chosen, in this > > case, so that > > > > > the receiver > > > > > can use them to tell which choices the answerer > > made if media > > > > > is received > > > > > by the offeror before the answer arrives. > > > > > 13) This line specifies an alternative media stream using SRTP. > > > > > p=3D2 invokes the second transport protocol > > (RTP/SAVP) from the > > > > > ctrpr > > > > > line. > > > > > a=3D1 identifies the SDES crypto attribute > > > > > ptm=3D1 identifies the payload map. I've used "1" to identify > > the > > > > > entire line, but we could use numbers to > > identify each > > > > > mapping, > > > > > as ptm=3D1,2,3 > > > > > Note that there are no references to the cfmt or cenc > > > > > attributes - they're > > > > > always attached to their respective media subtypes. > > > > > > > > > > Given an offer in the above form, a endpoint that doesn't > > > > > understand the capneg attributes will respond with the usual m=3D > > > > > line and attributes. If the endpoint does understand > > capneg, it > > > > > is expected to reply with the > > > > m=3Dline and > > > > > the > > > > > particular configuration it has chosen in an acfg > > > > attribute. If it > > > > > chooses the > > > > > unencrypted media as described above with PCMU > > encoding, it might > > > > > follow the m=3D line with > > > > > a=3Dacfg:0 m=3D6,8 p=3D0 ptm=3D0 > > > > > In either case, the answering endpoint can include latent > > > > > configurations as well. > > > > > > > > > > In the simple case that the offeror doesn't want to offer any > > > > > latent media configurations, but does want to offer the SRTP > > > > > alternative, the SDP could be reduced to the following: > > > > > ... (skipping over initial session lines) > > > > > 9) m=3Daudio 22222 AVT/RTP 0 18 100 ; standard > > audio line > > > > > 10) a=3Drtpmap:100 events > > > > > 11) a=3Dfmt:100 0-15 > > > > > 3) a=3Dctrpr:1 RTP/SAVP ;transport profile > > > > > 4) a=3Dcapar:1 a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_32 > > > > > > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20| > > > > > 1:32 > > > > > 12) a=3Dcptmap:1 1:101 2:102 3:103 > > > > > 13) a=3Dpcfg:1 m=3D1,3|2,3 p=3D1 a=3D1 ptm=3D1 = ;(SRTP option) > > > > > > > > > > Line 12, and the ptm=3D1 parameter in line 13, could be > > > > eliminated if > > > > > the > > > > > offeror doesn't need to use the payload types to decide > > > > early media > > > > > can > > > > > be rendered. > > > > > > > > > > My apologies for numbering errors, etc. Please reply with any > > > > > comments, corrections, additions, etc. > > > > > -Bob > > > > > ---------------------------------------------------- > > > > > Bob Gilman rrg@avaya.com +1 303 538 3868 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > mmusic mailing list > > > > > mmusic@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > -- > > > > Colin Perkins > > > > http://csperkins.org/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > mmusic mailing list > > > > mmusic@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 24 03:07:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9dA7-0004Pd-DR; Wed, 24 Jan 2007 03:07:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9dA6-0004P6-7B for mmusic@ietf.org; Wed, 24 Jan 2007 03:07:18 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9d9e-0006oO-GQ for mmusic@ietf.org; Wed, 24 Jan 2007 03:06:52 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62795 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1H9d9d-0006r9-RR; Wed, 24 Jan 2007 08:06:49 +0000 In-Reply-To: <45B68B68.50400@cisco.com> References: <45B68B68.50400@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Cisco IPR claims on ICE, ICE-tcp Date: Wed, 24 Jan 2007 08:06:47 +0000 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 23 Jan 2007, at 22:25, Jonathan Rosenberg wrote: > I wanted to let the working group know about two IPR claims that > Cisco just made on ICE and ICE-tcp: > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=799 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=798 > > These are actually just an update of a claim that was made on the > very first version of ICE: > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=112 > > which was submitted back in March of 2003. I also note that Tandberg has previously notified the IETF of IPR on ICE: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=727 -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 25 06:32:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA2ov-0006ET-EF; Thu, 25 Jan 2007 06:31:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA2ot-0006EE-Ot for mmusic@ietf.org; Thu, 25 Jan 2007 06:31:07 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA2on-0002kd-RC for mmusic@ietf.org; Thu, 25 Jan 2007 06:31:07 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2559F548142; Thu, 25 Jan 2007 12:30:53 +0100 (CET) X-AuditID: c1b4fb3c-aefc6bb0000007de-d5-45b894edddf6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 14693520001; Thu, 25 Jan 2007 12:30:53 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 12:30:52 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 12:30:51 +0100 Received: from [131.160.36.66] (EH3I2003TGFCPET-131160036066.lmf.ericsson.se [131.160.36.66]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 21345236E; Thu, 25 Jan 2007 13:30:51 +0200 (EET) Message-ID: <45B894EA.3070207@ericsson.com> Date: Thu, 25 Jan 2007 13:30:50 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Flemming Andreasen References: <45260230.2090300@ericsson.com> <455100C0.1030201@cisco.com> In-Reply-To: <455100C0.1030201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2007 11:30:51.0283 (UTC) FILETIME=[447DD630:01C74074] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "James M. Polk" , mmusic , sdhesika@cisco.com Subject: [MMUSIC] Re: SDP QoS Mechanism Identification X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Flemming, thanks for your comments. I intend to add the following section in order to address your last comment: 4.4. Subsequent Offer/answer Exchanges If, during an ongoing session that uses QoS, an endpoint receives a subsequent offer that does not contain the 'qos-mech-send' and 'qos- mech-recv' attributes, the endpoints SHOULD continue using the same QoS mechanism or mechanisms used up to that moment. Would that work for you? Thanks, Gonzalo Flemming Andreasen wrote: > Thanks for the update - it addresses my previous concerns. The only > other thing you may want to consider is to add a section for subsequent > offer/answer exchanges - I presume you will simply do what that O/A > exchange now specifies, and in the absence of parameter inclusion in > this subsequent exchange, it is up to the local implementation what to > do (e.g. try the mechanisms in the previously negotiated order or a > completely different order, including using mechanisms not previously > specified). > > -- Flemming > > > Gonzalo Camarillo wrote: > > > Hi, > > > > last time we presented this draft, Flemming had some concerns about its > > semantics. We have just submitted a new revision of the draft that tries > > and addresses Flemming's concerns. Now the result of the offer/answer > > exchange is a hint of which QoS mechanisms can be used because they are > > supported by the remote endpoint. However, it does not keep the > > endpoints from trying different mechanisms that may not be supported by > > the endpoint but may be supported by the network (e.g., thru an RSVP > > proxy). > > > > Until the draft appears in the official archives, you can fetch it from: > > > > > http://users.piuha.net/gonzalo/temp/draft-polk-mmusic-qos-mechanism-identification-02.txt > > > > > > Let us know if this revision addresses your concerns. > > > > Cheers, > > > > Gonzalo > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jan 25 12:15:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8Bb-00084t-B6; Thu, 25 Jan 2007 12:14:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8BZ-00084n-Em for mmusic@ietf.org; Thu, 25 Jan 2007 12:14:53 -0500 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound1-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8BX-0002AL-Sn for mmusic@ietf.org; Thu, 25 Jan 2007 12:14:53 -0500 Received: from outbound1-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-cpk-R.bigfish.com (Postfix) with ESMTP id 927371ED5425 for ; Thu, 25 Jan 2007 17:14:51 +0000 (UTC) Received: from mail129-cpk-R.bigfish.com (unknown [192.168.21.3]) by outbound1-cpk.bigfish.com (Postfix) with ESMTP id 8B80F1ED5408 for ; Thu, 25 Jan 2007 17:14:51 +0000 (UTC) Received: from mail129-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail129-cpk-R.bigfish.com (Postfix) with ESMTP id 7FB845FA1E9 for ; Thu, 25 Jan 2007 17:14:51 +0000 (UTC) X-BigFish: V Received: by mail129-cpk (MessageSwitch) id 1169745291427169_8722; Thu, 25 Jan 2007 17:14:51 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail129-cpk.bigfish.com (Postfix) with ESMTP id 386735FAC10 for ; Thu, 25 Jan 2007 17:14:51 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id l0PHEovQ021323 for ; Thu, 25 Jan 2007 11:14:50 -0600 (CST) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0PHEm6u008997 for ; Thu, 25 Jan 2007 11:14:50 -0600 (CST) Received: from PLSWB06C.ad.sprint.com ([208.10.70.231]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 11:14:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Jan 2007 11:14:43 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Offer Answer / SDP a=sdplang was [Sip-implementors] Accept-Language Header Thread-Index: AcdAl8p3afdkRZCaQr6p8AUBon5RpAADG3tw From: "Manroa, Arun [CTO]" To: X-OriginalArrivalTime: 25 Jan 2007 17:14:45.0564 (UTC) FILETIME=[4F7B3FC0:01C740A4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Subject: [MMUSIC] Offer Answer / SDP a=sdplang was [Sip-implementors] Accept-Language Header X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0191273374==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0191273374== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C740A4.4F77D295" This is a multi-part message in MIME format. ------_=_NextPart_001_01C740A4.4F77D295 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am trying to understand how to negotiate human language (audio output) = preferences using SDP or SIP headers; RFC 2327 defines a=3Dsdplang at the media level and so does the HTTP = /SIP specs at the signaling level (Accept-Language Header). RFC 3264 = offer answer does not delve into this. Consider the following use case, where User A is an "English" language = speaker using say G711 codec and want to conference in only certain = members of a group call that not only support the G711 codec, but also = understand the "English" language. =20 Assume following are the users characteristics: User A (English), Codec G711 User B (English), Codec G711 User C (Spanish), Codec G711 User D (English), Codec AMR User E (English, Spanish), Codec G711 =20 So in this use case User A wants to connect to User B & E only, since = the language and codec both match.(English, G711) =20 RFC 3261 20.3 Accept-Language says.. The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. The text says session descriptions but I not clear how that is handled = in offer answer. Does the "Conferencing Server" send out INVITES with = Accept-Language: en (with SDP Offer) to all participants and user C is = going to send a 415 indicating Spanish only, and B & E are going to = respond with a 200 OK (SDP Ans). Of course User D is going to reject the = SDP Offer with a 415 since it does not support G711. =20 Also the Accept-Language in REGISTER is used by the Registrar for = generating a response, which I think is a different semantic meaning, = maybe using RFC 3840 the users could register the appropriate language = in the contact header, that way there is no need to send the INVITES to = them etc. =20 Could someone please clarify? =20 Thanks, Arun ------_=_NextPart_001_01C740A4.4F77D295 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Offer Answer / SDP a=3Dsdplang was [Sip-implementors] = Accept-Language Header

Hi,

I = am trying to understand how to negotiate human language (audio output) = preferences using SDP or SIP headers;

RFC 2327 defines a=3Dsdplang at the media level and so does the = HTTP /SIP specs at the = signaling level (Accept-Language Header). RFC 3264 offer answer does not = delve into this.

Consider the following use case, where User A is an = "English" language speaker using say G711 codec and want to = conference in only certain members of a group call that not only support the G711 codec, but = also understand the "English" language.

 

Assume following are the users characteristics:

User A (English), Codec G711

User B (English), Codec G711

User C (Spanish), Codec G711

User D (English), Codec AMR

User E (English, Spanish), Codec G711

 

So = in this use case User A wants to connect to User B & E only, since = the language and codec both match.(English, G711)

 

RFC 3261 20.3 Accept-Language says..

        =         The Accept-Language header field is used in = requests to indicate = the

        =            preferred languages for reason = phrases, session descriptions, or

        =            status responses carried as message = bodies in the response.

The text says session descriptions but I not clear how that is = handled in offer answer. Does the "Conferencing Server" send = out INVITES with Accept-Language: en (with SDP Offer) to all = participants and user C is going to send a 415 indicating Spanish = only, and B & E are going to respond with a 200 OK = (SDP Ans). Of course User D is going to reject the SDP Offer with a 415 = since it does not support G711.

 

Also the Accept-Language in REGISTER is used by the Registrar for = generating a response, which I think is a different semantic meaning, maybe using RFC = 3840 the users could register the appropriate language in the contact = header, that way there is no need to send the INVITES to them = etc.

 

Could someone please clarify?

 

Thanks,

Arun

------_=_NextPart_001_01C740A4.4F77D295-- --===============0191273374== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0191273374==-- From mmusic-bounces@ietf.org Thu Jan 25 19:19:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEns-0006Qt-FM; Thu, 25 Jan 2007 19:18:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAEnr-0006Qo-Gn for mmusic@ietf.org; Thu, 25 Jan 2007 19:18:51 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAEnn-00042e-4X for mmusic@ietf.org; Thu, 25 Jan 2007 19:18:51 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 25 Jan 2007 16:18:47 -0800 X-IronPort-AV: i="4.13,239,1167638400"; d="scan'208"; a="357914944:sNHT52011414" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0Q0IiCt017507; Thu, 25 Jan 2007 16:18:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0Q0IiDk021326; Thu, 25 Jan 2007 16:18:44 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 16:18:44 -0800 Received: from [128.107.97.204] ([128.107.97.204]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 16:18:44 -0800 Message-ID: <45B948E3.7050402@cisco.com> Date: Thu, 25 Jan 2007 19:18:43 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Gonzalo Camarillo References: <45260230.2090300@ericsson.com> <455100C0.1030201@cisco.com> <45B894EA.3070207@ericsson.com> In-Reply-To: <45B894EA.3070207@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 00:18:44.0076 (UTC) FILETIME=[8A0422C0:01C740DF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2146; t=1169770724; x=1170634724; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20SDP=20QoS=20Mechanism=20Identification |Sender:=20; bh=kert2KHlCyVEj38fJPRpStJ/psxHDMa/5EJrQU8qoEc=; b=BOzk3300uNZT0862b/aH4oRb39OULl+WiYpJlSuFfY1erYo2xkZHjgTDzcVRaUJGtsc0fdof H7xYfZvc2/Ebo2SGdXtUzY7DriMj3QZzh86twCwNlhIH7LLhfUKxcvlt; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "James M. Polk" , mmusic , sdhesika@cisco.com Subject: [MMUSIC] Re: SDP QoS Mechanism Identification X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Gonzalo Camarillo wrote: > Hi Flemming, > > thanks for your comments. I intend to add the following section in > order to address your last comment: > > 4.4. Subsequent Offer/answer Exchanges > > If, during an ongoing session that uses QoS, an endpoint receives a > subsequent offer that does not contain the 'qos-mech-send' and 'qos- > mech-recv' attributes, the endpoints SHOULD continue using the same > QoS mechanism or mechanisms used up to that moment. > > Would that work for you? Sounds good. Thanks -- Flemming > > Thanks, > > Gonzalo > > > Flemming Andreasen wrote: >> Thanks for the update - it addresses my previous concerns. The only >> other thing you may want to consider is to add a section for subsequent >> offer/answer exchanges - I presume you will simply do what that O/A >> exchange now specifies, and in the absence of parameter inclusion in >> this subsequent exchange, it is up to the local implementation what to >> do (e.g. try the mechanisms in the previously negotiated order or a >> completely different order, including using mechanisms not previously >> specified). >> >> -- Flemming >> >> >> Gonzalo Camarillo wrote: >> >> > Hi, >> > >> > last time we presented this draft, Flemming had some concerns >> about its >> > semantics. We have just submitted a new revision of the draft that >> tries >> > and addresses Flemming's concerns. Now the result of the offer/answer >> > exchange is a hint of which QoS mechanisms can be used because >> they are >> > supported by the remote endpoint. However, it does not keep the >> > endpoints from trying different mechanisms that may not be >> supported by >> > the endpoint but may be supported by the network (e.g., thru an RSVP >> > proxy). >> > >> > Until the draft appears in the official archives, you can fetch it >> from: >> > >> > >> http://users.piuha.net/gonzalo/temp/draft-polk-mmusic-qos-mechanism-identification-02.txt >> >> > >> > >> > Let us know if this revision addresses your concerns. >> > >> > Cheers, >> > >> > Gonzalo >> > >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 26 11:15:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATil-00037Q-Ed; Fri, 26 Jan 2007 11:14:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATij-00034v-VT for mmusic@ietf.org; Fri, 26 Jan 2007 11:14:33 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATii-0005V8-Ig for mmusic@ietf.org; Fri, 26 Jan 2007 11:14:33 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l0QGERRa009484; Fri, 26 Jan 2007 09:14:29 -0700 (MST) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Fri, 26 Jan 2007 09:14:27 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: SDP QoS Mechanism Identification Date: Fri, 26 Jan 2007 09:14:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: SDP QoS Mechanism Identification Thread-Index: AcdAdN6Rz+2yqPkmSIqZMcXKE3HflQA7LPCw From: "Jean-Francois Mule" To: "Gonzalo Camarillo" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Gonzalo, The draft should make it clear that 'qos-mech-send' and 'qos-mech-recv' session and media-level attributes are not inter-dependent: one could be used without the other.=20 Gonzalo Camarillo wrote: > 4.4. Subsequent Offer/answer Exchanges > > If, during an ongoing session that uses QoS, an endpoint receives a > subsequent offer that does not contain the 'qos-mech-send' and 'qos- > mech-recv' attributes, the endpoints SHOULD continue using the same > QoS mechanism or mechanisms used up to that moment. Here are a few questions/comments on this new requirement text. > > If, during an ongoing session that uses QoS, an endpoint receives a ^^^^^^^ ^^^^^^^^^^^^^ s/ongoing/established? I thought about active but you could have an established session where the media is not active in one or both directions so that may be confusing. "that uses QoS" implies that QoS was successfully negotiated, this is misleading as this requirement may apply to sessions where no QoS is in effectively use but for which a QoS negotiation was attempted (and potentially failed). What qualifies this session is not that QoS is in use, but rather that a QoS mechanism was attempted in the first O/A due to the token lists. Suggest expanding the text to say something like: during an established session for which the QoS mechanism(s) were previously exchanged, ... with better wording. > subsequent offer that does not contain the 'qos-mech-send' and 'qos- > mech-recv' attributes,=20 Given that those 2 attributes are not necessarily linked or inter-dependent, it suffices that only one attribute is left out of the subsequent offer for this requirement to be applicable. If this is true, then this sentence should be modified (at a minimum, say "or", or better, reword to take into account the potential asymmetries. > the endpoints SHOULD continue using the same > QoS mechanism or mechanisms used up to that moment. You may consider adding a note that QoS re-negotiations using the same QoS mechanisms might however be required. Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 26 16:35:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYiM-0006q1-9Q; Fri, 26 Jan 2007 16:34:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUDr-0004Ky-RL for mmusic@ietf.org; Fri, 26 Jan 2007 11:46:43 -0500 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUDq-0002YO-Cq for mmusic@ietf.org; Fri, 26 Jan 2007 11:46:43 -0500 Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id l0QGkO7c026175 for ; Fri, 26 Jan 2007 17:46:24 +0100 From: Annie.Bourgeais@alcatel-lucent.fr To: mmusic@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Fri, 26 Jan 2007 17:46:23 +0100 X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 01/26/2007 17:46:24 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.2 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a X-Mailman-Approved-At: Fri, 26 Jan 2007 16:34:29 -0500 Subject: [MMUSIC] help - question on SDP negotiation based on RFC 3264 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I have 2 specific questions about the SDP media negotiation : I am not = sure to have a clear interpretation on some specific paragraph of the RFC 32= 64, which describes the media renegotiation and the "on-hold" procedure....= Thanks in advance for your help. Question #1 The RFC 3264 specifies =A76.1 : If a stream is offered as sendonly, the corresponding stream MUST be= marked as recvonly or inactive in the answer. If a media stream is listed as recvonly in the offer, the answer MUST be marked as sendonly or inactive in the answer. If an offered media stream is listed as sendrecv (or if there is no direction attribute at the media or session level, in which case the stream is sendrecv by default), the corresponding stream in the answer MAY be marked as sendonly, recvonly, sendrecv, or inactive. If an offered media stream is listed as inactive, it MUST be marked as inactive in the answer. The RFC 3264 specifies =A78.4 : Putting a Unicast Media Stream on Hold If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more unicast media streams, a party offers the other an updated SDP. If the stream to be placed on hold was previously a sendrecv media stream, it is placed on hold by marking it as sendonly. If the stream to be placed on hold was previously a recvonly media stream, it is placed on hold by marking it inactive. This means that a stream is placed "on hold" separately in each direction. Each stream is placed "on hold" independently. The recipient of an offer for a stream on-hold SHOULD NOT automatically return an answer with the corresponding stream on hold. An SDP with= all streams "on hold" is referred to as held SDP. Taking into account the follwoing basic scenario, where A user calls B user, and where a SIP session is successfully established. Then, A use= r chooses to put B on-hold, and sends a new offer with all the media set = to 'inactive'. B users generates his answer : -> Based on =A76.1(RFC 3264), Ithink that B user MUST generate an answe= r with all the media set to inactive, -> Based on =A78.4, Isuppose that B CAN generate an answer without all = the media set to inactive. What should be the right behaviour for B when generating his offer? Question #2 Moreover, the examples given in the RFC 4317 (=A73.2 listed below) seem= to show that an answer following a consecutive offer putting a stream on h= old can be constructed with identical SDP to the previous offer/answer exchanged. Is it really possible as it does not seem to be consistent w= ith the RFC 3264? Can you please clarifies Alice's behaviour below? Hold with Two Streams In this example, two audio streams have been established in the firs= t offer/answer exchange. In this second offer/answer exchange, one of= the audio streams is placed on hold. Alice offers two media streams= , a bidirectional audio stream and a send-only telephone event stream.= Bob accepts both streams. Bob then puts Alice's audio stream on hol= d but not the tone stream. Alice responds with identical SDP to the initial offer. [Offer] v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D=00 c=3DIN IP4 host.atlanta.example.com t=3D0 0 m=3Daudio 49170 RTP/AVP 0 97 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:97 iLBC/8000 m=3Daudio 49172 RTP/AVP 98 a=3Drtpmap:98 telephone-event/8000 a=3Dsendonly [Answer] v=3D0 o=3Dbob 2808844564 2808844564 IN IP4 host.biloxi.example.com s=3D=00 c=3DIN IP4 host.biloxi.example.com t=3D0 0 m=3Daudio 49172 RTP/AVP 97 a=3Drtpmap:97 iLBC/8000 m=3Daudio 49174 RTP/AVP 98 a=3Drtpmap:98 telephone-event/8000 a=3Drecvonly [Second-Offer] (From Bob) v=3D0 o=3Dbob 2808844564 2808844565 IN IP4 host.biloxi.example.com s=3D=00 c=3DIN IP4 host.biloxi.example.com t=3D0 0 m=3Daudio 49172 RTP/AVP 97 a=3Drtpmap:97 iLBC/8000 a=3Dsendonly m=3Daudio 49174 RTP/AVP 98 a=3Drtpmap:98 telephone-event/8000 a=3Drecvonly [Second-Answer] v=3D0 o=3Dalice 2890844526 2890844527 IN IP4 host.atlanta.example.com s=3D=00 c=3DIN IP4 host.atlanta.example.com t=3D0 0 m=3Daudio 49170 RTP/AVP 0 97 a=3Drtpmap:0 PCMU/8000 a=3Drtpmap:97 iLBC/8000 m=3Daudio 49172 RTP/AVP 98 a=3Drtpmap:98 telephone-event/8000 a=3Dsendonly = _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jan 26 18:53:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAasV-0004AO-CT; Fri, 26 Jan 2007 18:53:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAasT-0004AD-So for mmusic@ietf.org; Fri, 26 Jan 2007 18:53:05 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAasR-0008CP-C9 for mmusic@ietf.org; Fri, 26 Jan 2007 18:53:05 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2007 18:53:03 -0500 X-IronPort-AV: i="4.13,244,1167627600"; d="scan'208"; a="112586084:sNHT56344280" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0QNr3pl003275; Fri, 26 Jan 2007 18:53:03 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0QNr2VT000376; Fri, 26 Jan 2007 18:53:03 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 18:53:02 -0500 Received: from [161.44.183.166] ([161.44.183.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 18:53:02 -0500 Message-ID: <45BA945E.3020708@cisco.com> Date: Fri, 26 Jan 2007 18:53:02 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Annie.Bourgeais@alcatel-lucent.fr Subject: Re: [MMUSIC] help - question on SDP negotiation based on RFC 3264 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Jan 2007 23:53:02.0258 (UTC) FILETIME=[1D6F2120:01C741A5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5968; t=1169855583; x=1170719583; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20help=20-=20question=20on=20SDP=20negotiati on=20based=20on=20RFC=203264 |Sender:=20 |To:=20Annie.Bourgeais@alcatel-lucent.fr; bh=AA3BoHJDQfqTE3KvshEZJt0qcbyyT2fPSes9jKfGR0k=; b=HEFj9MnLQV5qi24N8bm4t5sZDhyz5kuGWUjXpzv29QrNMFggy7mcR9NowMSHBDrBobr1LOqX WZfw0e4RmixbNTx04qKyTR0jOyMGYwg4TdkrzIx0EliWRU1z7MFh7OyG; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Alan Johnston , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Annie, comments inline. [Alan - please not. Do you agree this is a bug in 4317?] Thanks, Paul Annie.Bourgeais@alcatel-lucent.fr wrote: > I have 2 specific questions about the SDP media negotiation : I am not sure > to have a clear interpretation on some specific paragraph of the RFC 3264, > which describes the media renegotiation and the "on-hold" procedure.... > Thanks in advance for your help. > > > Question #1 > > The RFC 3264 specifies §6.1 : > > If a stream is offered as sendonly, the corresponding stream MUST be > marked as recvonly or inactive in the answer. If a media stream is > listed as recvonly in the offer, the answer MUST be marked as > sendonly or inactive in the answer. If an offered media stream is > listed as sendrecv (or if there is no direction attribute at the > media or session level, in which case the stream is sendrecv by > default), the corresponding stream in the answer MAY be marked as > sendonly, recvonly, sendrecv, or inactive. If an offered media > stream is listed as inactive, it MUST be marked as inactive in the > answer. > > The RFC 3264 specifies §8.4 : > Putting a Unicast Media Stream on Hold > > If a party in a call wants to put the other party "on hold", i.e., > request that it temporarily stops sending one or more unicast media > streams, a party offers the other an updated SDP. > > If the stream to be placed on hold was previously a sendrecv media > stream, it is placed on hold by marking it as sendonly. If the > stream to be placed on hold was previously a recvonly media stream, > it is placed on hold by marking it inactive. > > This means that a stream is placed "on hold" separately in each > direction. Each stream is placed "on hold" independently. The > recipient of an offer for a stream on-hold SHOULD NOT automatically > return an answer with the corresponding stream on hold. An SDP with > all streams "on hold" is referred to as held SDP. > > > Taking into account the follwoing basic scenario, where A user calls B > user, and where a SIP session is successfully established. Then, A user > chooses to put B on-hold, and sends a new offer with all the media set to > 'inactive'. B users generates his answer : > > -> Based on §6.1(RFC 3264), Ithink that B user MUST generate an answer with > all the media set to inactive, > -> Based on §8.4, Isuppose that B CAN generate an answer without all the > media set to inactive. > > What should be the right behaviour for B when generating his offer? B must answer with inactive. I'm not especially happy with how this was described in the rfc, but it has been discussed ad nauseum elsewhere. The use of sendonly to signify HOLD assumes that the holder still wants to transmit (presumably MOH). But often that is not the case. A holder that doesn't want to send anything should be able to offer inactive. The answer to that must still be inactive - it is in effect an acknowledgment that it was understood. BUT, that doesn't mean the B *wants* hold, only that it accepts it. If B subsequently generates a new offer, it can *offer* whatever it *wants*, which typically will be sendonly. Then if A still wants to be on hold (probably yes), then it can respond with inactive or sendonly. > Question #2 > > Moreover, the examples given in the RFC 4317 (§3.2 listed below) seem to > show that an answer following a consecutive offer putting a stream on hold > can be constructed with identical SDP to the previous offer/answer > exchanged. Is it really possible as it does not seem to be consistent with > the RFC 3264? Can you please clarifies Alice's behaviour below? I hadn't noticed this before. I believe the example is in error. The second answer is incorrect. The first stream in the second answer should be either recvonly or inactive. Looks like a bug to me. Copying the author of that rfc. Paul > Hold with Two Streams > > In this example, two audio streams have been established in the first > offer/answer exchange. In this second offer/answer exchange, one of > the audio streams is placed on hold. Alice offers two media streams, > a bidirectional audio stream and a send-only telephone event stream. > Bob accepts both streams. Bob then puts Alice's audio stream on hold > but not the tone stream. Alice responds with identical SDP to the > initial offer. > > [Offer] > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s= t=0 0 > m=audio 49170 RTP/AVP 0 97 > a=rtpmap:0 PCMU/8000 > a=rtpmap:97 iLBC/8000 > m=audio 49172 RTP/AVP 98 > a=rtpmap:98 telephone-event/8000 > a=sendonly > > [Answer] > > v=0 > o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com > s= t=0 0 > m=audio 49172 RTP/AVP 97 > a=rtpmap:97 iLBC/8000 > m=audio 49174 RTP/AVP 98 > a=rtpmap:98 telephone-event/8000 > a=recvonly > > > [Second-Offer] (From Bob) > > v=0 > o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com > s= t=0 0 > m=audio 49172 RTP/AVP 97 > a=rtpmap:97 iLBC/8000 > a=sendonly > m=audio 49174 RTP/AVP 98 > a=rtpmap:98 telephone-event/8000 > a=recvonly > > [Second-Answer] > > v=0 > o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com > s= t=0 0 > m=audio 49170 RTP/AVP 0 97 > a=rtpmap:0 PCMU/8000 > a=rtpmap:97 iLBC/8000 > m=audio 49172 RTP/AVP 98 > a=rtpmap:98 telephone-event/8000 > a=sendonly > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jan 28 10:16:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBBjw-0001cD-2Q; Sun, 28 Jan 2007 10:14:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBBjv-0001c5-6E for mmusic@ietf.org; Sun, 28 Jan 2007 10:14:43 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBBjt-0001Y1-Nb for mmusic@ietf.org; Sun, 28 Jan 2007 10:14:43 -0500 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62928 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HBBjs-0000JC-V6; Sun, 28 Jan 2007 15:14:41 +0000 In-Reply-To: <72963DDDF17D7949ABD18DC5DA58E77001AC8E5D@MCHP7R5A.ww002.siemens.net> References: <72963DDDF17D7949ABD18DC5DA58E77001AC8E5D@MCHP7R5A.ww002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6D9940BA-D784-4074-BB4E-080DC05378C8@csperkins.org> Content-Transfer-Encoding: quoted-printable From: Colin Perkins Subject: Re: [MMUSIC] New ID, related to media stream dependencies Date: Sun, 28 Jan 2007 15:14:42 +0000 To: "Schmidt, Christian" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: MMusic , Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Christian, Can you comment on how this relates to the work on signalling for =20 layered codecs? draft-schierl-mmusic-layered-codec-02.txt Colin On 19 Jan 2007, at 12:03, Schmidt, Christian wrote: > Dear editor, > > we would like to submit a new Internet Draft related to work in the > MMUSIC Working Group (although it is not an official product of =20 > the WG). > > <> > > Abstract: > The Session Description Protocol (SDP) was intended for describing > multimedia sessions for the purposes of session announcement, session > invitation, and other forms of multimedia session initiation. > Together with Offer/Answer model it defines a mechanism, how two > entities can reach a common view of a multimedia session between > them. > > In certain cases, there are dependencies between media streams, for > example a text stream for subtitling make sense only together with a > video stream. To avoid senseless connections, the SDP mechanism can > be extended with a new Session Description Protocol (SDP) media-level > attribute: "dependency". The "dependency" attribute allows the > offerer to define dependencies of media streams. The updated offer/ > answer mechanism used with new "dependency" attribute can be used > furthermore, that in a multi-party SIP session all participants share > at least one common media type. > > Mit freundlichen Gr=FC=DFen > Christian Schmidt > > Siemens Networks GmbH & Co. KG > St.-Martin-Str. 76 > 81541 M=FCnchen, Germany > Tel.: +49 89 636-75192 > Fax: +49 89 636-75577 > christian-schmidt@siemens.com > > Siemens Networks GmbH & Co. KG > Gesch=E4ftsf=FChrer: Joachim Malterer, Roland Meinzer, Christian =20 > Unterberger > Sitz der Gesellschaft: M=FCnchen > Registergericht: M=FCnchen, HRA 88537 > WEEE-Reg.-Nr. DE 52984304 > Pers=F6nlich haftende Gesellschafterin: Siemens Networks Management = GmbH > Sitz der Gesellschaft: M=FCnchen > Registergericht: M=FCnchen, HRB 163416 > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jan 28 15:06:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBGHI-00008g-RK; Sun, 28 Jan 2007 15:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBGEk-0007PU-4C for mmusic@ietf.org; Sun, 28 Jan 2007 15:02:50 -0500 Received: from nucleon.liquidweb.com ([64.91.224.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBGEi-000748-TB for mmusic@ietf.org; Sun, 28 Jan 2007 15:02:50 -0500 Received: from c-69-136-253-7.hsd1.de.comcast.net ([69.136.253.7]:39388 helo=Oana2) by nucleon.liquidweb.com with esmtpa (Exim 4.52) id 1HBGEW-0006dg-BX for mmusic@ietf.org; Sun, 28 Jan 2007 15:02:36 -0500 Message-ID: <15397035.1170014444796.JavaMail.Onitza@Oana2> Date: Sun, 28 Jan 2007 15:00:44 -0500 (EST) From: Call for Papers To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nucleon.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - iaria.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Sun, 28 Jan 2007 15:05:26 -0500 Subject: [MMUSIC] ICIMP 2007 || The Second International Conference on Internet Monitoring and Protection || Silicon Valley, July 1-6, 2007 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Invitation, Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS The Second International Conference on Internet Monitoring and Protection ICIMP 2007 Date: July 1-6, 2007 Place: Silicon Valley, California Site: http://www.iaria.org/conferences2007/ICIMP07.html Submission: http://www.iaria.org/conferences2007/SubmitICIMP07.html Important deadlines: Full paper submission, February 20, 2007 Author notification, March 10, 2007 Registration and Camera ready, March 25, 2007 also featuring the workshops: - SYVUL 2007: The First International Workshop on Systems Vulnerabilities http://www.iaria.org/conferences2007/SYVUL.html - SYDIA 2007: The First International Workshop on Systems Diagnosis http://www.iaria.org/conferences2007/SYDIA.html - CYBER-FRAUD 2007: The First International Workshop on Cyber-Fraud http://www.iaria.org/conferences2007/CYBERFRAUD.html ICIMP 2007 Tracks (details in the CfP on site) TRASI: Internet traffic surveillance and interception IPERF: Internet performance RTSEC: Security for Internet-based real-time systems DISAS: Disaster prevention and recovery EMERG: Networks and applications emergency services MONIT: End-to-end sampling, measurement, and monitoring REPORT: Experiences & lessons learnt in securing networks and applications USSAF: User safety, privacy, and protection over Interne ================================================ ICIMP 2007 Chairs Yann Berthier, CSRRT-LU, Canada Liwen He, BT, UK _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jan 28 16:28:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBHZE-0005UG-Rs; Sun, 28 Jan 2007 16:28:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBHZD-0005U6-Gp for mmusic@ietf.org; Sun, 28 Jan 2007 16:28:03 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBHZC-0003Cl-3s for mmusic@ietf.org; Sun, 28 Jan 2007 16:28:03 -0500 Received: from 24-107-197-43.dhcp.stls.mo.charter.com ([24.107.197.43] helo=[192.168.0.40]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HBHZA-000AAR-Kz; Sun, 28 Jan 2007 16:28:00 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.43 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <45BD155F.8000909@sipstation.com> Date: Sun, 28 Jan 2007 15:27:59 -0600 From: Alan Johnston User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] help - question on SDP negotiation based on RFC 3264 References: <45BA945E.3020708@cisco.com> In-Reply-To: <45BA945E.3020708@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: mmusic@ietf.org, Robert Sparks , Annie.Bourgeais@alcatel-lucent.fr X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I agree that the second offer/answer exchange in 3.2 of RFC 4317 appears to be wrong. I can't recall right now what we were trying to show in it. I'm adding Robert in case he recalls the purpose of the scenario. The text says that the answer has the same SDP as the initial offer, yet the version is incremented. I think it should be: [Second-Offer] (From Bob) v=0 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com s= t=0 0 m=audio 49172 RTP/AVP 97 a=rtpmap:97 iLBC/8000 a=sendonly m=audio 49174 RTP/AVP 98 a=rtpmap:98 telephone-event/8000 a=recvonly [Second-Answer] v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000 a=recvonly m=audio 49172 RTP/AVP 98 a=rtpmap:98 telephone-event/8000 a=sendonly Thanks, Alan Paul Kyzivat wrote: > Annie, > > comments inline. > > [Alan - please not. Do you agree this is a bug in 4317?] > > Thanks, > Paul > > Annie.Bourgeais@alcatel-lucent.fr wrote: >> I have 2 specific questions about the SDP media negotiation : I am >> not sure >> to have a clear interpretation on some specific paragraph of the RFC >> 3264, >> which describes the media renegotiation and the "on-hold" procedure.... >> Thanks in advance for your help. >> >> >> Question #1 >> >> The RFC 3264 specifies §6.1 : >> >> If a stream is offered as sendonly, the corresponding stream MUST be >> marked as recvonly or inactive in the answer. If a media stream is >> listed as recvonly in the offer, the answer MUST be marked as >> sendonly or inactive in the answer. If an offered media stream is >> listed as sendrecv (or if there is no direction attribute at the >> media or session level, in which case the stream is sendrecv by >> default), the corresponding stream in the answer MAY be marked as >> sendonly, recvonly, sendrecv, or inactive. If an offered media >> stream is listed as inactive, it MUST be marked as inactive in the >> answer. >> >> The RFC 3264 specifies §8.4 : >> Putting a Unicast Media Stream on Hold >> >> If a party in a call wants to put the other party "on hold", i.e., >> request that it temporarily stops sending one or more unicast media >> streams, a party offers the other an updated SDP. >> >> If the stream to be placed on hold was previously a sendrecv media >> stream, it is placed on hold by marking it as sendonly. If the >> stream to be placed on hold was previously a recvonly media stream, >> it is placed on hold by marking it inactive. >> >> This means that a stream is placed "on hold" separately in each >> direction. Each stream is placed "on hold" independently. The >> recipient of an offer for a stream on-hold SHOULD NOT automatically >> return an answer with the corresponding stream on hold. An SDP with >> all streams "on hold" is referred to as held SDP. >> >> >> Taking into account the follwoing basic scenario, where A user calls B >> user, and where a SIP session is successfully established. Then, A user >> chooses to put B on-hold, and sends a new offer with all the media >> set to >> 'inactive'. B users generates his answer : >> >> -> Based on §6.1(RFC 3264), Ithink that B user MUST generate an >> answer with >> all the media set to inactive, >> -> Based on §8.4, Isuppose that B CAN generate an answer without all the >> media set to inactive. >> >> What should be the right behaviour for B when generating his offer? > > B must answer with inactive. > > I'm not especially happy with how this was described in the rfc, but > it has been discussed ad nauseum elsewhere. The use of sendonly to > signify HOLD assumes that the holder still wants to transmit > (presumably MOH). But often that is not the case. A holder that > doesn't want to send anything should be able to offer inactive. > > The answer to that must still be inactive - it is in effect an > acknowledgment that it was understood. > > BUT, that doesn't mean the B *wants* hold, only that it accepts it. If > B subsequently generates a new offer, it can *offer* whatever it > *wants*, which typically will be sendonly. Then if A still wants to be > on hold (probably yes), then it can respond with inactive or sendonly. > >> Question #2 >> >> Moreover, the examples given in the RFC 4317 (§3.2 listed below) seem to >> show that an answer following a consecutive offer putting a stream on >> hold >> can be constructed with identical SDP to the previous offer/answer >> exchanged. Is it really possible as it does not seem to be consistent >> with >> the RFC 3264? Can you please clarifies Alice's behaviour below? > > I hadn't noticed this before. I believe the example is in error. The > second answer is incorrect. The first stream in the second answer > should be either recvonly or inactive. > > Looks like a bug to me. Copying the author of that rfc. > > Paul > >> Hold with Two Streams >> >> In this example, two audio streams have been established in the first >> offer/answer exchange. In this second offer/answer exchange, one of >> the audio streams is placed on hold. Alice offers two media streams, >> a bidirectional audio stream and a send-only telephone event stream. >> Bob accepts both streams. Bob then puts Alice's audio stream on hold >> but not the tone stream. Alice responds with identical SDP to the >> initial offer. >> >> [Offer] >> >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= t=0 0 >> m=audio 49170 RTP/AVP 0 97 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:97 iLBC/8000 >> m=audio 49172 RTP/AVP 98 >> a=rtpmap:98 telephone-event/8000 >> a=sendonly >> >> [Answer] >> >> v=0 >> o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com >> s= t=0 0 >> m=audio 49172 RTP/AVP 97 >> a=rtpmap:97 iLBC/8000 >> m=audio 49174 RTP/AVP 98 >> a=rtpmap:98 telephone-event/8000 >> a=recvonly >> >> >> [Second-Offer] (From Bob) >> >> v=0 >> o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com >> s= t=0 0 >> m=audio 49172 RTP/AVP 97 >> a=rtpmap:97 iLBC/8000 >> a=sendonly >> m=audio 49174 RTP/AVP 98 >> a=rtpmap:98 telephone-event/8000 >> a=recvonly >> >> [Second-Answer] >> >> v=0 >> o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com >> s= t=0 0 >> m=audio 49170 RTP/AVP 0 97 >> a=rtpmap:0 PCMU/8000 >> a=rtpmap:97 iLBC/8000 >> m=audio 49172 RTP/AVP 98 >> a=rtpmap:98 telephone-event/8000 >> a=sendonly >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jan 28 19:21:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBKGk-0000Lh-Ty; Sun, 28 Jan 2007 19:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBKGk-0000Lb-2F for mmusic@ietf.org; Sun, 28 Jan 2007 19:21:10 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBKGg-0006xN-Og for mmusic@ietf.org; Sun, 28 Jan 2007 19:21:10 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Jan 2007 16:21:06 -0800 X-IronPort-AV: i="4.13,248,1167638400"; d="scan'208"; a="460273566:sNHT42077110" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0T0L5BL001519 for ; Sun, 28 Jan 2007 16:21:05 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0T0L5Uw014006 for ; Sun, 28 Jan 2007 16:21:05 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Jan 2007 16:21:05 -0800 Received: from [10.21.99.130] ([10.21.99.130]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Jan 2007 16:21:04 -0800 Message-ID: <45BD3DED.2090103@cisco.com> Date: Sun, 28 Jan 2007 19:21:01 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2007 00:21:04.0625 (UTC) FILETIME=[5D077610:01C7433B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=702; t=1170030065; x=1170894065; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotiation=3A=20Updated=20solution=20docu ment=20(-01) |Sender:=20; bh=dNiw4U+B4oiZ9jqeMe9sIrIc1RL6SiXE3kjvH9+BaU4=; b=xhdYVKlpvoQx5s/aHCApo2ggM44irX2gBP9yNHyvebEuxR5woBZgvAteL8jd4DJQ+o8D2Y4G k+u1Nz5C24TpwtpG5suajRL4Bfp0diV4gqii9NmXdZDHkyEjBY9H7ASp; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [MMUSIC] SDP Capability Negotiation: Updated solution document (-01) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Greetings I have just submitted an updated solution document as draft-ietf-mmusic-sdp-capability-negotiation-01.txt, which you can retrieve from http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-01.txt until it appears in the archives. The biggest change this time is to reduce the scope of the core framework to no longer include media capabilities - a solution for that will be provided in a separate document that will define it as an extension. Please refer to the change log for a more comprehensive list of changes We will discuss this document in our next SDP Capability Negotiation design team call (1/30/07). Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 29 02:13:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBQgh-0006YM-PK; Mon, 29 Jan 2007 02:12:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBQgg-0006Oq-73 for mmusic@ietf.org; Mon, 29 Jan 2007 02:12:22 -0500 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBQge-0006HH-Qq for mmusic@ietf.org; Mon, 29 Jan 2007 02:12:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] SDP Capability Negotiation: Updated solution document (-01) Date: Mon, 29 Jan 2007 09:12:12 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04461DE4@IsrExch01.israel.polycom.com> In-Reply-To: <45BD3DED.2090103@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP Capability Negotiation: Updated solution document (-01) Thread-Index: AcdDPBSHghZkqWMcS2mO2J7sk8gEKAAN5C7g From: "Even, Roni" To: "Flemming Andreasen" , "mmusic" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, I would like to clarify that the design team based on email discussion = has decided to divide the proposed solution for the capability = negotiation, as specified in = draft-ietf-mmusic-sdp-capability-negotiation-reqts-00 to a core part = addressing mostly the profile negotiation and an extension that will be = specified in a separate document addressing the media capabilities = negotiation. Note that the minimal implementation will need to support only the core = part while extensions are optional. Roni Even =20 > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Monday, January 29, 2007 2:21 AM > To: mmusic > Subject: [MMUSIC] SDP Capability Negotiation: Updated solution = document (- > 01) >=20 > Greetings >=20 > I have just submitted an updated solution document as > draft-ietf-mmusic-sdp-capability-negotiation-01.txt, which you can > retrieve from > http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability- > negotiation-01.txt > until it appears in the archives. >=20 > The biggest change this time is to reduce the scope of the core > framework to no longer include media capabilities - a solution for = that > will be provided in a separate document that will define it as an > extension. Please refer to the change log for a more comprehensive = list > of changes >=20 > We will discuss this document in our next SDP Capability Negotiation > design team call (1/30/07). >=20 > Thanks >=20 > -- Flemming >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 29 15:50:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdSB-0007hj-4a; Mon, 29 Jan 2007 15:50:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdS1-0007dh-15; Mon, 29 Jan 2007 15:50:05 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBdRz-0006tm-2J; Mon, 29 Jan 2007 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id BC4DC26ED0; Mon, 29 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HBdRy-0001Wy-Bz; Mon, 29 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 29 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP Capability Negotiation Author(s) : F. Andreasen Filename : draft-ietf-mmusic-sdp-capability-negotiation-01.txt Pages : 29 Date : 2007-1-29 The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-capability-negotiation-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-29110959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-capability-negotiation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-29110959.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Mon Jan 29 17:52:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfME-0006GQ-Vp; Mon, 29 Jan 2007 17:52:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfMD-0006GD-Rb for mmusic@ietf.org; Mon, 29 Jan 2007 17:52:13 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBfM3-0006jW-JY for mmusic@ietf.org; Mon, 29 Jan 2007 17:52:13 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Jan 2007 14:52:03 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0TMq2oj009140 for ; Mon, 29 Jan 2007 14:52:02 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0TMprnd006763 for ; Mon, 29 Jan 2007 14:52:02 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 14:51:53 -0800 Received: from [10.21.154.8] ([10.21.154.8]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 14:51:53 -0800 Message-ID: <45BE7A87.8030904@cisco.com> Date: Mon, 29 Jan 2007 17:51:51 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mmusic X-OriginalArrivalTime: 29 Jan 2007 22:51:53.0305 (UTC) FILETIME=[11CE9490:01C743F8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9487; t=1170111122; x=1170975122; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDP=20Capability=20Negotation=3A=20Minutes=20of=201/23/07=20d esign=20team=20conference=0A=20call |Sender:=20; bh=SfN6qMhdW8MXlO08mXyNM0z9lgORKJHiYAUk20LKz9c=; b=rOUUrZszvK42fVamJDtvl7T/6HGD1N648fyEhz0Bz6G4n3hEbcU7THrtkHg1PxQEjTSZxsSn ADkKfdwEaxk3B5zQULhq9J1dDTnTL93t0pO6PSA+0SKlOttjdOHP+b0e; Authentication-Results: sj-dkim-5; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Subject: [MMUSIC] SDP Capability Negotation: Minutes of 1/23/07 design team conference call X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1903966503==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1903966503== Content-Type: multipart/alternative; boundary="------------060801070306060906060305" This is a multi-part message in MIME format. --------------060801070306060906060305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings The SDP Capability Negotiation Design team had a conference call on 1/23/07. The attendees were: Matt Lepinski Flemming Andreasen Roni Even Christian Scmidt Thomas Stach Bob Gilman Colin Perkins The topics discussed were: 1. Splitting the current solution document in two 2. Specific technical issues in current document 3. Media capabilities 4) Media Stream Dependency draft 1) Splitting the solution document in two There have been concerns expressed on the list as well in private about the scope, perceived complexity and timeliness for coming up with a capability negotiation solution. The pressing need here is to address capability negotiation for transport protocols and associated attributes (e.g. secure RTP). A lot of the perveived complexity, and the majority of the open issues have to do with media capabilities and their associated negotiation semantics. In order to address the concerns expressed, the design team agreed to split the current solution document in two parts: a) A core part that contains a general capability negotiation framework as well as transport protocol capabilities and attribute capabilities. b) An extension for providing media capabilities, which can be used to address the codec negotiation and latent media stream requirements. The goal is to progress the two documents in parallel and have a solid proposal in place for the Praque meeting, however the core part can (and will) proceed independently of the media capabilities extension if necessary. Flemming will split the core solution document accordingly and update the requirements document to reflect this as well. Bob Gilman, Roni Even, and Flemming will work on producing the media capabilities document as well. 2) Specific technical issues. The team had a discussion around the numbering scope for transport protocol capability handles. Currently, the document provides a single global numbering scope for the entire session, irrespective of whether transport protocol capabilities are provided at the session level or the media level. This provides a simple and easy way to ensure handle uniqueness and enable referencing between the session and media-level. It does however require that numbering to be coordinated between the individual media streams. The team eventually agreed that the scope should be global (the entire session description) as is specified currently. A similar discussion took place for the attribute capability and the same conclusion was reached. It did however bring up a related issue, namely what does it mean to include a session-level attribute capability in a media-level potential configuration ? The updated solution document will propose a solution for that. Another (related) issue is that of ordering of potential configurations between the session and media-level - the updated solution document will propose a solution for that as well. 3) Media Capabilities Bob Gilman had sent out a modified proposal for media capabilities (on 1/16/07) based on the design team discussions that had taken place previously. There was general concensus in the design team around the proposal (modulo a few nits) and hence it will form the basis for the media capabilities document that will be provided separately. One potential issue with the proposal was discussed, namely whether the cmed attribute should provide the same MIME subtype more than once, or whether we should rather have a level of indirection that allows us to build composite capabilities above and beyond that provided by proposed "cenc" and "cfmt" attributes. Flemming felt that this warranted further consideration. 4) Media Stream Dependencies Christian Schmidt suggested the design team consider draft-schmidt-mmusic-media-dependency-00.txt in its further work. The team felt that was a bit premature since it has just been submitted as an individual draft and there appears to be potential overlap with some existing work related to signaling for layered codecs. Thanks -- Flemming --------------060801070306060906060305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings

The SDP Capability Negotiation Design team had a conference call on 1/23/07. The attendees were:

    Matt Lepinski
    Flemming Andreasen
    Roni Even
    Christian Scmidt
    Thomas Stach
    Bob Gilman
    Colin Perkins

The topics discussed were:
1. Splitting the current solution document in two
2. Specific technical issues in current document
3. Media capabilities
4) Media Stream Dependency draft

1) Splitting the solution document in two
There have been concerns expressed on the list as well in private about the scope, perceived complexity and timeliness for coming up with a capability negotiation solution. The pressing need here is to address capability negotiation for transport protocols and associated attributes (e.g. secure RTP).
A lot of the perveived complexity, and the majority of the open issues have to do with media capabilities and their associated negotiation semantics. In order to address the concerns expressed, the design team agreed to split the current solution document in two parts:
a) A core part that contains a general capability negotiation framework as well as transport protocol capabilities and attribute capabilities.
b) An extension for providing media capabilities, which can be used to address the codec negotiation and latent media stream requirements.

The goal is to progress the two documents in parallel and have a solid proposal in place for the Praque meeting, however the core part can (and will) proceed independently of the media capabilities extension if necessary.

Flemming will split the core solution document accordingly and update the requirements document to reflect this as well. Bob Gilman, Roni Even, and Flemming will work on producing the media capabilities document as well.

2) Specific technical issues.
The team had a discussion around the numbering scope for transport protocol capability handles. Currently, the document provides a single global numbering scope for the entire session, irrespective of whether transport protocol capabilities are provided at the session level or the media level.  This provides a simple and easy way to ensure handle uniqueness and enable referencing between the session and media-level. It does however require that numbering to be coordinated between the individual media streams. The team eventually agreed that the scope should be global (the entire session description) as is specified currently.

A similar discussion took place for the attribute capability and the same conclusion was reached.

It did however bring up a related issue, namely what does it mean to include a session-level attribute capability in a media-level potential configuration ? The updated solution document will propose a solution for that.

Another (related) issue is that of ordering of potential configurations between the session and media-level - the updated solution document will propose a solution for that as well.

3) Media Capabilities
Bob Gilman had sent out a modified proposal for media capabilities (on 1/16/07) based on the design team discussions that had taken place previously. There was general concensus in the design team around the proposal (modulo a few nits) and hence it will form the basis for the media capabilities document that will be provided separately. One potential issue with the proposal was discussed, namely whether the cmed attribute should provide the same MIME subtype more than once, or whether we should rather have a level of indirection that allows us to build composite capabilities above and beyond that provided by proposed "cenc" and "cfmt" attributes. Flemming felt that this warranted further consideration.

4) Media Stream Dependencies
Christian Schmidt suggested the design team consider draft-schmidt-mmusic-media-dependency-00.txt in its further work. The team felt that was a bit premature since it has just been submitted as an individual draft and there appears to be potential overlap with some existing work related to signaling for layered codecs.


Thanks

-- Flemming


--------------060801070306060906060305-- --===============1903966503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1903966503==-- From mmusic-bounces@ietf.org Mon Jan 29 18:03:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfWj-0000ax-3n; Mon, 29 Jan 2007 18:03:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfWi-0000as-77 for mmusic@ietf.org; Mon, 29 Jan 2007 18:03:04 -0500 Received: from keskus.netlab.hut.fi ([130.233.154.176] helo=smtp.netlab.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBfWg-00084Z-SF for mmusic@ietf.org; Mon, 29 Jan 2007 18:03:04 -0500 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id ACBC74FEFD; Tue, 30 Jan 2007 01:02:59 +0200 (EET) Message-ID: <45BE7D24.6090403@netlab.hut.fi> Date: Tue, 30 Jan 2007 01:03:00 +0200 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-01) References: <45BD3DED.2090103@cisco.com> In-Reply-To: <45BD3DED.2090103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Flemming, thanks a lot for the updated document. Looks good. Two quick comments/questions: Sect 2.1, example: The answerer returns the following SDP: v=0 o=- 24351 621814 IN IP4 128.96.41.2 s= c=IN IP4 128.96.41.2 t=0 0 m=audio 4567 RTP/SAVP 0 18 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 a=acfg: t=1 a=1 which means the desired shift from the backwards-compatible plain AVP to SAVP, thus yielding best-effort SRTP. In the discussions around ICE there was consensus that, ultimately, the m= lines should reflect what got actually negotiated (and thus will be sent) to be kind-of-nice to middleboxes trying to second-guess on what you are doing. We should follow the same approach here. (In principle, we negotiate two independent RTP sessions, so one direction might be protected while the other might not, but this perception from observing just the m= lines is not the semantics of the finally negotiated session.) Do we want an updated offer/answer exchange (in 2.5.3)? Sect 2.2.2, editorial? The text states: When an entity does not support one or more required SDP capability negotiation extensions, the entity SHOULD proceed as if the SDP capability negotiation attributes were not included in the first place, i.e. all the capability negotiation attributes should be ignored. Does this imply that the answerer SHOULD not provide any information back to the offerer? Wouldn't at least an a=csup: make sense? Joerg > Greetings > > I have just submitted an updated solution document as > draft-ietf-mmusic-sdp-capability-negotiation-01.txt, which you can > retrieve from > http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-01.txt > until it appears in the archives. > > The biggest change this time is to reduce the scope of the core > framework to no longer include media capabilities - a solution for that > will be provided in a separate document that will define it as an > extension. Please refer to the change log for a more comprehensive list > of changes > > We will discuss this document in our next SDP Capability Negotiation > design team call (1/30/07). > > Thanks > > -- Flemming > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jan 29 20:50:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBi8P-0007r3-Gl; Mon, 29 Jan 2007 20:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBi8O-0007qy-4T for mmusic@ietf.org; Mon, 29 Jan 2007 20:50:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBi8M-0005fb-OQ for mmusic@ietf.org; Mon, 29 Jan 2007 20:50:08 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 29 Jan 2007 17:50:06 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0U1o50A030226; Mon, 29 Jan 2007 17:50:05 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0U1o5hs012702; Mon, 29 Jan 2007 17:50:05 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 17:50:05 -0800 Received: from [10.21.154.8] ([10.21.154.8]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 17:50:05 -0800 Message-ID: <45BEA44C.6080205@cisco.com> Date: Mon, 29 Jan 2007 20:50:04 -0500 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Joerg Ott Subject: Re: [MMUSIC] SDP Capability Negotiation: Updated solution document (-01) References: <45BD3DED.2090103@cisco.com> <45BE7D24.6090403@netlab.hut.fi> In-Reply-To: <45BE7D24.6090403@netlab.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2007 01:50:05.0309 (UTC) FILETIME=[F6BCEAD0:01C74410] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3018; t=1170121805; x=1170985805; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20Capability=20Negotiation=3A=20Update d=20solution=20document=0A=20(-01) |Sender:=20; bh=EBJ9YpXdh9hd1wOXKNbOnCda7BXKnu1MZI/G2wECgcg=; b=JRMuG3NoLBbl+ZSTFMQrEDrwVgEoIhrVbHcs38MAc06D9dEeUICMAy+BC5VWS0y+9CBMSIUO rXtb1L8fxBHpNL8+cqc0edyRa2CMJl2NlXp6a96SqIlo9pA9ovCIY90T; Authentication-Results: sj-dkim-6; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mmusic X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Joerg Ott wrote: > Flemming, > > thanks a lot for the updated document. Looks good. > Two quick comments/questions: > > Sect 2.1, example: > > The answerer returns the following SDP: > > v=0 > o=- 24351 621814 IN IP4 128.96.41.2 > s= > c=IN IP4 128.96.41.2 > t=0 0 > m=audio 4567 RTP/SAVP 0 18 > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 > a=acfg: t=1 a=1 > > which means the desired shift from the backwards-compatible > plain AVP to SAVP, thus yielding best-effort SRTP. In the > discussions around ICE there was consensus that, ultimately, > the m= lines should reflect what got actually negotiated (and > thus will be sent) to be kind-of-nice to middleboxes trying > to second-guess on what you are doing. We should follow the > same approach here. Agreed - in general, there is more work to be done on the offer/answer procedures and I agree that the example should be updated accordingly to at least indicate that another O/A exchange should take place. > > (In principle, we negotiate two independent RTP sessions, > so one direction might be protected while the other might > not, but this perception from observing just the m= lines > is not the semantics of the finally negotiated session.) Right (although I disagree with the "two independent RTP sessions" part, but that's nit not worth arguing) > > Do we want an updated offer/answer exchange (in 2.5.3)? Yes. > > > Sect 2.2.2, editorial? > > The text states: > > When an entity does not support one or more required SDP capability > negotiation extensions, the entity SHOULD proceed as if the SDP > capability negotiation attributes were not included in the first > place, i.e. all the capability negotiation attributes should be > ignored. > > Does this imply that the answerer SHOULD not provide any information > back to the offerer? Wouldn't at least an a=csup: make sense? Yes - good point - will add in the next revision. Thanks -- Flemming > > Joerg > >> Greetings >> >> I have just submitted an updated solution document as >> draft-ietf-mmusic-sdp-capability-negotiation-01.txt, which you can >> retrieve from >> http://www.geocities.com/fandreasen/draft-ietf-mmusic-sdp-capability-negotiation-01.txt >> until it appears in the archives. >> >> The biggest change this time is to reduce the scope of the core >> framework to no longer include media capabilities - a solution for >> that will be provided in a separate document that will define it as >> an extension. Please refer to the change log for a more comprehensive >> list of changes >> >> We will discuss this document in our next SDP Capability Negotiation >> design team call (1/30/07). >> >> Thanks >> >> -- Flemming >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jan 31 10:31:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHQL-0005E3-I4; Wed, 31 Jan 2007 10:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHQK-0005Dy-FV for mmusic@ietf.org; Wed, 31 Jan 2007 10:31:00 -0500 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHQE-0001Zj-Gp for mmusic@ietf.org; Wed, 31 Jan 2007 10:31:00 -0500 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:50910) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HCHQD-0008Om-SN; Wed, 31 Jan 2007 15:30:53 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt Date: Wed, 31 Jan 2007 15:30:52 +0000 To: Flemming Andreasen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: MMusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 29 Jan 2007, at 20:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session > Control Working Group of the IETF. > > Title : SDP Capability Negotiation > Author(s) : F. Andreasen > Filename : draft-ietf-mmusic-sdp-capability-negotiation-01.txt > Pages : 29 > Date : 2007-1-29 > > The Session Description Protocol (SDP) was intended for describing > multimedia sessions for the purposes of session > announcement, session > invitation, and other forms of multimedia session > initiation. SDP was > not intended to provide capability indication or capability > negotiation, however over the years, SDP has seen > widespread adoption > and as a result it has been gradually extended to provide > limited > support for these. SDP and its current extensions however > do not have > the ability to negotiate one or more alternative transport > protocols > (e.g. RTP profiles) which makes it particularly difficult > to deploy > new RTP profiles such as secure RTP or RTP with RTCP-based > feedback. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp- > capability-negotiation-01.txt This draft is in very good shape. I do have some minor and editorial comments, though, to follow on from the discussions in the conference call yesterday: The "Conventions Used in this Document" section needs to be located after the Introduction, before the current Section 2. As I mentioned in the call, I find "a=ctrpr" difficult to read and remember. It would be easier if all capability attributes had a common style, perhaps "a=capar" for attributes, "a=ctpar" for transport, and "a=cmpar" for media; or maybe "a=acap", "a=tcap", and "a=mcap"? I was surprised white space was permitted before the in "a=csup:" and "a=creq". That seems inconsistent with typical SDP practice. In Section 2.2.2 the paragraph starting "When an entity generates an SDP..." says the "a=creq" attribute "MUST be included..., unless". Maybe "SHOULD be included..., unless" is intended? In Section 2.3.1, it would be helpful if the grammar for "a=capar:" could be expressed as ABNF, presumably referencing the "attribute" element from RFC 4566. Similar comments apply to Section 2.3.2 and 2.4.1. In Section 2.3.1, is white space allowed between "a=capar:" and the field? I recommend not, for consistency with other SDP attributes. This will mean the examples later in the draft need to be updated. Similar comments apply for the other new attributes, and the later examples. In Section 2.3.1, can we make the range of be 1...2^31-1 (both included)? That's still more space than we'll need, and it makes things more efficient for users of a certain programming language. Also in Section 2.3.2 and 2.4.1. In Section 2.3.1, second paragraph on page 12, should be ? In Section 2.3.1, note that the lines of the examples have been wrapped to fit the page, and are single lines in SDP. In Section 2.4.1, the "|" character is invalid ABNF, "/" is used to specify alternatives. Similar in Section 2.4.2. In Section 3.1, I suggest the example omit the second potential configuration, to show the simplest case, and have a second example with both configurations listed. More examples in general would be helpful. The idnits tool also finds a number of nits (the boilerplate will presumably need fixing, or the secretariat will bounce the next version). idnits 1.124 draft-ietf-mmusic-sdp-capability-negotiation-01.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... - This document has ISOC Copyright according to RFC 3978, instead of the newer IETF Trust Copyright according to RFC 4748. You should consider updating it; the new Copyright statement will be required from February 1st, 2007 - This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. You should consider updating it; the new disclaimer will be required from February 1st, 2007 * There are 463 instances of too long lines in the document, the longest one being 5 characters in excess of 72. * There are 16 instances of lines with non-RFC3330-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Checking nits according to http://www.ietf.org/ietf/1id- guidelines.txt: - The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 1) being 60 lines Miscellaneous warnings: None. Experimental warnings: - Missing Reference: 'Section 8' is mentioned on line 930, but not defined - Missing Reference: ' doing so is' is mentioned on line 930, but not defined - Unused Reference: 'RFC2234' is defined on line 1138, but not referenced - Unused Reference: 'RFC3407' is defined on line 1146, but not referenced - Unused Reference: 'RFC3605' is defined on line 1149, but not referenced - Unused Reference: 'RFC2046' is defined on line 1161, but not referenced - Unused Reference: 'RFC2327' is defined on line 1165, but not referenced - Unused Reference: 'RFC3388' is defined on line 1172, but not referenced - Unused Reference: 'RFC3851' is defined on line 1184, but not referenced - Unused Reference: 'RFC4091' is defined on line 1188, but not referenced - Unused Reference: 'BESRTP' is defined on line 1212, but not referenced - Unused Reference: 'SDPCapNegRqts' is defined on line 1221, but not referenced - Unused Reference: 'MIKEY' is defined on line 1228, but not referenced -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic