From fluffy@cisco.com Mon Oct 1 06:28:21 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD4511E8161 for ; Mon, 1 Oct 2012 06:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUtwqdY+Miih for ; Mon, 1 Oct 2012 06:28:20 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7705C1F0D09 for ; Mon, 1 Oct 2012 06:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5555; q=dns/txt; s=iport; t=1349098099; x=1350307699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+iLqVq4GaMwmlZcuI9vhjH4huFmA3PaJzAV8eKcxzvI=; b=YmIQmpfVTT32gnj4cMOCUfs6Dht59WnpvOhpeRtTCentVgrufuJ1EjZO nzQrtUydXUEfm00IyxOaEP/NjhTIdDsNA/5butvjjsJR73GLcvLkJ1Oo7 VVtSdtRSsrm7DriJ0y9XTK2/4JDC434LpyAc5CHdtf+OCy0MQYWon6pzY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACeZaVCtJXG8/2dsb2JhbABFvjmBCIIgAQEBAwEBAQEPAQodNAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIARmHXQYLmlefdIsfhWtgA5Z+jS2BaYJnghc X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="124065483" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 01 Oct 2012 13:28:18 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q91DSI3n027722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Oct 2012 13:28:18 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 08:28:18 -0500 From: "Cullen Jennings (fluffy)" To: "Miguel A. Garcia" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNn9idpnrfX5XVdkCtnrpEme07QQ== Date: Mon, 1 Oct 2012 13:28:17 +0000 Message-ID: References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> <5066A49F.2040002@ericsson.com> In-Reply-To: <5066A49F.2040002@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19226.000 x-tm-as-result: No--45.928300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , mmusic WG , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 13:28:21 -0000 I think the issues is how does a manffacture says on a spec sheet that they= want support half of it but not all of it. I know that does not matter for= 3GPP usage but it sort of useful for others. Clearly this is not a huge te= chnical issues but a small procedural thing so I leave it up to the chairs = what they want to do.=20 Any thoughts on making the changes so this works in world with more than en= glish? That was my far more relevant comment that is likely to also be rais= ed by IESG. On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia wrote: > Cullen, >=20 > The draft is written as an independent collection of "objects". This is a= void having three separate drafts. >=20 > It is possible to refer to parts of this draft. For example, I believe 3G= PP only needs the connection data capability, but not the others, and still= they are fine with this draft. >=20 > Couldn't the same principle be applied by RTCweb? >=20 > /Miguel >=20 > On 28/09/2012 17:02, Atle Monrad wrote: >> Hi >>=20 >> Is it really necessary to chop the draft up in pieces because others may= want to use just parts of it? >>=20 >> I find it more constuctive to finish this draft as is and let other be a= ble to build on and refer to the RFC if and when possible. >>=20 >> /atle >>=20 >> ________________________________ >>=20 >>=20 >> Atle Monrad >> 3GPP CT Chairman >> Standardization and Regulation, >> Group Function Technology and Portfolio Management >> Ericsson >>=20 >>=20 >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Cullen Jennings (fluffy) >> Sent: 28. september 2012 16:47 >> To: mmusic WG >> Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-c= aps@tools.ietf.org >> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-= 01.txt >>=20 >>=20 >> Major comment >>=20 >> I think the title stuff should be split out to a separate draft. The mai= n reason is that you might want to build a dvicd that supported title but d= id not supper the others and still be able to say what you were doing was R= FC X. For example, the RTC Web folks may want to use this. >>=20 >> Given the Title is meant to be human readable, I think it needs to be ex= tended to have normal i18n support. >>=20 >> Cullen >>=20 >>=20 >>=20 >> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrot= e: >>=20 >>> This is to announce a 2 week Working Group Last Call for >>>=20 >>> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>=20 >>> as Proposed Standard. Please review and provide any comments you may ha= ve on the document by September 21, 2012. Comments should be sent to the do= cument authors and the MMUSIC WG list. >>>=20 >>>=20 >>> Thanks >>>=20 >>> Flemming >>>=20 >>>=20 >>>=20 >>>=20 >>> Draft Info: >>> This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. >>>=20 >>> Title : Miscellanoues Capabilities Negotiation in the Sessio= n Description Protocol (SDP) >>> Author(s) : Miguel A. Garcia-Martin >>> Simo Veikkolainen >>> Robert R. Gilman >>> Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>> Pages : 19 >>> Date : 2012-08-27 >>>=20 >>> Abstract: >>> SDP has been extended with a capability negotiation mechanism >>> framework that allows the endpoints to negotiate transport protocols >>> and attributes. This framework has been extended with a media >>> capabilities negotiation mechanism that allows endpoints to negotiat= e >>> additional media-related capabilities. This negotiation is embedded >>> into the widely-used SDP offer/answer procedures. >>>=20 >>> This memo extends the SDP capability negotiation framework to allow >>> endpoints to negotiate three additional SDP capabilities. In >>> particular, this memo provides a mechanism to negotiate bandwidth >>> ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' lin= e for >>> each session or media). >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c >>> aps >>>=20 >>>=20 >>> There's also a htmlized version available at: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >>>=20 >>>=20 >>> A diff from the previous version is available at: >>>=20 >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-= c >>> aps-01 >>>=20 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>>=20 >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From thomas.belling@nsn.com Mon Oct 1 07:16:15 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9471F0CD6 for ; Mon, 1 Oct 2012 07:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZO639OZD4Oh for ; Mon, 1 Oct 2012 07:16:14 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id DE3501F0CF9 for ; Mon, 1 Oct 2012 07:16:13 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q91EG3w6016085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 16:16:04 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q91EG09U017559; Mon, 1 Oct 2012 16:16:01 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Oct 2012 16:16:00 +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: Mon, 1 Oct 2012 16:15:59 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F01D13C61@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNn9idpnrfX5XVdkCtnrpEme07QZekfR0g References: <5049096F.7080908@cisco.com><94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com><7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se><5066A49F.2040002@ericsson.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Cullen Jennings (fluffy)" , "Miguel A. Garcia" X-OriginalArrivalTime: 01 Oct 2012 14:16:00.0719 (UTC) FILETIME=[488AC5F0:01CD9FDF] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6513 X-purgate-ID: 151667::1349100966-00003184-805C68F6/0-0/0-0 Cc: "Flemming Andreasen \(fandreas\)" , mmusic WG , draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:16:15 -0000 > I think the issues is how does a manffacture says on a spec sheet that they want support half of it but not all of it.=20 You could say that you support clause 3.1.1. Bandwidth Capability, 3.1.2. Connection Data Capability, or 3.1.3. Title Capability. The draft also defines three separate option tags bcap-v0", "ccap-v0", and "icap-v0", for those capabilities defined that you could refer to. I hope this is good enough? Thomas -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Cullen Jennings (fluffy) Sent: Monday, October 01, 2012 3:28 PM To: Miguel A. Garcia Cc: Flemming Andreasen (fandreas); mmusic WG; draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt I think the issues is how does a manffacture says on a spec sheet that they want support half of it but not all of it. I know that does not matter for 3GPP usage but it sort of useful for others. Clearly this is not a huge technical issues but a small procedural thing so I leave it up to the chairs what they want to do.=20 Any thoughts on making the changes so this works in world with more than english? That was my far more relevant comment that is likely to also be raised by IESG. On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia wrote: > Cullen, >=20 > The draft is written as an independent collection of "objects". This is avoid having three separate drafts. >=20 > It is possible to refer to parts of this draft. For example, I believe 3GPP only needs the connection data capability, but not the others, and still they are fine with this draft. >=20 > Couldn't the same principle be applied by RTCweb? >=20 > /Miguel >=20 > On 28/09/2012 17:02, Atle Monrad wrote: >> Hi >>=20 >> Is it really necessary to chop the draft up in pieces because others may want to use just parts of it? >>=20 >> I find it more constuctive to finish this draft as is and let other be able to build on and refer to the RFC if and when possible. >>=20 >> /atle >>=20 >> ________________________________ >>=20 >>=20 >> Atle Monrad >> 3GPP CT Chairman >> Standardization and Regulation, >> Group Function Technology and Portfolio Management Ericsson >>=20 >>=20 >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 >> Behalf Of Cullen Jennings (fluffy) >> Sent: 28. september 2012 16:47 >> To: mmusic WG >> Cc: Flemming Andreasen (fandreas);=20 >> draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org >> Subject: Re: [MMUSIC] WGLC for=20 >> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>=20 >>=20 >> Major comment >>=20 >> I think the title stuff should be split out to a separate draft. The main reason is that you might want to build a dvicd that supported title but did not supper the others and still be able to say what you were doing was RFC X. For example, the RTC Web folks may want to use this. >>=20 >> Given the Title is meant to be human readable, I think it needs to be extended to have normal i18n support. >>=20 >> Cullen >>=20 >>=20 >>=20 >> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrote: >>=20 >>> This is to announce a 2 week Working Group Last Call for >>>=20 >>> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>=20 >>> as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list. >>>=20 >>>=20 >>> Thanks >>>=20 >>> Flemming >>>=20 >>>=20 >>>=20 >>>=20 >>> Draft Info: >>> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. >>>=20 >>> Title : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) >>> Author(s) : Miguel A. Garcia-Martin >>> Simo Veikkolainen >>> Robert R. Gilman >>> Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>> Pages : 19 >>> Date : 2012-08-27 >>>=20 >>> Abstract: >>> SDP has been extended with a capability negotiation mechanism >>> framework that allows the endpoints to negotiate transport protocols >>> and attributes. This framework has been extended with a media >>> capabilities negotiation mechanism that allows endpoints to negotiate >>> additional media-related capabilities. This negotiation is embedded >>> into the widely-used SDP offer/answer procedures. >>>=20 >>> This memo extends the SDP capability negotiation framework to allow >>> endpoints to negotiate three additional SDP capabilities. In >>> particular, this memo provides a mechanism to negotiate bandwidth >>> ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' = line for >>> each session or media). >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous >>> -c >>> aps >>>=20 >>>=20 >>> There's also a htmlized version available at: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps- >>> 01 >>>=20 >>>=20 >>> A diff from the previous version is available at: >>>=20 >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous >>> -c >>> aps-01 >>>=20 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>>=20 >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From prvs=96215a188a=aallen@rim.com Mon Oct 1 09:42:03 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDD01F0D17 for ; Mon, 1 Oct 2012 09:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.053 X-Spam-Level: X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbeAKvanvr4n for ; Mon, 1 Oct 2012 09:41:55 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1163A1F0CCD for ; Mon, 1 Oct 2012 09:41:54 -0700 (PDT) X-AuditID: 0a41282f-b7fe96d000002cdb-98-5069c7d04e1e Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id 2F.2E.11483.0D7C9605; Mon, 1 Oct 2012 11:41:52 -0500 (CDT) Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 11:41:51 -0500 From: Andrew Allen To: Atle Monrad , Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNmvvCPDx15NdGLUayjvwj3da30Jejn8Gg Date: Mon, 1 Oct 2012 16:41:50 +0000 Message-ID: References: <5049096F.7080908@cisco.com> <505FD666.5080205@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D24A0@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E9070A0D24A0@ESESSCMS0352.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23382EA371XMB105ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFKsWRmVeSWpSXmKPExsXC5Zyvq3vheGaAQWeTksX5TXMYLTadOcZk 8f6CrsXU5Y9ZHFg8pvzeyOrx6+tVNo8lS34yeXy5/JktgCWqgdEmKbGkLDgzPU/fziYxLy+/ JLEkVSEltTjZVsknNT0xRyGgKLMsMblSwSWzODknMTM3tUhJITPFVslESaEgJzE5NTc1r8RW KbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2ekmdPJkfO46wVZwYzFj xbS131kaGO9PZOxi5OSQEDCReNNyjx3CFpO4cG89G4gtJLCSUWLhGekuRi4gezOjxMGNF1lB EmwCyhLLf88AaxYRyJeY9/ASmM0sUClx+Ps9pi5GDg5hgQCJjVPkIUoCJT5MvsUOEhYRMJJ4 ekoYJMwioCKxq2ka2CpeAQ+Jm9vfsEGsmswocef4VzaQek6BCIk7U9JAahiBTvt+ag0TxCZx iVtP5jNBnCwgsWTPeWYIW1Ti5eN/rBC2osTjlm4WkDHMQFdu67SEWCUocXLmE5YJjKKzkEya hVA1C0kVRImOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRMDej2MDMIDkvWa8oM1cvL7Vk EyMo8Thq6O9gfPve4hCjAAejEg/vtXmZAUKsiWXFlbmHGCU4mJVEeO1zgEK8KYmVValF+fFF pTmpxYcYXYFhNZFZijs5H5gU80rijQ0McHOUxHmNd6UECAmkAxNYdmpqQWoRzBwmDk6QPVxS IsXANJRalFhakhEPSpbxxcB0KdXAuI53+8cTH52OfjjurBSu+KaoTMrP5alMeWpoxaQVPm0n /t5NWRy7dG7y/tA1Rqs1vj81trhq8eCKjlGTtc61v+dUa999r3+alMDDrd296A1b3yauyOiV ruE2BhnfcqYuWnFmz5+jczLT+hd/cvr7c/u5/rCzO/PK3Bl2Xb2573zKitw6P4NVU5RYijMS DbWYi4oTASPdJxd9AwAA Cc: "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 16:42:03 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD23382EA371XMB105ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable I have been following this work closely for the past 18 months and did a tho= rough review of the 00 version and the only changes since then are a couple= of reference updates. So I don't have any comments and believe this draft should go forward. Andrew From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Atle Monrad Sent: Tuesday, September 25, 2012 3:57 AM To: Flemming Andreasen; mmusic Cc: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.t= xt Flemming The draft has been on the 3GPP dependency list since Rel-8. I have reviewed the draft and have no comments. 3GPP would be grateful if the draft could progress in a bundle with draft-ie= tf-mmusic-sdp-media-capabilities and draft-ietf-mmusic-sdp-cs as soon as pos= sible. thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Flemming Andreasen Sent: 24. september 2012 05:41 To: mmusic Cc: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.t= xt The WGLC for the Miscellaneous Capabilities draft is now over and we will be= proceeding with a publication request. We did not receive any comments on the draft during the WGLC. If you reviewe= d the document but did not have any comments on it, please let that the chai= rs now. Thanks -- Flemming On 9/6/12 4:37 PM, Flemming Andreasen wrote: This is to announce a 2 week Working Group Last Call for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt as Proposed Standard. Please review and provide any comments you may have on= the document by September 21, 2012. Comments should be sent to the document= authors and the MMUSIC WG list. Thanks Flemming Draft Info: This draft is a work item of the Multiparty Multimedia Session Control Work= ing Group of the IETF. Title : Miscellanoues Capabilities Negotiation in the Session Des= cription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Pages : 19 Date : 2012-08-27 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line for each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps-= 01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD23382EA371XMB105ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

 

I have been following this= work closely for the past 18 months and did a thorough review of the 00 ver= sion and the only changes since then are a couple of reference updates.

 

So I don’t have any c= omments and believe this draft should go forward.

 

Andrew

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.= org] On Behalf Of Atle Monrad
Sent: Tuesday, September 25, 2012 3:57 AM
To: Flemming Andreasen; mmusic
Cc: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-ca= ps-01.txt

 

Flemming

 

The draft has been on= the 3GPP dependency list since Rel-8.

 

I have reviewed the draft and ha= ve no comments.

 

3GPP would be grateful if the dr= aft could progress in a bundle with draft-ietf-mmusic-sdp-media-capabilities= and draft-ietf-mmusic-sdp-cs as soon as possible.

 

thanks

/atle

________________________________


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management =
Ericsson

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: 24. september 2012 05:41
To: mmusic
Cc: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-ca= ps-01.txt

The WGLC for the Misce= llaneous Capabilities draft is now over and we will be proceeding with a pub= lication request.

We did not receive any comments on the draft during the WGLC. If you reviewe= d the document but did not have any comments on it, please let that the chai= rs now.

Thanks

-- Flemming


On 9/6/12 4:37 PM, Flemming Andreasen wrote:

This is to announce a 2 week Working Group Last Call fo= r

     draf= t-ietf-mmusic-sdp-miscellaneous-caps-01.txt

as Proposed Standard. Please review and pro= vide any comments you may have on the document by September 21, 2012. Commen= ts should be sent to the document authors and the MMUSIC WG list.


Thanks

       Flemmi= ng




Draft Info:

 This draft is a work item of the Multiparty Multimedia Session Control=
 Working Group of the IETF.
 
 Title           : Mi=
scellanoues Capabilities Negotiation in the Session Description Protocol (SD=
P)
 Author(s)       : Miguel A. Garcia-Marti=
n
            =
;             &n=
bsp;Simo Veikkolainen
            =
;            &nb=
sp; Robert R. Gilman
 Filename        : draft-ietf-mmusic=
-sdp-miscellaneous-caps-01.txt
 Pages           : 19=

 Date           =
 : 2012-08-27
 
Abstract:
   SDP has been extended with a capability negotiation mechan=
ism
   framework that allows the endpoints to negotiate transport=
 protocols
   and attributes.  This framework has been extended wit=
h a media
   capabilities negotiation mechanism that allows endpoints t=
o negotiate
   additional media-related capabilities.  This negotiat=
ion is embedded
   into the widely-used SDP offer/answer procedures.
 
   This memo extends the SDP capability negotiation framework=
 to allow
   endpoints to negotiate three additional SDP capabilities.&=
nbsp; In
   particular, this memo provides a mechanism to negotiate ba=
ndwidth
   ('b=3D' line), connection data ('c=3D' line), and titles (=
'i=3D' line for
   each session or media).
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscel=
laneous-caps
 
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-c=
aps-01
 
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp=
-miscellaneous-caps-01
 
 
Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/inte=
rnet-drafts/











_______________________________________________


mmusic mailing list


mmusic@ietf.org


https://www.ie=
tf.org/mailman/listinfo/mmusic

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD23382EA371XMB105ADSrimnet_-- From prvs=56218f7cb5=aallen@rim.com Mon Oct 1 11:07:39 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9276C1F0D17 for ; Mon, 1 Oct 2012 11:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+faw8ONrxFW for ; Mon, 1 Oct 2012 11:07:38 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id D237F1F0D28 for ; Mon, 1 Oct 2012 11:07:37 -0700 (PDT) X-AuditID: 0a41282f-b7fe96d000002cdb-8d-5069dbe80c7c Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id 90.01.11483.8EBD9605; Mon, 1 Oct 2012 13:07:36 -0500 (CDT) Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 13:07:36 -0500 From: Andrew Allen To: "fluffy@cisco.com" , "Miguel.A.Garcia@ericsson.com" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNn92i/xKrQvDwaUK/rmYMJ9thiJekv4gb Date: Mon, 1 Oct 2012 18:07:35 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsXC5Zyvp/vidmaAwds1Rhabzhxjsnh/Qdei YzKbxZpPK9gtpi5/zOLA6jHl90ZWj19fr7J5LFnyk8njy+XPbAEsUQ2MNkmJJWXBmel5+nY2 iXl5+SWJJakKKanFybZKPqnpiTkKAUWZZYnJlQoumcXJOYmZualFSgqZKbZKJkoKBTmJyam5 qXkltkqJBQWpeSlKdlwKGMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC1FLXUMlON6GTJ+PV8zvs BatNKrr+dzE3MC7X6mLk5JAQMJHYcX0HC4QtJnHh3nq2LkYuDiGBlYwSPVtaGSGczYwSX/5s ZAapYhNQllj+ewYjiC0ikCUxf/02sCJmgdOMEn9bnrB3MXJwCAsESDzeZwtiiggEShw7owRR biTRfu4W2BgWARWJC5tXgi3mFfCQuLT0OVicU8BXomfbeyYQmxHooO+n1oDZzALiEreezGeC OFRAYsme88wQtqjEy8f/WCFsRYllJ06yQdTrSdyYOgXK1pZYtvA1M8QuQYmTM5+wTGAUnYVk 7CwkLbOQtMxC0rKAkWUVo2BuRrGBmUFyXrJeUWauXl5qySZGUPJw1NDfwfj2vcUhRgEORiUe Xr4TmQFCrIllxZW5hxglOJiVRHiPgoR4UxIrq1KL8uOLSnNSiw8xWgBDYiKzFHdyPjCx5ZXE GxsYoHCUxHmNd6UECAmkA1NMdmpqQWoRTCsTByfIaC4pkWJgokgtSiwtyYgHpbP4YmBCk2pg 7A0PEXkdprWwY+4S2Zj5LCsUPjVM+LPxpvqS1N8d0tcXvfFhEDuWuk+4d0774VhVa7/muNNR zA2bHp0V3TWh9oz1ym2t83fNEpzO2swtcvDfafE1vrWBXOvZZm9mWfd6jeC7D5//RdyQ3iOc fc7z4eGDn1TutPlaL984a6f906D6TaKPjbQrZiqxFGckGmoxFxUnAgBOH9ybUgMAAA== Cc: "fandreas@cisco.com" , "mmusic@ietf.org" , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 18:07:39 -0000 I think it is possible. The statement just needs to identify the sections of= the draft or functionality suppported - this is quite common practice in th= e industry. Maybe rather than a last minute delay to this work the best approach would b= e for another draft to be written under RTCweb that specifies the SDP extens= ons needed for RTCweb (is the title capability really the only one?) - a kin= d of RTCweb hitchikers guide for SDP and then vendors can claim compliance t= o that. Andrew ----- Original Message ----- From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] Sent: Monday, October 01, 2012 08:28 AM Central Standard Time=0A= To: Miguel A. Garcia Cc: Flemming Andreasen (fandreas) ; mmusic WG ; draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.t= xt I think the issues is how does a manffacture says on a spec sheet that they= want support half of it but not all of it. I know that does not matter for= 3GPP usage but it sort of useful for others. Clearly this is not a huge tec= hnical issues but a small procedural thing so I leave it up to the chairs wh= at they want to do. Any thoughts on making the changes so this works in world with more than eng= lish? That was my far more relevant comment that is likely to also be raised= by IESG. On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia = wrote: > Cullen, > > The draft is written as an independent collection of "objects". This is av= oid having three separate drafts. > > It is possible to refer to parts of this draft. For example, I believe 3GP= P only needs the connection data capability, but not the others, and still t= hey are fine with this draft. > > Couldn't the same principle be applied by RTCweb? > > /Miguel > > On 28/09/2012 17:02, Atle Monrad wrote: >> Hi >> >> Is it really necessary to chop the draft up in pieces because others may= want to use just parts of it? >> >> I find it more constuctive to finish this draft as is and let other be ab= le to build on and refer to the RFC if and when possible. >> >> /atle >> >> ________________________________ >> >> >> Atle Monrad >> 3GPP CT Chairman >> Standardization and Regulation, >> Group Function Technology and Portfolio Management >> Ericsson >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Cullen Jennings (fluffy) >> Sent: 28. september 2012 16:47 >> To: mmusic WG >> Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-ca= ps@tools.ietf.org >> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-0= 1.txt >> >> >> Major comment >> >> I think the title stuff should be split out to a separate draft. The main= reason is that you might want to build a dvicd that supported title but did= not supper the others and still be able to say what you were doing was RFC= X. For example, the RTC Web folks may want to use this. >> >> Given the Title is meant to be human readable, I think it needs to be ext= ended to have normal i18n support. >> >> Cullen >> >> >> >> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrote= : >> >>> This is to announce a 2 week Working Group Last Call for >>> >>> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>> >>> as Proposed Standard. Please review and provide any comments you may hav= e on the document by September 21, 2012. Comments should be sent to the docu= ment authors and the MMUSIC WG list. >>> >>> >>> Thanks >>> >>> Flemming >>> >>> >>> >>> >>> Draft Info: >>> This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. >>> >>> Title : Miscellanoues Capabilities Negotiation in the Session= Description Protocol (SDP) >>> Author(s) : Miguel A. Garcia-Martin >>> Simo Veikkolainen >>> Robert R. Gilman >>> Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>> Pages : 19 >>> Date : 2012-08-27 >>> >>> Abstract: >>> SDP has been extended with a capability negotiation mechanism >>> framework that allows the endpoints to negotiate transport protocols >>> and attributes. This framework has been extended with a media >>> capabilities negotiation mechanism that allows endpoints to negotiate >>> additional media-related capabilities. This negotiation is embedded >>> into the widely-used SDP offer/answer procedures. >>> >>> This memo extends the SDP capability negotiation framework to allow >>> endpoints to negotiate three additional SDP capabilities. In >>> particular, this memo provides a mechanism to negotiate bandwidth >>> ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line= for >>> each session or media). >>> >>> >>> The IETF datatracker status page for this draft is: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c >>> aps >>> >>> >>> There's also a htmlized version available at: >>> >>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >>> >>> >>> A diff from the previous version is available at: >>> >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-c >>> aps-01 >>> >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From miguel.a.garcia@ericsson.com Mon Oct 1 14:23:04 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F113B1F0D60 for ; Mon, 1 Oct 2012 14:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPwMd-GMFe5A for ; Mon, 1 Oct 2012 14:23:03 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 528271F040A for ; Mon, 1 Oct 2012 14:23:02 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-06-506a09b43c42 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B5.65.11467.4B90A605; Mon, 1 Oct 2012 23:23:01 +0200 (CEST) Received: from [164.48.161.175] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 1 Oct 2012 23:23:00 +0200 Message-ID: <506A09B3.8080502@ericsson.com> Date: Mon, 1 Oct 2012 23:22:59 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> <5066A49F.2040002@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvre5WzqwAg9Of2Cw2nTnGZPH+gq5F x2Q2i6nLH7M4sHhM+b2R1WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgymja9J2tYKp5xdl9 D5kaGGfodDFyckgImEjsbWhgh7DFJC7cW8/WxcjFISRwilFi7bsbTBDOakaJxQ2b2ECqeAW0 JZ5fvgPWwSKgIvFh7WUwm03AXKJ140YwW1QgWOLcxm1Q9YISJ2c+YQGxRQQMJZr2zAMbyizw g1Hi9Ns5QAkODmEBP4nnn7MhlrUxSbzvgWjgFPCV6Nn2ngnEZhawlbgw5zoLhC0vsf3tHGYQ W0hAU2LyzaXMExgFZyHZNwtJyywkLQsYmVcxCucmZuaklxvqpRZlJhcX5+fpFaduYgQG8sEt v3V3MJ46J3KIUZqDRUmclytpv7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxpRHPFJ6O87I LlK5tHn904lq+7b5uxsFHrLamWvUPEH8w0kO22J3f56cFafExMM7fb93fs/kD6w/Fnn03bTn /g/qeUrX8/zfFXq66635wkaT7bwfoi33vZ7OfqVaet/Ghj8vNTs2dKkeD027bSR+QDRvWQK/ bLrj1/dim3N/Fj25rpN9p9StXImlOCPRUIu5qDgRAMqgZUkyAgAA Cc: "Flemming Andreasen \(fandreas\)" , mmusic WG , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 21:23:04 -0000 Hi Cullen: I am writing as an author of this draft. This draft has been hanging around for years, and it was always presented as a collection of small capabilities that could be used independently, but, due to similarities, and in order to avoid the explosion of internet-drafts, could be documented together. At IETF 73 the draft was already presented indicating that "This new draft collects these miscellaneous capabilities into a single document." You can check the slide #3 at: http://www.ietf.org/proceedings/73/slides/mmusic-6.pdf At that point in time, while there were questions about the intention of the various capabilities defined in the document, none raised the question of the documentation of these capabilities in the same document. I don't recall anyone having a problem because we were specifying three independent capabilities in the same document. At some point in time, I consulted 3GPP, because I knew this draft was a dependency, and I was told that 3GPP was only using one of the capabilities, but was OK with documenting the other two in the same draft. If we apply the same logic to most of our documents, we will need to revise other drafts that we are specifying and we should trim capabilities or attributes that are somehow independent of the others. I think this is a tedious task at this stage. I therefore propose to continue with the existing document as is. BR, Miguel On 01/10/2012 15:28, Cullen Jennings (fluffy) wrote: > > I think the issues is how does a manffacture says on a spec sheet that they want support half of it but not all of it. I know that does not matter for 3GPP usage but it sort of useful for others. Clearly this is not a huge technical issues but a small procedural thing so I leave it up to the chairs what they want to do. > > Any thoughts on making the changes so this works in world with more than english? That was my far more relevant comment that is likely to also be raised by IESG. > > > > On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia wrote: > >> Cullen, >> >> The draft is written as an independent collection of "objects". This is avoid having three separate drafts. >> >> It is possible to refer to parts of this draft. For example, I believe 3GPP only needs the connection data capability, but not the others, and still they are fine with this draft. >> >> Couldn't the same principle be applied by RTCweb? >> >> /Miguel >> >> On 28/09/2012 17:02, Atle Monrad wrote: >>> Hi >>> >>> Is it really necessary to chop the draft up in pieces because others may want to use just parts of it? >>> >>> I find it more constuctive to finish this draft as is and let other be able to build on and refer to the RFC if and when possible. >>> >>> /atle >>> >>> ________________________________ >>> >>> >>> Atle Monrad >>> 3GPP CT Chairman >>> Standardization and Regulation, >>> Group Function Technology and Portfolio Management >>> Ericsson >>> >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) >>> Sent: 28. september 2012 16:47 >>> To: mmusic WG >>> Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org >>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>> >>> >>> Major comment >>> >>> I think the title stuff should be split out to a separate draft. The main reason is that you might want to build a dvicd that supported title but did not supper the others and still be able to say what you were doing was RFC X. For example, the RTC Web folks may want to use this. >>> >>> Given the Title is meant to be human readable, I think it needs to be extended to have normal i18n support. >>> >>> Cullen >>> >>> >>> >>> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrote: >>> >>>> This is to announce a 2 week Working Group Last Call for >>>> >>>> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>> >>>> as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list. >>>> >>>> >>>> Thanks >>>> >>>> Flemming >>>> >>>> >>>> >>>> >>>> Draft Info: >>>> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. >>>> >>>> Title : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) >>>> Author(s) : Miguel A. Garcia-Martin >>>> Simo Veikkolainen >>>> Robert R. Gilman >>>> Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>> Pages : 19 >>>> Date : 2012-08-27 >>>> >>>> Abstract: >>>> SDP has been extended with a capability negotiation mechanism >>>> framework that allows the endpoints to negotiate transport protocols >>>> and attributes. This framework has been extended with a media >>>> capabilities negotiation mechanism that allows endpoints to negotiate >>>> additional media-related capabilities. This negotiation is embedded >>>> into the widely-used SDP offer/answer procedures. >>>> >>>> This memo extends the SDP capability negotiation framework to allow >>>> endpoints to negotiate three additional SDP capabilities. In >>>> particular, this memo provides a mechanism to negotiate bandwidth >>>> ('b=' line), connection data ('c=' line), and titles ('i=' line for >>>> each session or media). >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c >>>> aps >>>> >>>> >>>> There's also a htmlized version available at: >>>> >>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >>>> >>>> >>>> A diff from the previous version is available at: >>>> >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-c >>>> aps-01 >>>> >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From fandreas@cisco.com Mon Oct 1 18:56:39 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CEE11E8173 for ; Mon, 1 Oct 2012 18:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqcnVHMTh3fr for ; Mon, 1 Oct 2012 18:56:38 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AC5CF11E8170 for ; Mon, 1 Oct 2012 18:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39276; q=dns/txt; s=iport; t=1349142997; x=1350352597; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=GdF+7g1lF4FTxDhyc7GVEJaXZ3k65lsScpuZlxAN1oY=; b=am7wvuBvAKTIWRF3VpE9lrYvMs/sDowNssHeH/kSLI8qNNIDcIpclnsz T7otrw29bSBmXsITdYG0ObJJ8Y1E7VobEbOcnC2x18qd2IV0G3Mx0ySAt vi0zIRsJ9CkO8S9xkoV8cBYVL6VAoWTMZmEy8fwQosu8le13wF7jF2aIb I=; X-IronPort-AV: E=Sophos;i="4.80,520,1344211200"; d="scan'208,217";a="127347629" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 02 Oct 2012 01:56:37 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q921uaAQ011607; Tue, 2 Oct 2012 01:56:36 GMT Message-ID: <506A49D4.40102@cisco.com> Date: Mon, 01 Oct 2012 21:56:36 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> <5066A49F.2040002@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090802000903060307050706" Cc: mmusic WG , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 01:56:39 -0000 This is a multi-part message in MIME format. --------------090802000903060307050706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/1/12 9:28 AM, Cullen Jennings (fluffy) wrote: > I think the issues is how does a manffacture says on a spec sheet that they want support half of it but not all of it. I know that does not matter for 3GPP usage but it sort of useful for others. Clearly this is not a huge technical issues but a small procedural thing so I leave it up to the chairs what they want to do. I think the draft is pretty clear in not requiring all of it to be implemented, e.g. as described in the Introduction: Since the three added capabilities are highly unconnected, it is not expected that implementations will support all of them at the same time.Instead, it is expected that applications will choose their needed capability for their specific purpose.Due to this, we are writing the normative part pertaining to each capability in a self- contained section: Section 3.1.1 describes the bandwidth capability extension, Section 3.1.2 describes the connection data capability extension, and Section 3.1.3 describes the title capability extension.Separate option tags are defined for each capability. and carried through in the main part of the doc itself (btw; there seems to be an error in the "conn-config-list" inasmuch as it does not include the "["+"]" prefix to indicate mandatory extensions). With the separate option tags in mind, the above text, and also inclusion of the "mandatory" prefix in the various configurations, do you still have concerns around the granularity of the draft ? > > Any thoughts on making the changes so this works in world with more than english? That was my far more relevant comment that is likely to also be raised by IESG. > Can you elaborate on how this differs from the native SDP use of the "i=" field, which is simply being carried over here (maybe there should be some text talking about "a=charset" interactions though, per RFC 4566) ? Thanks -- Flemming > > On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia wrote: > >> Cullen, >> >> The draft is written as an independent collection of "objects". This is avoid having three separate drafts. >> >> It is possible to refer to parts of this draft. For example, I believe 3GPP only needs the connection data capability, but not the others, and still they are fine with this draft. >> >> Couldn't the same principle be applied by RTCweb? >> >> /Miguel >> >> On 28/09/2012 17:02, Atle Monrad wrote: >>> Hi >>> >>> Is it really necessary to chop the draft up in pieces because others may want to use just parts of it? >>> >>> I find it more constuctive to finish this draft as is and let other be able to build on and refer to the RFC if and when possible. >>> >>> /atle >>> >>> ________________________________ >>> >>> >>> Atle Monrad >>> 3GPP CT Chairman >>> Standardization and Regulation, >>> Group Function Technology and Portfolio Management >>> Ericsson >>> >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) >>> Sent: 28. september 2012 16:47 >>> To: mmusic WG >>> Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org >>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>> >>> >>> Major comment >>> >>> I think the title stuff should be split out to a separate draft. The main reason is that you might want to build a dvicd that supported title but did not supper the others and still be able to say what you were doing was RFC X. For example, the RTC Web folks may want to use this. >>> >>> Given the Title is meant to be human readable, I think it needs to be extended to have normal i18n support. >>> >>> Cullen >>> >>> >>> >>> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrote: >>> >>>> This is to announce a 2 week Working Group Last Call for >>>> >>>> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>> >>>> as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list. >>>> >>>> >>>> Thanks >>>> >>>> Flemming >>>> >>>> >>>> >>>> >>>> Draft Info: >>>> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. >>>> >>>> Title : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) >>>> Author(s) : Miguel A. Garcia-Martin >>>> Simo Veikkolainen >>>> Robert R. Gilman >>>> Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>> Pages : 19 >>>> Date : 2012-08-27 >>>> >>>> Abstract: >>>> SDP has been extended with a capability negotiation mechanism >>>> framework that allows the endpoints to negotiate transport protocols >>>> and attributes. This framework has been extended with a media >>>> capabilities negotiation mechanism that allows endpoints to negotiate >>>> additional media-related capabilities. This negotiation is embedded >>>> into the widely-used SDP offer/answer procedures. >>>> >>>> This memo extends the SDP capability negotiation framework to allow >>>> endpoints to negotiate three additional SDP capabilities. In >>>> particular, this memo provides a mechanism to negotiate bandwidth >>>> ('b=' line), connection data ('c=' line), and titles ('i=' line for >>>> each session or media). >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c >>>> aps >>>> >>>> >>>> There's also a htmlized version available at: >>>> >>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >>>> >>>> >>>> A diff from the previous version is available at: >>>> >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-c >>>> aps-01 >>>> >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > . > --------------090802000903060307050706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/1/12 9:28 AM, Cullen Jennings (fluffy) wrote:
I think the issues is how does a manffacture says on a spec sheet that they want support half of it but not all of it. I know that does not matter for 3GPP usage but it sort of useful for others. Clearly this is not a huge technical issues but a small procedural thing so I leave it up to the chairs what they want to do.
I think the draft is pretty clear in not requiring all of it to be implemented, e.g. as described in the Introduction:

<quote>

   Since the three added capabilities are highly unconnected, it is not

   expected that implementations will support all of them at the same

   time.  Instead, it is expected that applications will choose their

   needed capability for their specific purpose.  Due to this, we are

   writing the normative part pertaining to each capability in a self-

   contained section: Section 3.1.1 describes the bandwidth capability

   extension, Section 3.1.2 describes the connection data capability

   extension, and Section 3.1.3 describes the title capability

   extension.  Separate option tags are defined for each capability.
</quote>



and carried through in the main part of the doc itself (btw; there seems to be an error in the "conn-config-list" inasmuch as it does not include the "["+"]" prefix to indicate mandatory extensions).

With the separate option tags in mind, the above text, and also inclusion of the "mandatory" prefix in the various configurations, do you still have concerns around the granularity of the draft ? 


Any thoughts on making the changes so this works in world with more than english? That was my far more relevant comment that is likely to also be raised by IESG.

Can you elaborate on how this differs from the native SDP use of the "i=" field, which is simply being carried over here (maybe there should be some text talking about "a=charset" interactions though, per RFC 4566) ?


Thanks

-- Flemming 


On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia <Miguel.A.Garcia@ericsson.com> wrote:


Cullen,

The draft is written as an independent collection of "objects". This is avoid having three separate drafts.

It is possible to refer to parts of this draft. For example, I believe 3GPP only needs the connection data capability, but not the others, and still they are fine with this draft.

Couldn't the same principle be applied by RTCweb?

/Miguel

On 28/09/2012 17:02, Atle Monrad wrote:

Hi

Is it really necessary to chop the draft up in pieces because others may want to use just parts of it?

I find it more constuctive to finish this draft as is and let other be able to build on and refer to the RFC if and when possible.

/atle

________________________________


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management
Ericsson


-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy)
Sent: 28. september 2012 16:47
To: mmusic WG
Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt


Major comment

I think the title stuff should be split out to a separate draft. The main reason is that you might want to build a dvicd that supported title but did not supper the others and still be able to say what you were doing was RFC X. For example, the RTC Web folks may want to use this.

Given the Title is meant to be human readable, I think it needs to be extended to have normal i18n support.

Cullen



On Sep 6, 2012, at 2:37 PM, Flemming Andreasen <fandreas@cisco.com> wrote:


This is to announce a 2 week Working Group Last Call for

     draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list.


Thanks

       Flemming




Draft Info:
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
                          Robert R. Gilman
	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
	Pages           : 19
	Date            : 2012-08-27

Abstract:
   SDP has been extended with a capability negotiation mechanism
   framework that allows the endpoints to negotiate transport protocols
   and attributes.  This framework has been extended with a media
   capabilities negotiation mechanism that allows endpoints to negotiate
   additional media-related capabilities.  This negotiation is embedded
   into the widely-used SDP offer/answer procedures.

   This memo extends the SDP capability negotiation framework to allow
   endpoints to negotiate three additional SDP capabilities.  In
   particular, this memo provides a mechanism to negotiate bandwidth
   ('b=' line), connection data ('c=' line), and titles ('i=' line for
   each session or media).


The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c
aps


There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01


A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-c
aps-01



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

.

--------------090802000903060307050706-- From miguel.a.garcia@ericsson.com Mon Oct 1 23:56:51 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36321F8B61 for ; Mon, 1 Oct 2012 23:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm7Lv+UCHIZq for ; Mon, 1 Oct 2012 23:56:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56FD821F8AD4 for ; Mon, 1 Oct 2012 23:56:50 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-f0-506a9031cc32 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 12.78.11467.1309A605; Tue, 2 Oct 2012 08:56:49 +0200 (CEST) Received: from [164.48.161.175] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Oct 2012 08:56:48 +0200 Message-ID: <506A9030.1040703@ericsson.com> Date: Tue, 2 Oct 2012 08:56:48 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic References: <505188C7.1080805@ericsson.com> In-Reply-To: <505188C7.1080805@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+Jvra7hhKwAg6eT5S0ebJ/LaPH+gq7F 1OWPWRyYPab83sjqsWTJT6YApigum5TUnMyy1CJ9uwSujEW7trIVnOOouH37MWMD40+2LkZO DgkBE4llK38zQ9hiEhfurQeKc3EICZxilDg97zEzhLOaUeLj3e1ADgcHr4C2xMpfgiANLAIq Eov+LmQFsdkEzCVaN25kB7FFBYIlzm3cBraAV0BQ4uTMJywgtoiAjMTeTZvBljELxEt8PPAI zBYWcJQ42fEfzBYCGv/hyHswm1NAR2Lu4TeMEPW2EhfmXGeBsOUltr+dA1WvKTH55lLmCYyC s5Csm4WkZRaSlgWMzKsYhXMTM3PSyw31Uosyk4uL8/P0ilM3MQJD9uCW37o7GE+dEznEKM3B oiTOy5W0319IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDI5vrh737Us9OLl98vbf/9rWVPVHv Q86LvNFREdJj223bqX5khZCKkhP/zujVcbE6kv0p/caFpllHHSbHMRgYrYxKyN9/QmmPLetE zaZpbseYGTecCmWcUF/yoH9xrtPmf0kam9Zy3t98aMnEqWcL1/ZPOlUXv2x1K7/c7vYv//K1 xZZLHGpyUGIpzkg01GIuKk4EADDYU4wnAgAA Cc: Flemming Andreasen Subject: Re: [MMUSIC] WG Poll for consensus on duplicated streams X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 06:56:51 -0000 This is to conclude the WG poll for consensus on the duplicated streams drafts. We have seen quite a lot of support for this work, so, once we get the appropriate milestones, authors can submit the document as a WG item. /Miguel On 13/09/2012 9:18, Miguel A. Garcia wrote: > At the last IETF meeting we had presentation of two drafts, both > related to the expression of duplicated streams in SDP. We noticed > there was support to progress these drafts. These drafts are > complementary to work going on in AVTEXT, where there is a normative > dependency. > > These are the documents: > > http://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ > http://datatracker.ietf.org/doc/draft-begen-mmusic-temporal-interleaving/ > > We would like to poll the working group for adopting these two > documents as WG items, once we get approved milestones. > > Please indicate whether you support or not this new work within the > next 5 working days. > > Flemming and Miguel (co-chairs). > > /Miguel > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Tue Oct 2 03:28:54 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AAE21F89A2 for ; Tue, 2 Oct 2012 03:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxryIrFz46Yf for ; Tue, 2 Oct 2012 03:28:53 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A294521F8574 for ; Tue, 2 Oct 2012 03:28:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-a5-506ac1d32b49 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 85.48.11467.3D1CA605; Tue, 2 Oct 2012 12:28:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 2 Oct 2012 12:28:34 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Date: Tue, 2 Oct 2012 12:28:33 +0200 Thread-Topic: SDP comments draft-ietf-xrblock-rtcp-xr-delay-09 Thread-Index: Ac2giEdp4m1J5TbxQFCgxtWajNEGvw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A75E65D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A75E65DESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvre7lg1kBBt0zpS3+bZzOYjF1+WMW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvj41H1gqvKFUfv6zYwrpPvYuTkkBAwkei8 cIcNwhaTuHBvPZDNxSEkcIpRYvHG20wQznxGicZN51i7GDk42AQsJLr/aYM0iAioS3zd28MM YjMLFEpsaF4GZrMIqEhs2viIEcQWFrCUOHluGxNEvZ3Eov2zmEDGiAjoScx47AgS5hUIlzhx 9hXYDYxAN3w/tYYJYqS4xK0n85kgbhOQWLLnPDOELSrx8vE/Voh6UYk77esZIerzJeY1XWWF mCkocXLmE5YJjMKzkIyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRODcx Mye93FAvtSgzubg4P0+vOHUTIzBqDm75rbuD8dQ5kUOM0hwsSuK8XEn7/YUE0hNLUrNTUwtS i+KLSnNSiw8xMnFwSjUwzmxNj66rFToUvPN67bYfb9RyWpz+p/Mcb7718I2O3RtLvUIl/o0P TtaG+p49/33CgVfbxBO/x+9TXxZe0Pyd0yL6xsSniwMcMvsZQ0+2F/JGNs4/veSjvKWF9qe3 yw78VNx6lvOak7/5y/ml6hq6D+X3xjZpZIcIXv4ktdVI1p9f0G1H7swoJZbijERDLeai4kQA +swy72gCAAA= Cc: "draft-ietf-xrblock-rtcp-xr-delay-all@tools.ietf.org" Subject: [MMUSIC] SDP comments draft-ietf-xrblock-rtcp-xr-delay-09 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:28:54 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A75E65DESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have been asked to provide comments on draft-ietf-xrblock-rtcp-xr-delay-0= 9, from an "SDP perspective". >From a technical perspective the text looks ok. As the draft extends an exi= sting attribute, I don't think that much text is needed. However, a couple of suggestions which I think would be useful to implement= : Q1: I would suggest to add a subchapter (e.g. "4.1. SDP rtcp-xr-attrib Attr= ibute Extension"), where the extended syntax is defined. Q2: I would suggest to add a subchapter ("4.2 Offer/Answer Usage"), and ind= icate that the SDP Offer/Answer usage defined in RFC 3611 apply. I know it'= s very little text for a new subchapter, but it makes it easier to find the= information. Thanks! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A75E65DESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I= have been asked to provide comments on draft-ietf-xrblock-rtcp-xr-delay-09= , from an "SDP perspective".

 

From a technical perspective th= e text looks ok. As the draft extends an existing attribute, I don’t = think that much text is needed.

&nb= sp;

However, a couple of suggestions which I = think would be useful to implement:

 

Q1: I would suggest to add a subchapt= er (e.g. “4.1. SDP rtcp-xr-attrib Attribute Extension”), where = the extended syntax is defined.

&nb= sp;

Q2: I would suggest to add a subchapter (= “4.2 Offer/Answer Usage”), and indicate that the SDP Offer/Answ= er usage defined in RFC 3611 apply. I know it’s very little text for = a new subchapter, but it makes it easier to find the information.

 

Thanks!=

 

Regards,

 

Christer

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A75E65DESESSCMS0356e_-- From christer.holmberg@ericsson.com Tue Oct 2 03:30:34 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08821F8AD7 for ; Tue, 2 Oct 2012 03:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NznjAfg0agjU for ; Tue, 2 Oct 2012 03:30:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 54FC821F8AD5 for ; Tue, 2 Oct 2012 03:30:33 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-dc-506ac24833f8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D0.07.17130.842CA605; Tue, 2 Oct 2012 12:30:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 2 Oct 2012 12:30:32 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Date: Tue, 2 Oct 2012 12:30:30 +0200 Thread-Topic: SDP comments draft-ietf-xrblock-rtcp-xr-delay-09 Thread-Index: Ac2giEdp4m1J5TbxQFCgxtWajNEGvwAAH7CA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A75E666@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A75E666ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvra7HoawAg5On+C0mvmG2mLr8MYvF 3NvMDsweLUfesnosWfKTyePY/HOMAcxRXDYpqTmZZalF+nYJXBlntlYXXNKp2N3xgqmB8YB6 FyMnh4SAicT6L3eYIGwxiQv31rN1MXJxCAmcYpQ4t3sTK4Qzn1Fix9onQBkODjYBC4nuf9og DSIC6hJf9/Ywg9jMAlkS1x6fYgUpYRFQkejelAwSFhawlXh48wgLRLmdxKL9s5ggbCOJF9eX gdm8AuESLbcfMYLYjEA3fD+1hglipLjErSfzoW4TkFiy5zwzhC0q8fLxP1aIelGJO+3rGSHq 8yXWrFnLAjFTUOLkzCcsExiFZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6A kX0Vo3BuYmZOerm5XmpRZnJxcX6eXnHqJkZgHB3c8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYNzX9uvWUof7Z/ZVMDYX7uc37uppndrya/8Mq1v6Z9/F 6gkEFHxfbbDMSlKa9YLb35oeD4WossqXntF746YssmM3vXlmpeEcsV0sCn+O8m9qMFvgY97X ZqQZfbmFV3JFX32u8SO+GeKeghVxYapmN7cxmblpbQ6Uta8/dOHLj6liZ7xuBV87pcRSnJFo qMVcVJwIADO0yUpxAgAA Cc: "sunseawq@huawei.com" , "alan.d.clark@telchemy.com" Subject: Re: [MMUSIC] SDP comments draft-ietf-xrblock-rtcp-xr-delay-09 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:30:34 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A75E666ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft authors included. From: Christer Holmberg Sent: 2. lokakuuta 2012 13:29 To: mmusic@ietf.org Cc: 'draft-ietf-xrblock-rtcp-xr-delay-all@tools.ietf.org' Subject: SDP comments draft-ietf-xrblock-rtcp-xr-delay-09 Hi, I have been asked to provide comments on draft-ietf-xrblock-rtcp-xr-delay-0= 9, from an "SDP perspective". >From a technical perspective the text looks ok. As the draft extends an exi= sting attribute, I don't think that much text is needed. However, a couple of suggestions which I think would be useful to implement= : Q1: I would suggest to add a subchapter (e.g. "4.1. SDP rtcp-xr-attrib Attr= ibute Extension"), where the extended syntax is defined. Q2: I would suggest to add a subchapter ("4.2 Offer/Answer Usage"), and ind= icate that the SDP Offer/Answer usage defined in RFC 3611 apply. I know it'= s very little text for a new subchapter, but it makes it easier to find the= information. Thanks! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A75E666ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft authors included.

 

From: Christer Holmberg
Sent: 2. lokakuuta = 2012 13:29
To: mmusic@ietf.org
Cc: 'draft-ietf-xrblock-= rtcp-xr-delay-all@tools.ietf.org'
Subject: SDP comments draft-iet= f-xrblock-rtcp-xr-delay-09

 

Hi,

 

I have been = asked to provide comments on draft-ietf-xrblock-rtcp-xr-delay-09, from an &= quot;SDP perspective".

&nbs= p;

From a technical perspective the text look= s ok. As the draft extends an existing attribute, I don’t think that = much text is needed.

 

However, a couple of suggestions which I think would= be useful to implement:

 

Q1: I would suggest to add a subchapter (e.g. &#= 8220;4.1. SDP rtcp-xr-attrib Attribute Extension”), where the extende= d syntax is defined.

 

Q2: I would suggest to add a subchapter (“4.2 = Offer/Answer Usage”), and indicate that the SDP Offer/Answer usage de= fined in RFC 3611 apply. I know it’s very little text for a new subch= apter, but it makes it easier to find the information.

 

Thanks!=

 

Regards,=

 

Christer

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A75E666ESESSCMS0356e_-- From internet-drafts@ietf.org Tue Oct 2 09:30:17 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F95E21F84B5; Tue, 2 Oct 2012 09:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9T79qKeX9DW; Tue, 2 Oct 2012 09:30:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD98821F8525; Tue, 2 Oct 2012 09:30:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121002163016.8437.72763.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 09:30:16 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-media-capabilities-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:30:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Media Capabilities Ne= gotiation Author(s) : Robert R Gilman Roni Even Flemming Andreasen Filename : draft-ietf-mmusic-sdp-media-capabilities-15.txt Pages : 63 Date : 2012-10-02 Abstract: Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This document updates the IANA Considerations of RFC 5939. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-media-capabilities There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-media-capabilities= -15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fluffy@cisco.com Thu Oct 4 15:29:54 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFDD1F041E for ; Thu, 4 Oct 2012 15:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny2uOlncD4vL for ; Thu, 4 Oct 2012 15:29:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id EA3E121F8545 for ; Thu, 4 Oct 2012 15:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5698; q=dns/txt; s=iport; t=1349389792; x=1350599392; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xv7IsRmmvRRRmRrbdTWhwKyiNC1+vvNpQU+uZlTKDb4=; b=BYibqwDHvzBoViBsMAEH6vI0Zs4nkTEOXbRah722TK7yDLGmn3FDU8Wi rhSYluvH1BbpV5+lmFbzpkIci0J3UTl1qprek82jbo2oLwKL4cFLAAqQA GDpS5mi70IW0fPMp8frh5q6QuE7Ek9NIz0GHqNdKNjRkF1yDJK39wtPIi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIgMblCtJV2a/2dsb2JhbABFvxaBCIIgAQEBAwESAVQSDAQCAQgRBAEBAQodBzIUCQgCBA4FCBqHXQaYHKAOiz6FPWADiCOcCYFpgm2BYzQ X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="128472701" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 04 Oct 2012 22:29:51 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q94MTpUQ009597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 22:29:51 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 17:29:51 -0500 From: "Cullen Jennings (fluffy)" To: "Flemming Andreasen (fandreas)" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNon/EzvYQ0M0yoEetRSqhZQoPGQ== Date: Thu, 4 Oct 2012 22:29:50 +0000 Message-ID: References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> <5066A49F.2040002@ericsson.com> <506A49D4.40102@cisco.com> In-Reply-To: <506A49D4.40102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--52.815700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <46F45E3EE39B8E489B0602D1B51F5F0F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic WG , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:29:54 -0000 On Oct 1, 2012, at 7:56 PM, Flemming Andreasen wrote: >=20 > On 10/1/12 9:28 AM, Cullen Jennings (fluffy) wrote: >> I think the issues is how does a manffacture says on a spec sheet that t= hey want support half of it but not all of it. I know that does not matter = for 3GPP usage but it sort of useful for others. Clearly this is not a huge= technical issues but a small procedural thing so I leave it up to the chai= rs what they want to do.=20 > I think the draft is pretty clear in not requiring all of it to be implem= ented, e.g. as described in the Introduction: >=20 > > Since the three added capabilities are highly unconnected, it is not > expected that implementations will support all of them at the same > time. Instead, it is expected that applications will choose their > needed capability for their specific purpose. Due to this, we are > writing the normative part pertaining to each capability in a self- > contained section: Section 3.1.1 describes the bandwidth capability > extension, Section 3.1.2 describes the connection data capability > extension, and Section 3.1.3 describes the title capability > extension. Separate option tags are defined for each capability. > >=20 >=20 > and carried through in the main part of the doc itself (btw; there seems = to be an error in the "conn-config-list" inasmuch as it does not include th= e "["+"]" prefix to indicate mandatory extensions).=20 >=20 > With the separate option tags in mind, the above text, and also inclusion= of the "mandatory" prefix in the various configurations, do you still have= concerns around the granularity of the draft ?=20 The upside of combining these are roughly, as Miguel said in his email, we = can combine multiple random small stuff into one draft. The downside is tha= t if you do half some but not all of them, you can't say you implement RFC = 1234. Personally, I don't see that reviewing it in one draft is greatly sim= pler than a few drafts but really, this is not a big deal to me. As long as= the MMUSIC WG if fine with the RTCWeb WG having drafts that say do part o= f RFC XXXX, but not all of it - I don't see any problem with leaving it all= in one draft. If there not OK with that, then we need split it apart but i= t sounds like folks are fine with keeping it as one.=20 >=20 >>=20 >> Any thoughts on making the changes so this works in world with more than= english? That was my far more relevant comment that is likely to also be r= aised by IESG. >>=20 >>=20 >=20 > Can you elaborate on how this differs from the native SDP use of the "i= =3D" field, which is simply being carried over here (maybe there should be = some text talking about "a=3Dcharset" interactions though, per RFC 4566) ?= =20 The "i=3D" field was defined before the IETF was trying to seriously suppor= t i18n and there is no easy backwards compatible way to fix it. Also, the "= i=3D" is more or less not used. This is a bit different - it's new and peop= le are saying it would be used by 3GPP.=20 Making it support multiple languages would probably not be hard - you could= do it with a set of strings where each string also had a language tag and = the strings were UTF8 then encoded with base64 to represent them in SDP.=20 Given then is meant to be read by humans, why wouldn't you make it so it ca= n be read by human.=20 >=20 >=20 > Thanks=20 >=20 > -- Flemming=20 >=20 >>=20 >> On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia=20 >> >> wrote: >>=20 >>=20 >>> Cullen, >>>=20 >>> The draft is written as an independent collection of "objects". This is= avoid having three separate drafts. >>>=20 >>> It is possible to refer to parts of this draft. For example, I believe = 3GPP only needs the connection data capability, but not the others, and sti= ll they are fine with this draft. >>>=20 >>> Couldn't the same principle be applied by RTCweb? >>>=20 >>> /Miguel >>>=20 >>> On 28/09/2012 17:02, Atle Monrad wrote: >>>=20 >>>> Hi >>>>=20 >>>> Is it really necessary to chop the draft up in pieces because others m= ay want to use just parts of it? >>>>=20 >>>> I find it more constuctive to finish this draft as is and let other be= able to build on and refer to the RFC if and when possible. >>>>=20 >>>> /atle >>>>=20 >>>> ________________________________ >>>>=20 >>>>=20 >>>> Atle Monrad >>>> 3GPP CT Chairman >>>> Standardization and Regulation, >>>> Group Function Technology and Portfolio Management >>>> Ericsson >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From:=20 >>>> mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org >>>> ] On Behalf Of Cullen Jennings (fluffy) >>>> Sent: 28. september 2012 16:47 >>>> To: mmusic WG >>>> Cc: Flemming Andreasen (fandreas);=20 >>>> draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org >>>>=20 >>>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-cap= s-01.txt >>>>=20 >>>>=20 >>>> Major comment >>>>=20 >>>> I think the title stuff should be split out to a separate draft. The m= ain reason is that you might want to build a dvicd that supported title but= did not supper the others and still be able to say what you were doing was= RFC X. For example, the RTC Web folks may want to use this. >>>>=20 >>>> Given the Title is meant to be human readable, I think it needs to be = extended to have normal i18n support. >>>>=20 >>>> Cullen >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen=20 >>>> >>>> wrote: From fluffy@cisco.com Thu Oct 4 15:29:58 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F651F0425 for ; Thu, 4 Oct 2012 15:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.507 X-Spam-Level: X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2axvgivN2S9e for ; Thu, 4 Oct 2012 15:29:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 269E71F0424 for ; Thu, 4 Oct 2012 15:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7912; q=dns/txt; s=iport; t=1349389797; x=1350599397; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zptHOiA/kVMoQxMMCqkeY1h9j5HNflWxAoYp5t1Qv/I=; b=YhF/ABOPJg9EcDkQxzzqIag37rxjeeoIxW8M6IfqRSuCMXKvm+jt2TAu WKtgXszjkv2FV9xN80JmUQtwixNglFuvuTr21CvWvnU2BHhlJVxCF81I+ SHDPR+LG+uxn+b++7jQL5am6Ai7vO4elWb19hu0miI5aRXcufR10U64o3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPEMblCtJV2Z/2dsb2JhbAA7Cr8XgQiCIAEBAQMBAQEBDwEKHTQLDAQCAQgOAwQBAQEKFAkHJwsUCQgCBA4FCAEZh10GC5gRoA2LPhCFLWADln6NLoFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="125472263" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 04 Oct 2012 22:29:46 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q94MTk3u010007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 22:29:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 17:29:46 -0500 From: "Cullen Jennings (fluffy)" To: Andrew Allen Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNon/BXApv78grPUyVmogj+v8d8g== Date: Thu, 4 Oct 2012 22:29:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--55.719200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <86B833A9C45A11439E3AE0576ADBCA89@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:29:58 -0000 On Oct 1, 2012, at 12:07 PM, Andrew Allen wrote: >=20 > I think it is possible. The statement just needs to identify the sections= of the draft or functionality suppported - this is quite common practice i= n the industry. >=20 > Maybe rather than a last minute delay to this work the best approach woul= d be for another draft to be written under RTCweb that specifies the SDP ex= tensons needed for RTCweb (is the title capability really the only one?) - = a kind of RTCweb hitchikers guide for SDP and then vendors can claim compli= ance to that. >=20 > Andrew OK, as long a the folks in the music WG view that as reasonable thing for m= e to do, I'll submit something. >=20 > ----- Original Message ----- > From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Sent: Monday, October 01, 2012 08:28 AM Central Standard Time > To: Miguel A. Garcia > Cc: Flemming Andreasen (fandreas) ; mmusic WG ; draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org > Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-0= 1.txt >=20 >=20 > I think the issues is how does a manffacture says on a spec sheet that th= ey want support half of it but not all of it. I know that does not matter f= or 3GPP usage but it sort of useful for others. Clearly this is not a huge = technical issues but a small procedural thing so I leave it up to the chair= s what they want to do.=20 >=20 > Any thoughts on making the changes so this works in world with more than = english? That was my far more relevant comment that is likely to also be ra= ised by IESG. >=20 >=20 >=20 > On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia wrote: >=20 >> Cullen, >>=20 >> The draft is written as an independent collection of "objects". This is = avoid having three separate drafts. >>=20 >> It is possible to refer to parts of this draft. For example, I believe 3= GPP only needs the connection data capability, but not the others, and stil= l they are fine with this draft. >>=20 >> Couldn't the same principle be applied by RTCweb? >>=20 >> /Miguel >>=20 >> On 28/09/2012 17:02, Atle Monrad wrote: >>> Hi >>>=20 >>> Is it really necessary to chop the draft up in pieces because others ma= y want to use just parts of it? >>>=20 >>> I find it more constuctive to finish this draft as is and let other be = able to build on and refer to the RFC if and when possible. >>>=20 >>> /atle >>>=20 >>> ________________________________ >>>=20 >>>=20 >>> Atle Monrad >>> 3GPP CT Chairman >>> Standardization and Regulation, >>> Group Function Technology and Portfolio Management >>> Ericsson >>>=20 >>>=20 >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behal= f Of Cullen Jennings (fluffy) >>> Sent: 28. september 2012 16:47 >>> To: mmusic WG >>> Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-= caps@tools.ietf.org >>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps= -01.txt >>>=20 >>>=20 >>> Major comment >>>=20 >>> I think the title stuff should be split out to a separate draft. The ma= in reason is that you might want to build a dvicd that supported title but = did not supper the others and still be able to say what you were doing was = RFC X. For example, the RTC Web folks may want to use this. >>>=20 >>> Given the Title is meant to be human readable, I think it needs to be e= xtended to have normal i18n support. >>>=20 >>> Cullen >>>=20 >>>=20 >>>=20 >>> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wro= te: >>>=20 >>>> This is to announce a 2 week Working Group Last Call for >>>>=20 >>>> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>>=20 >>>> as Proposed Standard. Please review and provide any comments you may h= ave on the document by September 21, 2012. Comments should be sent to the d= ocument authors and the MMUSIC WG list. >>>>=20 >>>>=20 >>>> Thanks >>>>=20 >>>> Flemming >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Draft Info: >>>> This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. >>>>=20 >>>> Title : Miscellanoues Capabilities Negotiation in the Sessi= on Description Protocol (SDP) >>>> Author(s) : Miguel A. Garcia-Martin >>>> Simo Veikkolainen >>>> Robert R. Gilman >>>> Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>> Pages : 19 >>>> Date : 2012-08-27 >>>>=20 >>>> Abstract: >>>> SDP has been extended with a capability negotiation mechanism >>>> framework that allows the endpoints to negotiate transport protocols >>>> and attributes. This framework has been extended with a media >>>> capabilities negotiation mechanism that allows endpoints to negotiat= e >>>> additional media-related capabilities. This negotiation is embedded >>>> into the widely-used SDP offer/answer procedures. >>>>=20 >>>> This memo extends the SDP capability negotiation framework to allow >>>> endpoints to negotiate three additional SDP capabilities. In >>>> particular, this memo provides a mechanism to negotiate bandwidth >>>> ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' lin= e for >>>> each session or media). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c >>>> aps >>>>=20 >>>>=20 >>>> There's also a htmlized version available at: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >>>>=20 >>>>=20 >>>> A diff from the previous version is available at: >>>>=20 >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous= -c >>>> aps-01 >>>>=20 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>>=20 >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 >> --=20 >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Fri Oct 5 05:28:36 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C111E21F8496; Fri, 5 Oct 2012 05:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bxnrNTEYfJc; Fri, 5 Oct 2012 05:28:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E6A3C21F846D; Fri, 5 Oct 2012 05:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4750; q=dns/txt; s=iport; t=1349440116; x=1350649716; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=82X8XN0T1Fx75ATY/XDPCJoLZOrmkNsjaQkk+ORFspA=; b=fqRRq5Z3sxUgfxRxUaJToX9isXihWGPDx9Gh/9+bf9PaYk7pm+6jxc/1 e3xRcPLhOH4gsF82drkGcz3zsQA/FGHbL3+56dEBulvEwhRZPqkLoaIkU pIf6cLvF8Q6ocQ6/31SZmQYers9ohulO4MrXnO8v5SJdTvvZ7PJ9zTZYj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMHRblCtJXG+/2dsb2JhbABFvx6BCIIiAQQSASc/EgEqFEIfCAQBDQ0TB4djmDqgCJBnYAOXAI0wgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="125640566" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2012 12:28:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q95CSZ0W019845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 12:28:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 07:28:34 -0500 From: "Cullen Jennings (fluffy)" To: mmusic WG , "Cullen Jennings (fluffy)" , Harald Tveit Alvestrand , "Justin Uberti" , Eric Rescorla , Christer Holmberg , Bernard Aboba , Jonathan Lennox , Randell Jesup Thread-Topic: path forward on bundle Thread-Index: AQHNovTwIf3O/3MMMESi6UaijuNjfw== Date: Fri, 5 Oct 2012 12:28:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--37.820000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: [MMUSIC] path forward on bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:28:36 -0000 I'm trying to figure out how to move forward on bundle stuff. Let me start = by summarizing what I think the three proposals are then we can try and sor= t out pros/cons of each. I think we agree that the goals here is to have so= mething that gets the SDP so that we can negotiate using less ports.=20 I see it as we have three proposed solutions that I will call "a=3Dbundle s= ame port", "a=3Dbundle different port", and "m=3Dbundle". I'll try and des= cribe these below to make sure we are on same page of what the three are th= en we can try and figurer out pros/cons of each and what to do. I'll give e= xamples of the SDP offer for each but I tried and make everything simple, I= 'm going to ignore the RTCP mux and such but I think you can see how that w= ould get added to all the examples.=20 First lets set the baseline of an offer that does not want to multiplex the= audio and video on same port=20 v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 m=3Daudio 49170 RTP/AVP 0=20 a=3Dmid:foo a=3Drtpmap:0 PCMU/8000 m=3Dvideo 49172 RTP/AVP 31=20 a=3Dmid:bar a=3Drtpmap:31 H261/90000 Proposal "a=3Dbundle same port" v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 49170 RTP/AVP 0=20 a=3Dmid:foo a=3Drtpmap:0 PCMU/8000 m=3Dvideo 49170 RTP/AVP 31=20 a=3Dmid:bar a=3Drtpmap:31 H261/90000 In the above example, note that all the m lines for a mid identified in the= group:BUNLDE have the same port (49170) Proposal "a=3Dbundle different port" v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 a=3Dgroup:BUNDLE foo bar m=3Daudio 49170 RTP/AVP 0=20 a=3Dmid:foo a=3Drtpmap:0 PCMU/8000 m=3Dvideo 49172 RTP/AVP 31=20 a=3Dmid:bar a=3Drtpmap:31 H261/90000 In the above example, note that the port numbers are the same as baseline -= if you device receiving this offer does not support group:BUNLDE, then thi= s is identical to the baseline. So one m line has a port of 49170 and the o= ther has a different port. Other than that, it is the same as the "a=3Dbund= le same port". The semantics of group:BUNLDE would be defined to be that if= the SDP receiver supports BUNDLE and wants to use it, then it places a gro= up:BUNDLE line in the answer and it send all the media to the mids in the i= n BUNDLE group to the port number identified for the m-line corresponding t= o the first mid in the BUNDLE group. In this example, the first mid on the = a=3Dgroup:BUNDLE lines is foo, which has a m line with a port of 49170, so = both the H261 and PCMU (mids foo and bar) would go to port 49170 if the dev= ice creating the answer wanted to use BUNDLE. We don't have a draft yet tha= t says exactly this thought it is very close to the one-rtp draft ( and for= that matter close to bundle draft ) Proposal "m=3Dbundle" v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 a=3Dgroup:BUNDLE foo bar baz=20 m=3Daudio 49170 RTP/AVP 0=20 a=3Dmid:foo a=3Drtpmap:0 PCMU/8000 m=3Dvideo 49172 RTP/AVP 31=20 a=3Dmid:bar a=3Drtpmap:31 H261/90000 m=3Dbundle 10000 RTP/AVP 0 8 97 31 32 a=3Dmid:baz a=3Dfull-rtpmap:0 audio/PCMU/8000 a=3Dfull-rtpmap:31 video/H261/90000 Note in the above example the SDP above the m=3Dbundle line is pretty much = the same as the baseline + the group:BUNDLE line. The m=3Dbundle is new med= ia type that indicates many things are bundled together on port 10000. A de= vice that understood bundle would know to ignore the m lines corresponding = to foo and bar mids and would just use the stuff from the bas mid.=20 So before we start discussing the pros / cons of theses three approaches, l= et's spend a few days and make sure that I have correctly characterized the= three approaches under discussion.=20 Did I get it right? Do we need more explanation of any of these to see how = they work?=20 Lets keep clarifications only on this thread and I'll start a separate thre= ad for pro/cons once we get this a bit clearer.=20 From christer.holmberg@ericsson.com Fri Oct 5 05:41:45 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5D21F8645; Fri, 5 Oct 2012 05:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2fTsBDAm+-U; Fri, 5 Oct 2012 05:41:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDF621F8630; Fri, 5 Oct 2012 05:41:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-c4-506ed5866dc6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 32.83.17130.685DE605; Fri, 5 Oct 2012 14:41:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 5 Oct 2012 14:41:42 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , mmusic WG , Harald Tveit Alvestrand , Justin Uberti , Eric Rescorla , Bernard Aboba , Jonathan Lennox , Randell Jesup Date: Fri, 5 Oct 2012 14:41:40 +0200 Thread-Topic: path forward on bundle Thread-Index: AQHNovTwIf3O/3MMMESi6UaijuNjf5eqpRiw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A7BD37B@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+JvrW7b1bwAg32XpC32L7nMbLHi9Tl2 i47JbBbH+rrYLPYvPs9ssXWqkMXU5Y9ZLDZ9OchssfZfO7sDp8eVCVdYPab83sjqsWBTqcfj njNsHkuW/GTy6DvQxeox+XEbs0fbszvsARxRXDYpqTmZZalF+nYJXBl9W5uZCharVpzbM4Ol gbFLuouRk0NCwERiXsNbNghbTOLCvfVANheHkMApRokZF89COfMZJRZcWcbSxcjBwSZgIdH9 TxskLiKwl0li0vHbjCDdzALqEncWn2MHsVkEVCQuzLrEDGILA9k3+jrBakQEVCUeLL3OAmEb SbyZf5YVxOYVCJe48/YoWI2QgI/Erj/nwWo4BXwl9j3qBYszAl33/dQaJohd4hK3nsxngrha QGLJnvPMELaoxMvH/1gh6kUl7rSvh7pNR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo9gsJGNn IWmZhaRlFpKWBYwsqxiFcxMzc9LLzfVSizKTi4vz8/SKUzcxAiP34JbfBjsYN90XO8QozcGi JM6rp7rfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj8+KStYJquaeluwNyix133DjO7+J+ vbtWeWPefB/mhasEHCq5e31UChNdtTLFe46dUPCfx10z7Y/rzaN5m0oEZ0yftn06T6KVz5q2 vz+dA75qLD1mJNVhubXsxv/+Dywfahbe2tnYv4x1ooDI1DdNmYp8PlPkF8fVK/KYZU/YxLC4 +MHqA2VKLMUZiYZazEXFiQAEuMcCqgIAAA== Cc: "rtcweb@ietf.org" Subject: Re: [MMUSIC] path forward on bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:41:45 -0000 Hi, >I'm trying to figure out how to move forward on bundle stuff. Let me start= by summarizing what I think the three proposals are then we can try and so= rt out pros/cons of each. I think we agree that the goals here is to have s= omething that gets the SDP so=20 >that we can negotiate using less ports.=20 > >I see it as we have three proposed solutions that I will call "a=3Dbundle = same port", "a=3Dbundle different port", and "m=3Dbundle". I'll try and de= scribe these below to make sure we are on same page of what the three are t= hen we can try and figurer out=20 >pros/cons of each and what to do. I'll give examples of the SDP offer for = each but I tried and make everything simple, I'm going to ignore the RTCP m= ux and such but I think you can see how that would get added to all the exa= mples.=20 > > >First lets set the baseline of an offer that does not want to multiplex th= e audio and video on same port=20 > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 0=20 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31=20 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 Correct. >Proposal "a=3Dbundle same port" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar > m=3Daudio 49170 RTP/AVP 0=20 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49170 RTP/AVP 31=20 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > > In the above example, note that all the m lines for a mid identified in t= he group:BUNLDE have the same port (49170) Correct. This is what is currently described in draft-bundle. >Proposal "a=3Dbundle different port" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar > m=3Daudio 49170 RTP/AVP 0=20 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31=20 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > In the above example, note that the port numbers are the same as baseline= - if you device receiving this offer does not support group:BUNLDE, then t= his is identical to the baseline. So one m line has a port of 49170 and the= other has a different port.=20 > Other than that, it is the same as the "a=3Dbundle same port". The semant= ics of group:BUNLDE would be defined to be that if the SDP receiver support= s BUNDLE and wants to use it, then it places a group:BUNDLE line in the ans= wer and it send all the media=20 > to the mids in the in BUNDLE group to the port number identified for the = m-line corresponding to the first mid in the BUNDLE group. In this example,= the first mid on the a=3Dgroup:BUNDLE lines is foo, which has a m line wit= h a port of 49170, so both the=20 > H261 and PCMU (mids foo and bar) would go to port 49170 if the device cre= ating the answer wanted to use BUNDLE. We don't have a draft yet that says = exactly this thought it is very close to the one-rtp draft ( and for that m= atter close to bundle draft ) This is more or less Harald's original proposal. >Proposal "m=3Dbundle" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar baz=20 > m=3Daudio 49170 RTP/AVP 0=20 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31=20 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > m=3Dbundle 10000 RTP/AVP 0 8 97 31 32 > a=3Dmid:baz > a=3Dfull-rtpmap:0 audio/PCMU/8000 > a=3Dfull-rtpmap:31 video/H261/90000 > > > Note in the above example the SDP above the m=3Dbundle line is pretty muc= h the same as the baseline + the group:BUNDLE line. The m=3Dbundle is new m= edia type that indicates many things are bundled together on port 10000. A = device that understood=20 > bundle would know to ignore the m lines corresponding to foo and bar mids= and would just use the stuff from the bas mid.=20 Correct. Later today, we are planning to submit an individual draft (ie *no= t* a new version of draft-bundle) on this alternative, so that people have = some text to look at. Regards, Christer From harald@alvestrand.no Fri Oct 5 05:55:41 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DAF21F86DF; Fri, 5 Oct 2012 05:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.324 X-Spam-Level: X-Spam-Status: No, score=-109.324 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpGAktS2lfL3; Fri, 5 Oct 2012 05:55:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BE06A21F86DC; Fri, 5 Oct 2012 05:55:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFC4539E1D0; Fri, 5 Oct 2012 14:55:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVh3vnGAf-8X; Fri, 5 Oct 2012 14:55:33 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4589A39E1BD; Fri, 5 Oct 2012 14:55:33 +0200 (CEST) Message-ID: <506ED8C4.6080409@alvestrand.no> Date: Fri, 05 Oct 2012 14:55:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Jonathan Lennox , mmusic WG , Randell Jesup , Christer Holmberg , "rtcweb@ietf.org" Subject: Re: [MMUSIC] path forward on bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 12:55:41 -0000 On 10/05/2012 02:28 PM, Cullen Jennings (fluffy) wrote: > I'm trying to figure out how to move forward on bundle stuff. Let me st= art by summarizing what I think the three proposals are then we can try a= nd sort out pros/cons of each. I think we agree that the goals here is to= have something that gets the SDP so that we can negotiate using less por= ts. > > I see it as we have three proposed solutions that I will call "a=3Dbund= le same port", "a=3Dbundle different port", and "m=3Dbundle". I'll try a= nd describe these below to make sure we are on same page of what the thre= e are then we can try and figurer out pros/cons of each and what to do. I= 'll give examples of the SDP offer for each but I tried and make everythi= ng simple, I'm going to ignore the RTCP mux and such but I think you can = see how that would get added to all the examples. > > > First lets set the baseline of an offer that does not want to multiplex= the audio and video on same port > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.c= om > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > m=3Daudio 49170 RTP/AVP 0 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > > > > Proposal "a=3Dbundle same port" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.c= om > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar > m=3Daudio 49170 RTP/AVP 0 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49170 RTP/AVP 31 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > > In the above example, note that all the m lines for a mid identified in= the group:BUNLDE have the same port (49170) No issue so far. > > > > Proposal "a=3Dbundle different port" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.c= om > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar > m=3Daudio 49170 RTP/AVP 0 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > > In the above example, note that the port numbers are the same as baseli= ne - if you device receiving this offer does not support group:BUNLDE, th= en this is identical to the baseline. So one m line has a port of 49170 a= nd the other has a different port. Other than that, it is the same as the= "a=3Dbundle same port". The semantics of group:BUNLDE would be defined t= o be that if the SDP receiver supports BUNDLE and wants to use it, then i= t places a group:BUNDLE line in the answer and it send all the media to t= he mids in the in BUNDLE group to the port number identified for the m-li= ne corresponding to the first mid in the BUNDLE group. In this example, t= he first mid on the a=3Dgroup:BUNDLE lines is foo, which has a m line wit= h a port of 49170, so both the H261 and PCMU (mids foo and bar) would go = to port 49170 if the device creating the answer wanted to use BUNDLE. We = don't have a draft yet that says exactly this thought it is very close to= the one-rtp draft ( and for that matter close to bundle draft ) I believe this is the mechanism described in=20 draft-alvestrand-one-rtp-02, or at least what it was intended to say. So = we can use the name "a=3Dgroup:together" for this without risk of confusi= on. > > > > Proposal "m=3Dbundle" > v=3D0 > o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.c= om > s=3D > c=3DIN IP4 host.atlanta.example.com > t=3D0 0 > a=3Dgroup:BUNDLE foo bar baz > m=3Daudio 49170 RTP/AVP 0 > a=3Dmid:foo > a=3Drtpmap:0 PCMU/8000 > m=3Dvideo 49172 RTP/AVP 31 > a=3Dmid:bar > a=3Drtpmap:31 H261/90000 > m=3Dbundle 10000 RTP/AVP 0 8 97 31 32 > a=3Dmid:baz > a=3Dfull-rtpmap:0 audio/PCMU/8000 > a=3Dfull-rtpmap:31 video/H261/90000 > > > Note in the above example the SDP above the m=3Dbundle line is pretty m= uch the same as the baseline + the group:BUNDLE line. The m=3Dbundle is n= ew media type that indicates many things are bundled together on port 100= 00. A device that understood bundle would know to ignore the m lines corr= esponding to foo and bar mids and would just use the stuff from the bas m= id. Yep. I've suggested calling it "m=3Danytype", but Christer hasn't adopted= =20 that so far :-) > > > So before we start discussing the pros / cons of theses three approache= s, let's spend a few days and make sure that I have correctly characteriz= ed the three approaches under discussion. > > Did I get it right? Do we need more explanation of any of these to see = how they work? > > Lets keep clarifications only on this thread and I'll start a separate = thread for pro/cons once we get this a bit clearer. Remember to change the subject line to a descriptive one for the next=20 thread :-) > > > > > > > > > From fluffy@cisco.com Fri Oct 5 11:49:01 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B71F21F8528; Fri, 5 Oct 2012 11:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.319 X-Spam-Level: X-Spam-Status: No, score=-109.319 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZlPNSBCkrBp; Fri, 5 Oct 2012 11:49:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3EE21F842B; Fri, 5 Oct 2012 11:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6668; q=dns/txt; s=iport; t=1349462940; x=1350672540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=REi2TERZC8kt9jiJM/IvIFuXEiIajqTLrvsHr5Y+kl0=; b=hhxtdlFSrxdIGsLcpILzlt+PyziHIhluhytS7uPi5FLuDOVW5QyYqIxL s9jDngLXEBBfORr/jZx3dzG8i/TkCptuOQmtxdT2zkaGZ7WgQqynFbbTG XOaF0h0dr1JZOVXodpuhau904IuZN9IxsdjAwd92uyzYJtXPn8WrlYcJl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGUqb1CtJXG9/2dsb2JhbABFvyCBCIIgAQEBBAEBAQ8BWwsQAgEIGAokIQYLJQIEDgUIEweHUQMPC5heljANiVSKWGaFKWADiCOLc4Jqig6DIoFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128819004" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 05 Oct 2012 18:49:00 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q95ImxYs027533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 18:48:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 13:48:59 -0500 From: "Cullen Jennings (fluffy)" To: Kaiduan Xie Thread-Topic: [rtcweb] path forward on bundle Thread-Index: AQHNoyaEp4nhhdwyxEuzOdZlbOlWD5erYa2A Date: Fri, 5 Oct 2012 18:48:59 +0000 Message-ID: References: <506ED8C4.6080409@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--58.071700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <483558E4CF5F74448414E1D3F1C4175E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , Randell Jesup , mmusic WG , Jonathan Lennox Subject: Re: [MMUSIC] [rtcweb] path forward on bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:49:01 -0000 On Oct 5, 2012, at 12:23 PM, Kaiduan Xie wrote: > "Note in the above example the SDP above the m=3Dbundle line is pretty > much the same as the baseline + the group:BUNDLE line. The m=3Dbundle is > new media type that indicates many things are bundled together on port > 10000. A device that understood bundle would know to ignore the m > lines corresponding to foo and bar mids and would just use the stuff > from the bas mid." > ^^^ >=20 > Should it be baz mid? oops - yes - that should be baz , sorry >=20 > /Kaiduan >=20 > On Fri, Oct 5, 2012 at 8:55 AM, Harald Alvestrand = wrote: >> On 10/05/2012 02:28 PM, Cullen Jennings (fluffy) wrote: >>>=20 >>> I'm trying to figure out how to move forward on bundle stuff. Let me st= art >>> by summarizing what I think the three proposals are then we can try and= sort >>> out pros/cons of each. I think we agree that the goals here is to have >>> something that gets the SDP so that we can negotiate using less ports. >>>=20 >>> I see it as we have three proposed solutions that I will call "a=3Dbund= le >>> same port", "a=3Dbundle different port", and "m=3Dbundle". I'll try an= d >>> describe these below to make sure we are on same page of what the three= are >>> then we can try and figurer out pros/cons of each and what to do. I'll = give >>> examples of the SDP offer for each but I tried and make everything simp= le, >>> I'm going to ignore the RTCP mux and such but I think you can see how t= hat >>> would get added to all the examples. >>>=20 >>>=20 >>> First lets set the baseline of an offer that does not want to multiplex >>> the audio and video on same port >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.co= m >>> s=3D >>> c=3DIN IP4 host.atlanta.example.com >>> t=3D0 0 >>> m=3Daudio 49170 RTP/AVP 0 >>> a=3Dmid:foo >>> a=3Drtpmap:0 PCMU/8000 >>> m=3Dvideo 49172 RTP/AVP 31 >>> a=3Dmid:bar >>> a=3Drtpmap:31 H261/90000 >>>=20 >>>=20 >>>=20 >>> Proposal "a=3Dbundle same port" >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.co= m >>> s=3D >>> c=3DIN IP4 host.atlanta.example.com >>> t=3D0 0 >>> a=3Dgroup:BUNDLE foo bar >>> m=3Daudio 49170 RTP/AVP 0 >>> a=3Dmid:foo >>> a=3Drtpmap:0 PCMU/8000 >>> m=3Dvideo 49170 RTP/AVP 31 >>> a=3Dmid:bar >>> a=3Drtpmap:31 H261/90000 >>>=20 >>> In the above example, note that all the m lines for a mid identified in >>> the group:BUNLDE have the same port (49170) >>=20 >> No issue so far. >>=20 >>>=20 >>>=20 >>>=20 >>> Proposal "a=3Dbundle different port" >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.co= m >>> s=3D >>> c=3DIN IP4 host.atlanta.example.com >>> t=3D0 0 >>> a=3Dgroup:BUNDLE foo bar >>> m=3Daudio 49170 RTP/AVP 0 >>> a=3Dmid:foo >>> a=3Drtpmap:0 PCMU/8000 >>> m=3Dvideo 49172 RTP/AVP 31 >>> a=3Dmid:bar >>> a=3Drtpmap:31 H261/90000 >>>=20 >>> In the above example, note that the port numbers are the same as baseli= ne >>> - if you device receiving this offer does not support group:BUNLDE, the= n >>> this is identical to the baseline. So one m line has a port of 49170 an= d the >>> other has a different port. Other than that, it is the same as the "a= =3Dbundle >>> same port". The semantics of group:BUNLDE would be defined to be that i= f the >>> SDP receiver supports BUNDLE and wants to use it, then it places a >>> group:BUNDLE line in the answer and it send all the media to the mids i= n the >>> in BUNDLE group to the port number identified for the m-line correspond= ing >>> to the first mid in the BUNDLE group. In this example, the first mid on= the >>> a=3Dgroup:BUNDLE lines is foo, which has a m line with a port of 49170,= so >>> both the H261 and PCMU (mids foo and bar) would go to port 49170 if the >>> device creating the answer wanted to use BUNDLE. We don't have a draft = yet >>> that says exactly this thought it is very close to the one-rtp draft ( = and >>> for that matter clo >>=20 >> se to bundle draft ) >> I believe this is the mechanism described in draft-alvestrand-one-rtp-02= , or >> at least what it was intended to say. So we can use the name >> "a=3Dgroup:together" for this without risk of confusion. >>=20 >>>=20 >>>=20 >>>=20 >>> Proposal "m=3Dbundle" >>> v=3D0 >>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.co= m >>> s=3D >>> c=3DIN IP4 host.atlanta.example.com >>> t=3D0 0 >>> a=3Dgroup:BUNDLE foo bar baz >>> m=3Daudio 49170 RTP/AVP 0 >>> a=3Dmid:foo >>> a=3Drtpmap:0 PCMU/8000 >>> m=3Dvideo 49172 RTP/AVP 31 >>> a=3Dmid:bar >>> a=3Drtpmap:31 H261/90000 >>> m=3Dbundle 10000 RTP/AVP 0 8 97 31 32 >>> a=3Dmid:baz >>> a=3Dfull-rtpmap:0 audio/PCMU/8000 >>> a=3Dfull-rtpmap:31 video/H261/90000 >>>=20 >>>=20 >>> Note in the above example the SDP above the m=3Dbundle line is pretty m= uch >>> the same as the baseline + the group:BUNDLE line. The m=3Dbundle is new= media >>> type that indicates many things are bundled together on port 10000. A d= evice >>> that understood bundle would know to ignore the m lines corresponding t= o foo >>> and bar mids and would just use the stuff from the bas mid. >>=20 >> Yep. I've suggested calling it "m=3Danytype", but Christer hasn't adopte= d that >> so far :-) >>=20 >>>=20 >>>=20 >>> So before we start discussing the pros / cons of theses three approache= s, >>> let's spend a few days and make sure that I have correctly characterize= d the >>> three approaches under discussion. >>>=20 >>> Did I get it right? Do we need more explanation of any of these to see = how >>> they work? >>>=20 >>> Lets keep clarifications only on this thread and I'll start a separate >>> thread for pro/cons once we get this a bit clearer. >>=20 >> Remember to change the subject line to a descriptive one for the next th= read >> :-) >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From fandreas@cisco.com Fri Oct 5 11:51:35 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA6F21F87AB for ; Fri, 5 Oct 2012 11:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMD1KFMhiAAm for ; Fri, 5 Oct 2012 11:51:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F36D821F86BB for ; Fri, 5 Oct 2012 11:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7834; q=dns/txt; s=iport; t=1349463092; x=1350672692; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UwZaTdT3Q+iEyTyTRPX8OygToMsqtrwW9x6adw/4dmA=; b=QUQ7N+vpkbr3tmmAJYHlEFb6wh4L8b3aFJ8sfWYqFEJ/js/DnauDMyAa edxJ8yxiYa11KFf6+mr22Bgo8jBZAK5dN3+yI/VLFHIlIksSbEj6Rp9bc zOJ+OYhzDRBVHxEug4P+hmOCNLQaFrvS+Zy7ilO667SxE+Fh3eV80jAIO U=; X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128782646" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 05 Oct 2012 18:51:31 +0000 Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q95IpUhT027640; Fri, 5 Oct 2012 18:51:31 GMT Message-ID: <506F2C32.5080501@cisco.com> Date: Fri, 05 Oct 2012 14:51:30 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:51:35 -0000 On 10/4/12 6:29 PM, Cullen Jennings (fluffy) wrote: > On Oct 1, 2012, at 12:07 PM, Andrew Allen wrote: > >> I think it is possible. The statement just needs to identify the sections of the draft or functionality suppported - this is quite common practice in the industry. >> >> Maybe rather than a last minute delay to this work the best approach would be for another draft to be written under RTCweb that specifies the SDP extensons needed for RTCweb (is the title capability really the only one?) - a kind of RTCweb hitchikers guide for SDP and then vendors can claim compliance to that. >> >> Andrew > OK, as long a the folks in the music WG view that as reasonable thing for me to do, I'll submit something. > Sounds good to me. -- Flemming >> ----- Original Message ----- >> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] >> Sent: Monday, October 01, 2012 08:28 AM Central Standard Time >> To: Miguel A. Garcia >> Cc: Flemming Andreasen (fandreas) ; mmusic WG ; draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org >> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >> >> >> I think the issues is how does a manffacture says on a spec sheet that they want support half of it but not all of it. I know that does not matter for 3GPP usage but it sort of useful for others. Clearly this is not a huge technical issues but a small procedural thing so I leave it up to the chairs what they want to do. >> >> Any thoughts on making the changes so this works in world with more than english? That was my far more relevant comment that is likely to also be raised by IESG. >> >> >> >> On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia wrote: >> >>> Cullen, >>> >>> The draft is written as an independent collection of "objects". This is avoid having three separate drafts. >>> >>> It is possible to refer to parts of this draft. For example, I believe 3GPP only needs the connection data capability, but not the others, and still they are fine with this draft. >>> >>> Couldn't the same principle be applied by RTCweb? >>> >>> /Miguel >>> >>> On 28/09/2012 17:02, Atle Monrad wrote: >>>> Hi >>>> >>>> Is it really necessary to chop the draft up in pieces because others may want to use just parts of it? >>>> >>>> I find it more constuctive to finish this draft as is and let other be able to build on and refer to the RFC if and when possible. >>>> >>>> /atle >>>> >>>> ________________________________ >>>> >>>> >>>> Atle Monrad >>>> 3GPP CT Chairman >>>> Standardization and Regulation, >>>> Group Function Technology and Portfolio Management >>>> Ericsson >>>> >>>> >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) >>>> Sent: 28. september 2012 16:47 >>>> To: mmusic WG >>>> Cc: Flemming Andreasen (fandreas); draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org >>>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>> >>>> >>>> Major comment >>>> >>>> I think the title stuff should be split out to a separate draft. The main reason is that you might want to build a dvicd that supported title but did not supper the others and still be able to say what you were doing was RFC X. For example, the RTC Web folks may want to use this. >>>> >>>> Given the Title is meant to be human readable, I think it needs to be extended to have normal i18n support. >>>> >>>> Cullen >>>> >>>> >>>> >>>> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen wrote: >>>> >>>>> This is to announce a 2 week Working Group Last Call for >>>>> >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>>> >>>>> as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list. >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Flemming >>>>> >>>>> >>>>> >>>>> >>>>> Draft Info: >>>>> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. >>>>> >>>>> Title : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) >>>>> Author(s) : Miguel A. Garcia-Martin >>>>> Simo Veikkolainen >>>>> Robert R. Gilman >>>>> Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>>> Pages : 19 >>>>> Date : 2012-08-27 >>>>> >>>>> Abstract: >>>>> SDP has been extended with a capability negotiation mechanism >>>>> framework that allows the endpoints to negotiate transport protocols >>>>> and attributes. This framework has been extended with a media >>>>> capabilities negotiation mechanism that allows endpoints to negotiate >>>>> additional media-related capabilities. This negotiation is embedded >>>>> into the widely-used SDP offer/answer procedures. >>>>> >>>>> This memo extends the SDP capability negotiation framework to allow >>>>> endpoints to negotiate three additional SDP capabilities. In >>>>> particular, this memo provides a mechanism to negotiate bandwidth >>>>> ('b=' line), connection data ('c=' line), and titles ('i=' line for >>>>> each session or media). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c >>>>> aps >>>>> >>>>> >>>>> There's also a htmlized version available at: >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01 >>>>> >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-c >>>>> aps-01 >>>>> >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > . > From fandreas@cisco.com Fri Oct 5 12:05:51 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8915021F86BE for ; Fri, 5 Oct 2012 12:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggORa2sJoIL5 for ; Fri, 5 Oct 2012 12:05:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6DD21F86A5 for ; Fri, 5 Oct 2012 12:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6702; q=dns/txt; s=iport; t=1349463950; x=1350673550; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/0lSXObO7pcOK1f7+3lYke1Tx0KkCmk+W4b8CMvWhAs=; b=EMl98Couuf9PEaSS/+0ZzTZeoGb9ai2rGxmd4p+hcem8snIn9RWRbUIM FOSzoqvmjIx9gYOU5g7I26APigcy6jd5z0XDotJf7sHQU0rJnUGHIQv6E Ip4A+GiS3/I9Rc27QKFY5cjA3s23T/XytOWpQhTm4KiowncA4aPVgW0vY g=; X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128820183" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 05 Oct 2012 19:05:50 +0000 Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q95J5n8o014349; Fri, 5 Oct 2012 19:05:49 GMT Message-ID: <506F2F8D.5070708@cisco.com> Date: Fri, 05 Oct 2012 15:05:49 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> <5066A49F.2040002@ericsson.com> <506A49D4.40102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic WG , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 19:05:51 -0000 On 10/4/12 6:29 PM, Cullen Jennings (fluffy) wrote: > On Oct 1, 2012, at 7:56 PM, Flemming Andreasen wrote: > >> On 10/1/12 9:28 AM, Cullen Jennings (fluffy) wrote: >>> I think the issues is how does a manffacture says on a spec sheet that they want support half of it but not all of it. I know that does not matter for 3GPP usage but it sort of useful for others. Clearly this is not a huge technical issues but a small procedural thing so I leave it up to the chairs what they want to do. >> I think the draft is pretty clear in not requiring all of it to be implemented, e.g. as described in the Introduction: >> >> >> Since the three added capabilities are highly unconnected, it is not >> expected that implementations will support all of them at the same >> time. Instead, it is expected that applications will choose their >> needed capability for their specific purpose. Due to this, we are >> writing the normative part pertaining to each capability in a self- >> contained section: Section 3.1.1 describes the bandwidth capability >> extension, Section 3.1.2 describes the connection data capability >> extension, and Section 3.1.3 describes the title capability >> extension. Separate option tags are defined for each capability. >> >> >> >> and carried through in the main part of the doc itself (btw; there seems to be an error in the "conn-config-list" inasmuch as it does not include the "["+"]" prefix to indicate mandatory extensions). >> >> With the separate option tags in mind, the above text, and also inclusion of the "mandatory" prefix in the various configurations, do you still have concerns around the granularity of the draft ? > The upside of combining these are roughly, as Miguel said in his email, we can combine multiple random small stuff into one draft. The downside is that if you do half some but not all of them, you can't say you implement RFC 1234. Personally, I don't see that reviewing it in one draft is greatly simpler than a few drafts but really, this is not a big deal to me. As long as the MMUSIC WG if fine with the RTCWeb WG having drafts that say do part of RFC XXXX, but not all of it - I don't see any problem with leaving it all in one draft. If there not OK with that, then we need split it apart but it sounds like folks are fine with keeping it as one. In the future, I'm fine either way. The reason I'd prefer to keep them together in this draft is because we are at the WGLC stage and 3GPP is anxiously waiting for us to complete this work. Given that we have individual option tags for each of the extensions defined in this draft, we have a well-defined way of splitting them up as it is, so I think we are fine with proceeding with a single draft in this case, even if RTCWeb or others only want to use a subset. >>> Any thoughts on making the changes so this works in world with more than english? That was my far more relevant comment that is likely to also be raised by IESG. >>> >>> >> Can you elaborate on how this differs from the native SDP use of the "i=" field, which is simply being carried over here (maybe there should be some text talking about "a=charset" interactions though, per RFC 4566) ? > The "i=" field was defined before the IETF was trying to seriously support i18n and there is no easy backwards compatible way to fix it. Also, the "i=" is more or less not used. This is a bit different - it's new and people are saying it would be used by 3GPP. Not sure I follow - the title capability defined in the draft is defined as mapping directly to the RFC 4566 "i=" field. > > Making it support multiple languages would probably not be hard - you could do it with a set of strings where each string also had a language tag and the strings were UTF8 then encoded with base64 to represent them in SDP. Ok, but it would no longer correspond to the "i=" field then, right ? Are you looking for an internationalized version of the "i=" field instead (could define an attribute for that, which would then automatically be representable as an attribute capability) ? If so, I think that's above and beyond what this draft is trying to do (which is not to say we don't need another draft to solve this, but it's not just as a capability then) ? > Given then is meant to be read by humans, why wouldn't you make it so it can be read by human. > The draft is just trying to map existing SDP into capabilities. -- Flemming >> >> Thanks >> >> -- Flemming >> >>> On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia >>> >>> wrote: >>> >>> >>>> Cullen, >>>> >>>> The draft is written as an independent collection of "objects". This is avoid having three separate drafts. >>>> >>>> It is possible to refer to parts of this draft. For example, I believe 3GPP only needs the connection data capability, but not the others, and still they are fine with this draft. >>>> >>>> Couldn't the same principle be applied by RTCweb? >>>> >>>> /Miguel >>>> >>>> On 28/09/2012 17:02, Atle Monrad wrote: >>>> >>>>> Hi >>>>> >>>>> Is it really necessary to chop the draft up in pieces because others may want to use just parts of it? >>>>> >>>>> I find it more constuctive to finish this draft as is and let other be able to build on and refer to the RFC if and when possible. >>>>> >>>>> /atle >>>>> >>>>> ________________________________ >>>>> >>>>> >>>>> Atle Monrad >>>>> 3GPP CT Chairman >>>>> Standardization and Regulation, >>>>> Group Function Technology and Portfolio Management >>>>> Ericsson >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: >>>>> mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org >>>>> ] On Behalf Of Cullen Jennings (fluffy) >>>>> Sent: 28. september 2012 16:47 >>>>> To: mmusic WG >>>>> Cc: Flemming Andreasen (fandreas); >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org >>>>> >>>>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt >>>>> >>>>> >>>>> Major comment >>>>> >>>>> I think the title stuff should be split out to a separate draft. The main reason is that you might want to build a dvicd that supported title but did not supper the others and still be able to say what you were doing was RFC X. For example, the RTC Web folks may want to use this. >>>>> >>>>> Given the Title is meant to be human readable, I think it needs to be extended to have normal i18n support. >>>>> >>>>> Cullen >>>>> >>>>> >>>>> >>>>> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen >>>>> >>>>> wrote: > . > From kaiduanx@gmail.com Fri Oct 5 11:23:18 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CCB21F87EC; Fri, 5 Oct 2012 11:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4VcNX7Mv41T; Fri, 5 Oct 2012 11:23:18 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC0B021F87EA; Fri, 5 Oct 2012 11:23:17 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2440685obq.31 for ; Fri, 05 Oct 2012 11:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ppVEmYa6z+UkNXOn8bFkyY/dOAhNjPCtLAdNuLs1Iok=; b=hIq+Jmgscdi2/30uBCsR0Zf2XUwX2/12Upun6zADu2B/uP76BjJGZN7nyMCkDbyXPb JdUsnbAykWNotMaNzCtdAO6iQs/xqbAmdsOuwwj9x85qXp5VC6UKnnEvp+9io/mK58xl KGxxkqFB4XviTLNEa0XsGJ1MqJVQakDpn9R6f8f2Dqsnr0aDFT8NcxcsVLobKpJb0Tpv oUPZJH43pHm0ttB9FA9623pon/NN5V7nBDNpv7C+bAeW7MM3EO43fohDish/1ym74LO2 G2ToX51WXjLOwELC9XpKyCgjA45YY2txVNpCFQruOfyK8u6VKf5iDRC9oXfjvwC454OP 7Tyw== MIME-Version: 1.0 Received: by 10.60.0.169 with SMTP id 9mr7847606oef.94.1349461397572; Fri, 05 Oct 2012 11:23:17 -0700 (PDT) Received: by 10.76.23.129 with HTTP; Fri, 5 Oct 2012 11:23:17 -0700 (PDT) In-Reply-To: <506ED8C4.6080409@alvestrand.no> References: <506ED8C4.6080409@alvestrand.no> Date: Fri, 5 Oct 2012 14:23:17 -0400 Message-ID: From: Kaiduan Xie To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 05 Oct 2012 14:00:13 -0700 Cc: "Cullen Jennings \(fluffy\)" , Jonathan Lennox , Randell Jesup , mmusic WG , "rtcweb@ietf.org" Subject: Re: [MMUSIC] [rtcweb] path forward on bundle X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:23:18 -0000 "Note in the above example the SDP above the m=bundle line is pretty much the same as the baseline + the group:BUNDLE line. The m=bundle is new media type that indicates many things are bundled together on port 10000. A device that understood bundle would know to ignore the m lines corresponding to foo and bar mids and would just use the stuff from the bas mid." ^^^ Should it be baz mid? /Kaiduan On Fri, Oct 5, 2012 at 8:55 AM, Harald Alvestrand wrote: > On 10/05/2012 02:28 PM, Cullen Jennings (fluffy) wrote: >> >> I'm trying to figure out how to move forward on bundle stuff. Let me start >> by summarizing what I think the three proposals are then we can try and sort >> out pros/cons of each. I think we agree that the goals here is to have >> something that gets the SDP so that we can negotiate using less ports. >> >> I see it as we have three proposed solutions that I will call "a=bundle >> same port", "a=bundle different port", and "m=bundle". I'll try and >> describe these below to make sure we are on same page of what the three are >> then we can try and figurer out pros/cons of each and what to do. I'll give >> examples of the SDP offer for each but I tried and make everything simple, >> I'm going to ignore the RTCP mux and such but I think you can see how that >> would get added to all the examples. >> >> >> First lets set the baseline of an offer that does not want to multiplex >> the audio and video on same port >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> m=audio 49170 RTP/AVP 0 >> a=mid:foo >> a=rtpmap:0 PCMU/8000 >> m=video 49172 RTP/AVP 31 >> a=mid:bar >> a=rtpmap:31 H261/90000 >> >> >> >> Proposal "a=bundle same port" >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> a=group:BUNDLE foo bar >> m=audio 49170 RTP/AVP 0 >> a=mid:foo >> a=rtpmap:0 PCMU/8000 >> m=video 49170 RTP/AVP 31 >> a=mid:bar >> a=rtpmap:31 H261/90000 >> >> In the above example, note that all the m lines for a mid identified in >> the group:BUNLDE have the same port (49170) > > No issue so far. > >> >> >> >> Proposal "a=bundle different port" >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> a=group:BUNDLE foo bar >> m=audio 49170 RTP/AVP 0 >> a=mid:foo >> a=rtpmap:0 PCMU/8000 >> m=video 49172 RTP/AVP 31 >> a=mid:bar >> a=rtpmap:31 H261/90000 >> >> In the above example, note that the port numbers are the same as baseline >> - if you device receiving this offer does not support group:BUNLDE, then >> this is identical to the baseline. So one m line has a port of 49170 and the >> other has a different port. Other than that, it is the same as the "a=bundle >> same port". The semantics of group:BUNLDE would be defined to be that if the >> SDP receiver supports BUNDLE and wants to use it, then it places a >> group:BUNDLE line in the answer and it send all the media to the mids in the >> in BUNDLE group to the port number identified for the m-line corresponding >> to the first mid in the BUNDLE group. In this example, the first mid on the >> a=group:BUNDLE lines is foo, which has a m line with a port of 49170, so >> both the H261 and PCMU (mids foo and bar) would go to port 49170 if the >> device creating the answer wanted to use BUNDLE. We don't have a draft yet >> that says exactly this thought it is very close to the one-rtp draft ( and >> for that matter clo > > se to bundle draft ) > I believe this is the mechanism described in draft-alvestrand-one-rtp-02, or > at least what it was intended to say. So we can use the name > "a=group:together" for this without risk of confusion. > >> >> >> >> Proposal "m=bundle" >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> a=group:BUNDLE foo bar baz >> m=audio 49170 RTP/AVP 0 >> a=mid:foo >> a=rtpmap:0 PCMU/8000 >> m=video 49172 RTP/AVP 31 >> a=mid:bar >> a=rtpmap:31 H261/90000 >> m=bundle 10000 RTP/AVP 0 8 97 31 32 >> a=mid:baz >> a=full-rtpmap:0 audio/PCMU/8000 >> a=full-rtpmap:31 video/H261/90000 >> >> >> Note in the above example the SDP above the m=bundle line is pretty much >> the same as the baseline + the group:BUNDLE line. The m=bundle is new media >> type that indicates many things are bundled together on port 10000. A device >> that understood bundle would know to ignore the m lines corresponding to foo >> and bar mids and would just use the stuff from the bas mid. > > Yep. I've suggested calling it "m=anytype", but Christer hasn't adopted that > so far :-) > >> >> >> So before we start discussing the pros / cons of theses three approaches, >> let's spend a few days and make sure that I have correctly characterized the >> three approaches under discussion. >> >> Did I get it right? Do we need more explanation of any of these to see how >> they work? >> >> Lets keep clarifications only on this thread and I'll start a separate >> thread for pro/cons once we get this a bit clearer. > > Remember to change the subject line to a descriptive one for the next thread > :-) > >> >> >> >> >> >> >> >> >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tireddy@cisco.com Sun Oct 7 01:53:23 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2D321F84EA for ; Sun, 7 Oct 2012 01:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPm9LkHiA649 for ; Sun, 7 Oct 2012 01:53:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7D00221F84A0 for ; Sun, 7 Oct 2012 01:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2246; q=dns/txt; s=iport; t=1349600002; x=1350809602; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wZS+VE26uy0b7l/UTW5WBlZA+8DGmnS9sQxH4qoH2Hs=; b=PR6+2RH8cAWWnJwbTcmlGsDyZ/309AQiWnjb9fbiXg77RAAAlMXjd76g CmKbgI2BENLkC+3Rf4vWRhmaqfIXFuTc2EMBUDFJbIOJ6R3FSZnGGlN3z +cjZGCi65J5KyQNkxnh8VW3SvQLelP5USBxDM3tLSmTufbpI14bMCv8gR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF1CcVCtJV2Z/2dsb2JhbABFhhG4En+BCIIgAQEBBBIBEBFDDgYBCBEEAQEDAgYdAwIEMBQBBgEBBQUEEwgBGYdjC5hagSiNG5FtgSGKLoR+MmADlwCNMIFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,547,1344211200"; d="scan'208";a="129066020" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 07 Oct 2012 08:53:22 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q978rLx2014300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 7 Oct 2012 08:53:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 03:53:21 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-wing-mmusic-ice-mobility-02.txt Thread-Index: AQHNo9xJ32BcG8oCvkG5kZ4CzZfNNJeticrg Date: Sun, 7 Oct 2012 08:53:20 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147FCA07@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.68.16.234] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--26.371500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 08:53:23 -0000 d2UgaGF2ZSBhZGRyZXNzZWQgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGFuZCB1cGRhdGVkIHZlcnNp b24gb2YgTW9iaWxpdHkgd2l0aCBJQ0UgKE1JQ0UpIGhhcyBiZWVuIHN1Ym1pdHRlZC4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LTAyIEFs bCBjaGFuZ2VzIGFyZSBzcGVjaWZpYyB0byBNb2JpbGl0eSB1c2luZyBJQ0UuIFBsZWFzZSBsZXQg dXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMsIHN1Z2dlc3Rpb25zIHRvIGltcHJvdmUg dGhlIGRyYWZ0Lg0KDQpUaGFua3MNClRpcnUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMDYsIDIwMTIgOTozNSBQTQ0KVG86 IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiBQcmFzaGFudGggUGF0aWwgKHByYXNw YXRpKTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpOyBEYW4gV2luZyAoZHdpbmcpDQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdpbmctbW11c2ljLWljZS1tb2Jp bGl0eS0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2luZy1tbXVzaWMt aWNlLW1vYmlsaXR5LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBU aXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K RmlsZW5hbWU6CSBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHkNClJldmlzaW9uOgkgMDIN ClRpdGxlOgkJIE1vYmlsaXR5IHdpdGggSUNFIChNSUNFKQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTIt MTAtMDYNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAx Nw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDIudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmls aXR5DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdp bmctbW11c2ljLWljZS1tb2JpbGl0eS0wMg0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDINCg0K QWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGhvdyBlbmRwb2ludCBt b2JpbGl0eSBjYW4gYmUgYWNoaWV2ZWQNCiAgIHVzaW5nIElDRS4gIFR3byBtZWNoYW5pc21zIGFy ZSBzaG93biwgb25lIHdoZXJlIGJvdGggZW5kcG9pbnRzDQogICBzdXBwb3J0IElDRSBhbmQgYW5v dGhlciB3aGVyZSBvbmx5IG9uZSBlbmRwb2ludCBzdXBwb3J0cyBJQ0UuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From praspati@cisco.com Sat Oct 6 10:22:46 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028C321F8504 for ; Sat, 6 Oct 2012 10:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1DSrol2x7yj for ; Sat, 6 Oct 2012 10:22:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 39B3421F8503 for ; Sat, 6 Oct 2012 10:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2225; q=dns/txt; s=iport; t=1349544165; x=1350753765; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=GAJah3dtffEXi/xYhbKGcopknfiQAB46JPUx4JVmJDU=; b=KeKSl9TlpVgatc9E6UYZfucxE8qj35ANpX39zT44W0tWNWMNmTdPXVFb lrpu30LCO/LozkoJKixRAjo9NnCzR8O9KjMUra3mRIBYkoZKOzqZOBvIe LcJdohbHfyj8HLIM6tQ6ZEOI29jFhPJr7spXXkNJhtRaJZqt4WCBQ6PmM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMLAN5ncFCtJV2b/2dsb2JhbABFtxcCAYgJgQiCIAEBAQQSAScNMBQBCCIUQhsBBgMCBBMIARmHYwuYNIEokQyOLpB/YAOXAI0wgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,545,1344211200"; d="scan'208";a="129017070" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 06 Oct 2012 17:22:44 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q96HMilw002551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 6 Oct 2012 17:22:44 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.135]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Sat, 6 Oct 2012 12:22:44 -0500 From: "Prashanth Patil (praspati)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-00.txt Thread-Index: AQHNo+cxlamY2KCNw0ymMtJD55Hp0A== Date: Sat, 6 Oct 2012 17:22:43 +0000 Message-ID: In-Reply-To: <20121004023610.1904.67107.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.65.68.217] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19246.000 x-tm-as-result: No--34.709000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 07 Oct 2012 02:26:56 -0700 Subject: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 17:22:46 -0000 For dual stack hosts, ICE will prefer IPv6 addresses over IPv4 as per RFC6724 and connectivity checks have to be performed on all IPv6 candidates before trying IPv4 candidates. If the IPv6 path is broken or is excessively slow, fallback to IPv4 candidates will be significantly slow and introduce user-visible delay. This draft proposes an algorithm that makes ICE connectivity checks more responsive to failures of an address family by performing connectivity checks with both IPv4 and IPv6 in parallel if IPv6 connectivity checks don't seem to succeed. Considering the fact that there is a very realistic chance that connectivity checks for relayed candidates will always work, the draft also proposes an optimization such that connectivity checks with relayed candidates are performed earlier than usual if connectivity checks using other candidates do not succeed quickly. Comments and feedback welcome. -Prashanth On 04/10/12 8:06 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-reddy-mmusic-ice-happy-eyeballs-00.txt >has been successfully submitted by Tirumaleswar Reddy and posted to the >IETF repository. > >Filename: draft-reddy-mmusic-ice-happy-eyeballs >Revision: 00 >Title: Happy Eyeballs Extension for ICE >Creation date: 2012-10-04 >WG ID: Individual Submission >Number of pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-reddy-mmusic-ice-happy-eyeballs- >00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-reddy-mmusic-ice-happy-eyeballs >Htmlized: =20 >http://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-eyeballs-00 > > >Abstract: > This document specifies requirements for algorithms that make ICE > connectivity checks more aggressive to reduce delays in dual stack > host connectivity checks when there is a path failure for the address > family preferred by the application or by the operating system. As > IPv6 is usually preferred, the procedures in this document helps > avoid user-noticable delays wheen the IPv6 path is broken or > excessively slow. > > =20 > =20 > > >The IETF Secretariat > From christer.holmberg@ericsson.com Sun Oct 7 12:38:37 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1F821F864A for ; Sun, 7 Oct 2012 12:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV8iLn3skvmQ for ; Sun, 7 Oct 2012 12:38:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF1321F8647 for ; Sun, 7 Oct 2012 12:38:36 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-92-5071da3a4c14 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C9.B0.25676.A3AD1705; Sun, 7 Oct 2012 21:38:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sun, 7 Oct 2012 21:38:34 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , "Flemming Andreasen (fandreas)" Date: Sun, 7 Oct 2012 21:35:04 +0200 Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNon/EzvYQ0M0yoEetRSqhZQoPGZeuQLMv Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA62@ESESSCMS0356.eemea.ericsson.se> References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> <5066A49F.2040002@ericsson.com> <506A49D4.40102@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvra7VrcIAg5//zC02nTnGZPH+gq5F x2Q2i6nLH7M4sHhM+b2R1WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyvh+bxtbwUfmirMn H7M3MP5i6mLk5JAQMJG4/vkEO4QtJnHh3nq2LkYuDiGBU4wSjZ1ToZwFjBIT/7xh7mLk4GAT sJDo/qcN0iAikCnx4UITC4jNLDCDUeLh/3QQm0VARWLdtiNMIOXCAgES07dog5giAoESx84o QXQaSbzvbQHr5BUIl2jZ0M4IsekNk8SP2xPYQOo5BXwl/q0wB6lhBDrt+6k1TBCbxCVuPZkP db6AxJI955khbFGJl4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwW krGzkLTMQtIyC0nLAkaWVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgRF1cMtv1R2Md86JHGKU 5mBREue13rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjkOGnuubXF0/7W0UdOnAtyOCt SaXmQevaqTGcPxfMkAxMuPnrMtvX+DX1snfO7/nb3Lx9hbuz+ZENRsaLXpldj7j5c55EzmSD bKOMjcYbdS6Vhkfo7Vly0eFB8hylpL7u+KdX906sNy86uvrEUYs/scGal1KPnAiVnrReUSa2 ai9HR+laIelOJZbijERDLeai4kQAsDLMtXYCAAA= Cc: mmusic WG , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 19:38:37 -0000 Hi, > As long as the MMUSIC WG if fine with the RTCWeb WG having drafts that s= ay do part of RFC XXXX, but not all of it - I don't see=20 > any problem with leaving it all in one draft. If there not OK with that, = then we need split it apart but it sounds like folks are fine with keeping = it as one. I think we have other such examples. For example, RFC 6223 (SIP keep-alive) assumes support of RFC 5626 (SIP Out= bound), but only the keep-alive part. Regards, Christer= From prvs=96284961f4=aallen@rim.com Sun Oct 7 17:28:57 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E2D21F8712 for ; Sun, 7 Oct 2012 17:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.128 X-Spam-Level: X-Spam-Status: No, score=-5.128 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikxkg45M-yQW for ; Sun, 7 Oct 2012 17:28:57 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0A40021F8711 for ; Sun, 7 Oct 2012 17:28:56 -0700 (PDT) X-AuditID: 0a41282f-b7f4b6d0000008db-fb-50721e4784e9 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id 27.95.02267.74E12705; Sun, 7 Oct 2012 19:28:55 -0500 (CDT) Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 19:28:54 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "fluffy@cisco.com" , "fandreas@cisco.com" Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt Thread-Index: AQHNon/KUfRZZyrxgk2Z0ZEZp6DnRZeulIQA///+RYI= Date: Mon, 8 Oct 2012 00:28:53 +0000 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA62@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2VScUgTURzm7bZxzkbnWvmaJPMSlGK6yuoUJ0VJC8yWRUgU67o959F2m3fn 0AIT/UclqFBDJ5iGOSrJ0ozKMFtgLkRHWdQiCVRCIjQzwozorhkYvb++73u/7/c+Hh+O6QZU BpzlRMRztItUa5SaPR6TaV8ibzO/GDRT4eangOoZGVJQs2ETVVOvphoDk8pdKmvD0h2V9ce3 V2prR8eiwrrw8qvapjxWCbJP0aLvMOvk0nOyaY7ziLSIjA4kMBYyDzlpl9HGsz6aKTfuZQXG RbNuxJNG1mEhM0ij10UzyI040ULSXi/iHGSOxvjfyZbGWM6IOMbjYDmnhdx/+KCJorZnmraQ OaaTtauKa2p/Krx9sWV94UFQCfpj6kAMDokMGKp+oIridTA80a2uAxpcR1wHsOpqRBUlvQBO 1EYweUpNbISBpSYgX+iJFgBbx/1/CEa0Afj6Wo1EcHwNYYOTAxYZ6olDcGiElL16IguefxLC ZFlJJMP3rRmyrCWssL7hmVKWY4hCeLM1RZaBlOf78y6FjDEiHkamriiiOQnY8WgMi+K1cGby 13L+JNg5HFJH59Pgm8aGZbwZdrZ/wqJPxcFQ85TyIljrX7HWv8LiX2Hxr7C0AeUNEOcuFsw7 zAzHpPGsO41DYg+Q27E7Nf0++DxLBQGBA3KVtmC+xKZT0T6h3B0EEMdIvbZypyRpHXT5GcR7 7HypCwlBQEn/cAkzxDIeqWucaN9mNv9DyHjttocOm45wSoU5jZAX8X+tCjxGXq0x6AWpE4in S8Viu1wzuyD1zFAJxLfmwO17RafVZfWjO5q6DuR+uBws8X5c2Dz/reeUf8NZlJ83lvD49jvS Mvv2S3sk1Fo1P3fMUZjZMrG6op8ZBqXxY2eaj1gT/P686pmkwPqUufCF57UnRsem9+Qv+I7m HndOp/eCZLo6ryj7XMHdiu7xxRR7qi5u+BaoZrISt5JKoZjesgnjBfo3+Sg1IVEDAAA= Cc: "mmusic@ietf.org" , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 00:28:57 -0000 Yes and also RFC 5627 (GRUU) uses the +sip.instance header field parameter f= rom RFC 5626 but implementing GRUU does not also require that you also imple= ment all of Outbound. GRUU and outbound also were being developed at the same time and we did not= decide to split +sip.instance into a separate draft back then. ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Sunday, October 07, 2012 02:35 PM Central Standard Time=0A= To: Cullen Jennings (fluffy) ; Flemming Andreasen (fandrea= s) Cc: mmusic WG ; draft-ietf-mmusic-sdp-miscellaneous-caps@to= ols.ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.t= xt Hi, > As long as the MMUSIC WG if fine with the RTCWeb WG having drafts that sa= y do part of RFC XXXX, but not all of it - I don't see > any problem with leaving it all in one draft. If there not OK with that, t= hen we need split it apart but it sounds like folks are fine with keeping it= as one. I think we have other such examples. For example, RFC 6223 (SIP keep-alive) assumes support of RFC 5626 (SIP Outb= ound), but only the keep-alive part. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From bill.wu@huawei.com Sun Oct 7 18:49:59 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB4321F863F; Sun, 7 Oct 2012 18:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa27jkSQ4ouS; Sun, 7 Oct 2012 18:49:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFEDF21F8650; Sun, 7 Oct 2012 18:49:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALK27870; Mon, 08 Oct 2012 01:49:57 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 02:49:32 +0100 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 02:49:53 +0100 Received: from w53375 (10.138.41.149) by szxeml415-hub.china.huawei.com (10.82.67.154) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 8 Oct 2012 09:49:44 +0800 Message-ID: From: Qin Wu To: Christer Holmberg , , References: <7F2072F1E0DE894DA4B517B93C6A0585340A75E666@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 8 Oct 2012 09:49:43 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027D_01CDA53A.3E65FD50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: sunseawq@huawei.com, alan.d.clark@telchemy.com Subject: Re: [MMUSIC] SDP comments draft-ietf-xrblock-rtcp-xr-delay-09 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 01:49:59 -0000 ------=_NextPart_000_027D_01CDA53A.3E65FD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksQ2hyaXN0ZXI6DQpUaGFuayBmb3IgeW91ciB2YWx1YWJsZSByZXZpZXcuIHBsZWFzZSBzZWUg bXkgcmVwbHkgaW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KICAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyANCiAgVG86IG1tdXNp Y0BpZXRmLm9yZyANCiAgQ2M6IGFsYW4uZC5jbGFya0B0ZWxjaGVteS5jb20gOyBzdW5zZWF3cUBo dWF3ZWkuY29tIA0KICBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDAyLCAyMDEyIDY6MzAgUE0NCiAg U3ViamVjdDogUkU6IFNEUCBjb21tZW50cyBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1kZWxh eS0wOQ0KDQoNCiAgRHJhZnQgYXV0aG9ycyBpbmNsdWRlZC4NCg0KICAgDQoNCiAgRnJvbTogQ2hy aXN0ZXIgSG9sbWJlcmcgDQogIFNlbnQ6IDIuIGxva2FrdXV0YSAyMDEyIDEzOjI5DQogIFRvOiBt bXVzaWNAaWV0Zi5vcmcNCiAgQ2M6ICdkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1kZWxheS1h bGxAdG9vbHMuaWV0Zi5vcmcnDQogIFN1YmplY3Q6IFNEUCBjb21tZW50cyBkcmFmdC1pZXRmLXhy YmxvY2stcnRjcC14ci1kZWxheS0wOQ0KDQogICANCg0KICBIaSwNCg0KICAgDQoNCiAgSSBoYXZl IGJlZW4gYXNrZWQgdG8gcHJvdmlkZSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXhyYmxvY2stcnRj cC14ci1kZWxheS0wOSwgZnJvbSBhbiAiU0RQIHBlcnNwZWN0aXZlIi4NCg0KICAgDQoNCiAgRnJv bSBhIHRlY2huaWNhbCBwZXJzcGVjdGl2ZSB0aGUgdGV4dCBsb29rcyBvay4gQXMgdGhlIGRyYWZ0 IGV4dGVuZHMgYW4gZXhpc3RpbmcgYXR0cmlidXRlLCBJIGRvbid0IHRoaW5rIHRoYXQgbXVjaCB0 ZXh0IGlzIG5lZWRlZC4NCg0KICAgDQoNCiAgSG93ZXZlciwgYSBjb3VwbGUgb2Ygc3VnZ2VzdGlv bnMgd2hpY2ggSSB0aGluayB3b3VsZCBiZSB1c2VmdWwgdG8gaW1wbGVtZW50Og0KDQogICANCg0K ICBRMTogSSB3b3VsZCBzdWdnZXN0IHRvIGFkZCBhIHN1YmNoYXB0ZXIgKGUuZy4gIjQuMS4gU0RQ IHJ0Y3AteHItYXR0cmliIEF0dHJpYnV0ZSBFeHRlbnNpb24iKSwgd2hlcmUgdGhlIGV4dGVuZGVk IHN5bnRheCBpcyBkZWZpbmVkLg0KDQogICANCg0KW1Fpbl06IEdvb2Qgc3VnZ2VzdGlvbiwgdGhh bmtzLiBJIGxpa2UgdG8gbW92ZSB0aGUgMnN0IHBhcmFncmFwaCB0byBzZWN0aW9uIDQuMS4gDQoN CiAgUTI6IEkgd291bGQgc3VnZ2VzdCB0byBhZGQgYSBzdWJjaGFwdGVyICgiNC4yIE9mZmVyL0Fu c3dlciBVc2FnZSIpLCBhbmQgaW5kaWNhdGUgdGhhdCB0aGUgU0RQIE9mZmVyL0Fuc3dlciB1c2Fn ZSBkZWZpbmVkIGluIFJGQyAzNjExIGFwcGx5LiBJIGtub3cgaXQncyB2ZXJ5IGxpdHRsZSB0ZXh0 IGZvciBhIG5ldyBzdWJjaGFwdGVyLCBidXQgaXQgbWFrZXMgaXQgZWFzaWVyIHRvIGZpbmQgdGhl IGluZm9ybWF0aW9uLg0KDQoNCg0KW1Fpbl06IE9rYXksIHlvdSBoYXZlIGEgZ29vZCBzdWdnZXN0 ZWQgdGV4dCwgc28gaG93IGFib3V0IGFkZGluZyBhIHNlbnRlbmNlIGluIHRoaXMgbmV3IHNlY3Rp b24gNC4yIHRvIHNheSAiDQoNCldoZW4gU0RQIGlzIHVzZWQgaW4gb2ZmZXItYW5zd2VyIGNvbnRl eHQsIHRoZSBTRFAgT2ZmZXIvQW5zd2VyIHVzYWdlIGRlZmluZWQgaW4gW1JGQzM2MTFdIGFwcGxp ZXMuDQoNCiINCg0KICAgDQoNCiAgVGhhbmtzIQ0KDQogICANCg0KICBSZWdhcmRzLA0KDQogICAN Cg0KICBDaHJpc3Rlcg0K ------=_NextPart_000_027D_01CDA53A.3E65FD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptID0gDQoiaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIj48SEVBRD4NCjxNRVRBIGNvbnRl bnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTkyOTgi Pg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBDYWxpYnJpOw0KfQ0KQGZvbnQt ZmFjZSB7DQoJZm9udC1mYW1pbHk6IFRhaG9tYTsNCn0NCkBwYWdlIFdvcmRTZWN0aW9uMSB7c2l6 ZTogNjEyLjBwdCA3OTIuMHB0OyBtYXJnaW46IDcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDsg fQ0KUC5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQNCn0NCkxJLk1zb05vcm1hbCB7DQoJ TUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 IEZPTlQtU0laRTogMTFwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IEZPTlQtU0laRTogMTFwdA0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1z by1zdHlsZS1wcmlvcml0eTogOTkNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1 ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7IG1zby1zdHlsZS1wcmlvcml0eTogOTkNCn0N CkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmU7 IG1zby1zdHlsZS1wcmlvcml0eTogOTkNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0K CUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJp b3JpdHk6IDk5DQp9DQpQLk1zb1BsYWluVGV4dCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9O VC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IEZPTlQtU0laRTogMTFwdDsgbXNvLXN0 eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJQbGFpbiBUZXh0IENoYXIiDQp9DQpM SS5Nc29QbGFpblRleHQgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOyBGT05ULVNJWkU6IDExcHQ7IG1zby1zdHlsZS1wcmlvcml0eTog OTk7IG1zby1zdHlsZS1saW5rOiAiUGxhaW4gVGV4dCBDaGFyIg0KfQ0KRElWLk1zb1BsYWluVGV4 dCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7IEZPTlQtU0laRTogMTFwdDsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxl LWxpbms6ICJQbGFpbiBUZXh0IENoYXIiDQp9DQpTUEFOLlBsYWluVGV4dENoYXIgew0KCUZPTlQt RkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5OyBt c28tc3R5bGUtbGluazogIlBsYWluIFRleHQiOyBtc28tc3R5bGUtbmFtZTogIlBsYWluIFRleHQg Q2hhciINCn0NClNQQU4uRW1haWxTdHlsZTE5IHsNCglGT05ULUZBTUlMWTogIkNhbGlicmkiLCJz YW5zLXNlcmlmIjsgQ09MT1I6IHdpbmRvd3RleHQ7IG1zby1zdHlsZS10eXBlOiBwZXJzb25hbA0K fQ0KU1BBTi5FbWFpbFN0eWxlMjAgew0KCUZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOyBDT0xPUjogIzFmNDk3ZDsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLXJlcGx5DQp9DQou TXNvQ2hwRGVmYXVsdCB7DQoJRk9OVC1TSVpFOiAxMHB0OyBtc28tc3R5bGUtdHlwZTogZXhwb3J0 LW9ubHkNCn0NCkRJVi5Xb3JkU2VjdGlvbjEgew0KCXBhZ2U6IFdvcmRTZWN0aW9uMQ0KfQ0KPC9T VFlMRT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9I RUFEPg0KPEJPRFkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgYmdDb2xvcj0jZmZmZmZmIHZMaW5rPXB1 cnBsZT4NCjxESVY+SGksQ2hyaXN0ZXI6PC9ESVY+DQo8RElWPlRoYW5rIGZvciB5b3VyIHZhbHVh YmxlIHJldmlldy4gcGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUgYmVsb3cuPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5SZWdhcmRzITwvRElWPg0KPERJVj4tUWluPC9ESVY+DQo8QkxP Q0tRVU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkct TEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1S SUdIVDogMHB4IiANCmRpcj1sdHI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgQkFDS0dST1VORDogI2U0ZTRlNDsgZm9udC1j b2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tIA0KICBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIj5DaHJpc3RlciBIb2xtYmVyZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPW1tdXNpY0BpZXRmLm9yZyAN CiAgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9BPiA8L0RJ Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4g PEEgdGl0bGU9YWxhbi5kLmNsYXJrQHRlbGNoZW15LmNvbSANCiAgaHJlZj0ibWFpbHRvOmFsYW4u ZC5jbGFya0B0ZWxjaGVteS5jb20iPmFsYW4uZC5jbGFya0B0ZWxjaGVteS5jb208L0E+IDsgPEEg DQogIHRpdGxlPXN1bnNlYXdxQGh1YXdlaS5jb20gDQogIGhyZWY9Im1haWx0bzpzdW5zZWF3cUBo dWF3ZWkuY29tIj5zdW5zZWF3cUBodWF3ZWkuY29tPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBUdWVzZGF5LCBPY3RvYmVy IDAyLCAyMDEyIDY6MzAgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7 JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSRTogU0RQIGNvbW1lbnRzIA0KICBkcmFmdC1pZXRm LXhyYmxvY2stcnRjcC14ci1kZWxheS0wOTwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJ ViBjbGFzcz1Xb3JkU2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0i Q09MT1I6ICMxZjQ5N2QiPkRyYWZ0IGF1dGhvcnMgDQogIGluY2x1ZGVkLjxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJDT0xPUjogIzFmNDk3 ZCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8RElWPg0KICA8RElWIA0KICBzdHls ZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkctUklHSFQ6IDBj bTsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PFNQQU4gDQog IHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEw cHQiPkZyb206PC9TUEFOPjwvQj48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21h Jywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+IENocmlzdGVyIEhvbG1iZXJnIA0KICA8 QlI+PEI+U2VudDo8L0I+IDIuIGxva2FrdXV0YSAyMDEyIDEzOjI5PEJSPjxCPlRvOjwvQj4gPEEg DQogIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvQT48QlI+ PEI+Q2M6PC9CPiA8QSANCiAgaHJlZj0ibWFpbHRvOidkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14 ci1kZWxheS1hbGxAdG9vbHMuaWV0Zi5vcmcnIj4nZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHIt ZGVsYXktYWxsQHRvb2xzLmlldGYub3JnJzwvQT48QlI+PEI+U3ViamVjdDo8L0I+IA0KICBTRFAg Y29tbWVudHMgDQogIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWRlbGF5LTA5PG86cD48L286 cD48L1NQQU4+PC9QPjwvRElWPjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD5IaSw8bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1Nc29QbGFpblRleHQ+SSBoYXZlIGJlZW4gYXNrZWQgdG8gcHJvdmlkZSBjb21tZW50cyBvbiAN CiAgZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItZGVsYXktMDksIGZyb20gYW4gIlNEUCBwZXJz cGVjdGl2ZSIuPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZu YnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPkZyb20gYSB0ZWNobmljYWwgcGVy c3BlY3RpdmUgdGhlIHRleHQgbG9va3Mgb2suIEFzIHRoZSANCiAgZHJhZnQgZXh0ZW5kcyBhbiBl eGlzdGluZyBhdHRyaWJ1dGUsIEkgZG9uknQgdGhpbmsgdGhhdCBtdWNoIHRleHQgaXMgDQogIG5l ZWRlZC48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+SG93ZXZlciwgYSBjb3VwbGUgb2Ygc3VnZ2Vz dGlvbnMgd2hpY2ggSSB0aGluayB3b3VsZCBiZSANCiAgdXNlZnVsIHRvIGltcGxlbWVudDo8bzpw PjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+UTE6IEkgd291bGQgc3VnZ2VzdCB0byBhZGQgYSBzdWJjaGFw dGVyIChlLmcuIJM0LjEuIFNEUCANCiAgcnRjcC14ci1hdHRyaWIgQXR0cmlidXRlIEV4dGVuc2lv bpQpLCB3aGVyZSB0aGUgZXh0ZW5kZWQgc3ludGF4IGlzIA0KICBkZWZpbmVkLjxvOnA+PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+PC9ESVY+PC9C TE9DS1FVT1RFPg0KPFAgZGlyPWx0ciBjbGFzcz1Nc29Ob3JtYWw+PG86cD48Rk9OVCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5bUWluXTogR29vZCANCnN1Z2dlc3Rpb24sIHRoYW5rcy4g SSZuYnNwO2xpa2UgdG8mbmJzcDttb3ZlIHRoZSAyc3QgcGFyYWdyYXBoIHRvIHNlY3Rpb24gDQo0 LjEuJm5ic3A7PC9GT05UPjwvbzpwPjwvUD4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1M RUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6 IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiIA0KZGlyPWx0cj4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPlEyOiBJIHdvdWxkIHN1Z2dlc3QgdG8gYWRkIGEgc3ViY2hhcHRl ciAokzQuMiBPZmZlci9BbnN3ZXIgDQogIFVzYWdllCksIGFuZCBpbmRpY2F0ZSB0aGF0IHRoZSBT RFAgT2ZmZXIvQW5zd2VyIHVzYWdlIGRlZmluZWQgaW4gUkZDIDM2MTEgDQogIGFwcGx5LiBJIGtu b3cgaXSScyB2ZXJ5IGxpdHRsZSB0ZXh0IGZvciBhIG5ldyBzdWJjaGFwdGVyLCBidXQgaXQgbWFr ZXMgaXQgDQogIGVhc2llciB0byBmaW5kIHRoZSBpbmZvcm1hdGlvbi48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD4mbmJzcDs8L1A+PC9CTE9DS1FVT1RFPg0KPFAgZGlyPWx0ciBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBzaXplPTM+W1Fpbl06IA0K T2theSwgeW91IGhhdmUgYSBnb29kIHN1Z2dlc3RlZCB0ZXh0LCBzbyBob3cgYWJvdXQgYWRkaW5n IGEgc2VudGVuY2UgaW4gdGhpcyANCm5ldyZuYnNwO3NlY3Rpb24gNC4yIHRvIHNheSAiPC9QPg0K PFAgDQpzdHlsZT0iTElORS1IRUlHSFQ6IG5vcm1hbDsgTUFSR0lOOiAwY20gMGNtIDBwdCAxMC41 cHQ7IFRFWFQtQVVUT1NQQUNFOiBpZGVvZ3JhcGgtbnVtZXJpYzsgbXNvLXBhcmEtbWFyZ2luLWxl ZnQ6IDEuMGdkOyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuOyB0YWItc3RvcHM6IDQ1Ljhw dCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQg NDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3 MzIuOHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IGF1dG8iIA0KY2xhc3M9TXNvTm9ybWFsPjxT UEFOIA0Kc3R5bGU9IkxBWU9VVC1HUklELU1PREU6IGJvdGg7IEZPTlQtRkFNSUxZOiAmIzIzNDM1 OyYjMjAzMDc7OyBGT05ULVNJWkU6IDEycHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmIzIzNDM1 OyYjMjAzMDc7IiANCmxhbmc9RU4tVVM+V2hlbiBTRFAgaXMgdXNlZCBpbiBvZmZlci1hbnN3ZXIg Y29udGV4dCwgdGhlIFNEUCBPZmZlci9BbnN3ZXIgdXNhZ2UgDQpkZWZpbmVkIGluIFtSRkMzNjEx XSBhcHBsaWVzLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGRpcj1sdHIgY2xhc3M9TXNvTm9y bWFsPiI8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0i Qk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElO Ry1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCIgDQpkaXI9 bHRyPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+DQogIDxQIGNs YXNzPU1zb05vcm1hbD5UaGFua3MhPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPlJlZ2FyZHMsPG86 cD48L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPkNocmlzdGVyPG86cD48L286cD48L1A+PC9CTE9DS1FVT1RF PjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_027D_01CDA53A.3E65FD50-- From salvatore.loreto@ericsson.com Mon Oct 8 01:12:53 2012 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85C721F86B9 for ; Mon, 8 Oct 2012 01:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.683 X-Spam-Level: X-Spam-Status: No, score=-106.683 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucYajUclNTFa for ; Mon, 8 Oct 2012 01:12:53 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 762C421F85D5 for ; Mon, 8 Oct 2012 01:12:51 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-99-50728b02d346 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AC.3A.17130.20B82705; Mon, 8 Oct 2012 10:12:51 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012 10:12:50 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 64F5B22F6 for ; Mon, 8 Oct 2012 11:12:50 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A1AE4538FC for ; Mon, 8 Oct 2012 11:12:49 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 54CAE53192 for ; Mon, 8 Oct 2012 11:12:49 +0300 (EEST) Message-ID: <50728B01.5060405@ericsson.com> Date: Mon, 8 Oct 2012 11:12:49 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: multipart/alternative; boundary="------------010606060707070001050802" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+JvrS5zd1GAwfrnTBZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRv/cC8wFd+UqntxeztLA+Ey8i5GTQ0LAROLNh0Z2CFtM4sK9 9WxdjFwcQgKnGCW6mg6yQDjrGSXap+1mhHAuMkpMeryTFaRFSOAIo0RPtzeEvYdR4t+zEhCb V0BbYtPHw8wgNouAikTT2vlgNpuAmcTzh1vAbFGBZIne+TsZIeoFJU7OfMICYosICEvMePsX 6AwODmEBHYl7++RAwswCYRJTVk1ihrhUTeLquU3MEGu1JHrPdjJNYBSchWTSLCQtELatxIU5 16Hi8hLb386BiutKXPg/BUV8ASPbKkbh3MTMnPRyc73Uoszk4uL8PL3i1E2MwAA/uOW3wQ7G TffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4aaqTkOymW6onfzpu F1c9mmwWd/jmNvWtVvyC7P8nPtoWduVu9CN/Rf/EPg/D01ujdrVVG+rEey/3z7G6aib6es/8 NOvsos3/Hz7PStwstJKRy3zVzzeNBu+UP/q6h7D+6PKwcQ95p6ctUWwm/vHDpmevhH89+mfP U7B6w/0EycfNW5/M6C9VYinOSDTUYi4qTgQAkjOVYz4CAAA= Subject: [MMUSIC] updating draft-ietf-mmusic-sctp-sdp X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 08:12:54 -0000 --------------010606060707070001050802 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, there has been a quite large discussion within the rtcweb mailing list and especially the w3c webrtc mailing list. Some of the points discussed are specific of how to negotiate the 'datachannel' protocol over SDP, and I lean on putting those in a separate draft and not in this one. However there are things that are general enough to is worth to insert in this draft as they can be used in other protocols that eventually will be specified in the future running on top of SCTP, or STCP over DTLS. 'streams' is some of those attributes, so I am proposing to insert in the new version of the draft the following text xxx. Streams Attribute The 'streams' attribute indicates time the number of streams to be supported by the association. If this attribute is not present, the implementation should provide a default, with a suggested value of 16. streams-attr = "a=streams:" streamsnumbers streamsnumbers =1*DIGIT As I said, all the other attributes that has been discussed are tied to the 'datachannel' protocol identifier ( to be registered?), which is describing the format of the media... so they should go in a different draft. opinion, thoughts are welcome and required thanks Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------010606060707070001050802 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi there,

there has been a quite large discussion within the rtcweb mailing list and
especially the w3c webrtc mailing list.

Some of the points discussed are specific of how to negotiate the 'datachannel' protocol over SDP,
and I lean on putting those in a separate draft and not in this one.

However there are things that are general enough to is worth to insert in this draft
as they can be used in other protocols that eventually will be specified in the future
running on top of SCTP, or STCP over DTLS.

 'streams' is some of those attributes,
 so I am proposing to insert in the new version of the draft the following text

 xxx.  Streams Attribute

   The 'streams' attribute indicates time the number of streams to be supported by the association.
   If this attribute is not present, the implementation should provide a default, with a suggested value
   of 16. 

         streams-attr           =  "a=streams:" streamsnumbers
         streamsnumbers         =  1*DIGIT



    

    As I said, all the other attributes that has been discussed are tied
    to the 'datachannel'  protocol identifier ( to be registered?), 

    which is describing the format of the media... so they should go in
    a different draft.

    

    opinion, thoughts are welcome and required

    

    thanks

    Salvatore

    

    
-- 
Salvatore Loreto, PhD
www.sloreto.com

  


--------------010606060707070001050802--

From christer.holmberg@ericsson.com  Mon Oct  8 01:54:53 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576A421F86DF for ; Mon,  8 Oct 2012 01:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.116
X-Spam-Level: 
X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.132,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udMb16UtPEbi for ; Mon,  8 Oct 2012 01:54:52 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6395521F8698 for ; Mon,  8 Oct 2012 01:54:42 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-99-507294d18734
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 81.3B.11467.1D492705; Mon,  8 Oct 2012 10:54:41 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 8 Oct 2012 10:54:41 +0200
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Date: Mon, 8 Oct 2012 10:54:39 +0200
Thread-Topic: Draft new: draft-holmberg-mmusic-sdp-mmt-negotiation-00
Thread-Index: Ac2lMfyN5xbhjaInQoWNm7/ewW3hIA==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD030B@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD030BESESSCMS0356e_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre7FKUUBBi/3ClpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGVtWSRYcFK149/ILewPjauEuRk4OCQETiVVXJjNB2GISF+6t Z+ti5OIQEjjFKHHhxAIWCGcOo0TPimtAGQ4ONgELie5/2iANIgLqEl/39jCD2CwCKhJLV/wC s4UFHCTa7h1nh6hxlXg44xcLSKuIgJ5E5zsDkDCvQLjEmT8TwMoZgfZ+P7UG7AZmAXGJW0/m Q90jILFkz3lmCFtU4uXjf6wQ9aISd9rXM0LU50s8ufaNBWKmoMTJmU9YJjAKzUIyahaSsllI yiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzA WDi45bfuDsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwGg1/09M ns/Xe/NnfFU2a7f8WrXzTcTHGK6K8zfcT2XPKli7ofyr25y1e78Z/r7qFel++ENujmOJ77L9 RZfm1kw8bvk4fNmySx4KB2v314n8+RdY8SvMt8Blq9Zavtt6640FVhx0nbkp/hZz/RrD/dtC T+lVPeKV7tFn8tBTW8ZuOUFXe8fyb8eUWIozEg21mIuKEwGCvNm7UwIAAA==
Subject: [MMUSIC] Draft new: draft-holmberg-mmusic-sdp-mmt-negotiation-00
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Oct 2012 08:54:53 -0000

--_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD030BESESSCMS0356e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

We've submitted a new draft, which describes the 'm=3Dbundle' mechanism.

In order to avoid confusion, we're not using bundle terminology in the draf=
t.

Regards,

Christer

--_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD030BESESSCMS0356e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Hi,
 
We’ve submitted a new draft, whic=
h describes the ’m=3Dbundle’ mechanism.
 
In order to avoid co=
nfusion, we’re not using bundle terminology in the draft.<=
/p>
 
Regards,<=
o:p>
 
Christer
=

--_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD030BESESSCMS0356e_--

From internet-drafts@ietf.org  Mon Oct  8 02:10:22 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2091721F870F; Mon,  8 Oct 2012 02:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.504
X-Spam-Level: 
X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZFLy65MSeZn; Mon,  8 Oct 2012 02:10:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915ED21F8753; Mon,  8 Oct 2012 02:10:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121008091021.2678.43639.idtracker@ietfa.amsl.com>
Date: Mon, 08 Oct 2012 02:10:21 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Oct 2012 09:10:22 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Session Description Protocol (SDP) Extension For Setting=
 Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ=
ic Switched Telephone Network (PSTN)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
	Filename        : draft-ietf-mmusic-sdp-cs-12.txt
	Pages           : 37
	Date            : 2012-10-08

Abstract:
   This memo describes use cases, requirements, and protocol extensions
   for using the Session Description Protocol (SDP) Offer/Answer model
   for establishing audio and video media streams over circuit-switched
   bearers in the Public Switched Telephone Network (PSTN).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-12

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-12


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From miguel.a.garcia@ericsson.com  Mon Oct  8 04:02:24 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5565121F8762 for ; Mon,  8 Oct 2012 04:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Level: 
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCMo90xBgI7A for ; Mon,  8 Oct 2012 04:02:23 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 49DE321F870F for ; Mon,  8 Oct 2012 04:02:23 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-00-5072b2bd2b65
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.13.11467.DB2B2705; Mon,  8 Oct 2012 13:02:22 +0200 (CEST)
Received: from [159.107.48.152] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 8 Oct 2012 13:02:21 +0200
Message-ID: <5072B2BC.1090302@ericsson.com>
Date: Mon, 8 Oct 2012 13:02:20 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic 
References: <20121008091021.2678.73076.idtracker@ietfa.amsl.com>
In-Reply-To: <20121008091021.2678.73076.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20121008091021.2678.73076.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre6+TUUBBpumsVpMXf6YxeLcp7ss DkweS5b8ZPK4e+sSUwBTFJdNSmpOZllqkb5dAlfG/rUbmQsu8FfM7P3J1MB4laeLkZNDQsBE 4sPF5YwQtpjEhXvr2boYuTiEBE4xSmy4fJoVwlnNKHG77TszSBWvgLZEx6b9LF2MHBwsAioS R9sKQMJsAuYSrRs3soPYogLBEuc2bmODKBeUODnzCQuILSIgI7F302awMcwCxhInvixjBbGF BbwkFr2ewwYyUkjAQeJ1dxhImFPAUWLGhf/MIGEJAR+Jowv5IDotJBa/OcgOYctLbH87B2yi kICmxOSbS5knMArNQrJ4FpKWWUhaFjAyr2IUzk3MzEkvN9RLLcpMLi7Oz9MrTt3ECAzfg1t+ 6+5gPHVO5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MtqlvEuN67WMX +z6o9dXf8VHiwus95Y/v/lGdGfC+aKp+yNPGOEc5MZ4Xj3ScVZy+f2s5+6vwZWKpV1ve//Ba 9Zkz3j37xpaufOMEQ9GLyxmMq5c/sup2/6zmadIVt3BCOOfaq3N8Z/QWrPm+oebsqeuxG46c qZjVOr3ePiolUT/i8Mw3Do/TlFiKMxINtZiLihMBXM0H9C0CAAA=
Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-sdp-cs-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Oct 2012 11:02:24 -0000

We have put a new version of the CS draft, and we the authors believe 
that this closes all the open issues indicating during the WGLC.

Recently we had a discussion on the registration of the "E164" address 
type. We have clarified that this registration is for using together with 
the "PSTN" net type.

We have changed the syntax to refer to RFC 3966 (global-number). This 
does not have an impact on the actual protocol.

And we have added procedures for a case when the SDP answerer is in 
charge of setting up the CS call, but somehow that call fails.

 From the authors' perspective, the draft is complete and ready.

/Miguel

-------- Original Message --------
Subject: New Version Notification for draft-ietf-mmusic-sdp-cs-12.txt
Date: Mon, 8 Oct 2012 02:10:21 -0700
From: 
To: 
CC: 


A new version of I-D, draft-ietf-mmusic-sdp-cs-12.txt
has been successfully submitted by Miguel A. Garcia-Martin and posted to the
IETF repository.

Filename:	 draft-ietf-mmusic-sdp-cs
Revision:	 12
Title:		 Session Description Protocol (SDP) Extension For Setting Up 
Audio and Video Media Streams Over Circuit-Switched Bearers In The Public 
Switched Telephone Network (PSTN)
Creation date:	 2012-10-08
WG ID:		 mmusic
Number of pages: 37
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-12.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs
Htmlized:        http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-12
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-cs-12

Abstract:
    This memo describes use cases, requirements, and protocol extensions
    for using the Session Description Protocol (SDP) Offer/Answer model
    for establishing audio and video media streams over circuit-switched
    bearers in the Public Switched Telephone Network (PSTN).

 



The IETF Secretariat






From emil@sip-communicator.org  Mon Oct  8 09:30:59 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6554321F87B3 for ; Mon,  8 Oct 2012 09:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZWf5YP5Yqby for ; Mon,  8 Oct 2012 09:30:58 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5010521F8754 for ; Mon,  8 Oct 2012 09:30:58 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so2942370wey.31 for ; Mon, 08 Oct 2012 09:30:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-gm-message-state; bh=2XArEhY6RaWi38vQeQ/SS+uC1XmDkJ5EJ1T9XDpYsBw=; b=fBhLh2T+YfsD5ZFc/GMEcxpiVAtAuxz2C6crpXMAuIND06kX4Lrmc5XbHxC2raQyZb +589kwimsrYqqgFCFqlYF0OlX+Lx8DAKDAL4wb50z/RDcpUK6hYRiuBd+Kp8Qfx0j60b gwv4fDPlvu6Lx3EErdrXj4oRtJEPCXnzuVA+HkyRx42Bl2yam1N8bRmhb3dRB2iRH5wR 4LUO9A6CisU7VLnRFTlGcH8gL3/BSmNCoZDyFWwpyjL8ESmZKSBGLHE5e6hPJ7LIpxqd ggoUfq3YE7CctQChB6eQnenQNHQ9V0xHLgvf208MnpEotKOob6WM3G+kHxPRrtXGLetE kPcA==
Received: by 10.180.81.37 with SMTP id w5mr23117637wix.10.1349713857183; Mon, 08 Oct 2012 09:30:57 -0700 (PDT)
Received: from camionet.local (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPS id ay10sm22965103wib.2.2012.10.08.09.30.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 09:30:56 -0700 (PDT)
Message-ID: <5072FFBE.6020602@jitsi.org>
Date: Mon, 08 Oct 2012 18:30:54 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "MMUSIC IETF WG" 
References: <20121008162703.10569.16584.idtracker@ietfa.amsl.com>
In-Reply-To: <20121008162703.10569.16584.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20121008162703.10569.16584.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmsqEPogpHBU67GpRgkH8aInwXXyTSneNlmZNi9XWI/VN3+KbkMic51PvmFwB5N7963Wcw+
Subject: [MMUSIC] Fwd: New Version Notification for draft-ivov-mmusic-latching-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Oct 2012 16:30:59 -0000

Hey all,

Just posted a new version of the latching draft. This version mostly
addresses comments from the chairs and clarifies some of the security
implications of using latching.

Diff2 available here:
http://tools.ietf.org/rfcdiff?url2=draft-ivov-mmusic-latching-02.txt

Cheers,
Emil

--
https://jitsi.org


-------- Original Message --------
Subject: New Version Notification for draft-ivov-mmusic-latching-02.txt
Date: Mon, 08 Oct 2012 09:27:03 -0700
From: internet-drafts@ietf.org
To: emcho@jitsi.org
CC: dwing@cisco.com, hkaplan@acmepacket.com


A new version of I-D, draft-ivov-mmusic-latching-02.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:	 draft-ivov-mmusic-latching
Revision:	 02
Title:		 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
Communication
Creation date:	 2012-10-08
WG ID:		 Individual Submission
Number of pages: 15
URL:
http://www.ietf.org/internet-drafts/draft-ivov-mmusic-latching-02.txt
Status:          http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching
Htmlized:        http://tools.ietf.org/html/draft-ivov-mmusic-latching-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ivov-mmusic-latching-02

Abstract:
   This document describes behavior of signalling intermediaries in RTC
   deployments, sometimes referred to as Session Border Controllers
   (SBCs), when performing Hosted NAT Traversal (HNT).  HNT is a set of
   mechanisms, such as media relaying and latching, that such
   intermediaries use to enable other RTC devices behind NATs to
   communicate with each other.  This document is non-normative, and is
   only written to explain HNT in order to provide a reference to the
   IETF community, as well as an informative description to
   manufacturers, and users.





The IETF Secretariat





From fluffy@cisco.com  Mon Oct  8 15:51:59 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E34311E810F for ; Mon,  8 Oct 2012 15:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.473
X-Spam-Level: 
X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W92CklwDqN5B for ; Mon,  8 Oct 2012 15:51:58 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 721B211E810E for ; Mon,  8 Oct 2012 15:51:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=869; q=dns/txt; s=iport; t=1349736718; x=1350946318; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NWncMm4lwU3vxTujhHdbtKbysdKwa4vQ1WPb2CqfVA8=; b=TA0g0CB35MQ3Tnz3i0fY55jEpe2Kb5fCJnMFC+aCmdhGs0fW+Y20FElk MbBG0iYiInbvRAmDZOXB4nbWKjZvysA83OdlNLXO04DnjxFR+mUZAkeOK uOo3UlcHUlwH8L4GYuFG43Isx5hHdKYD5PbpNmQlRXFX6LzVoTR/VVUHB I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEFAEBYc1CtJV2Z/2dsb2JhbABFhUq5Z4EIgiABAQEDARIBJz8FCwIBCCIUEDIlAgQOBQgah10Gmj+gAItHgzqBeWADpDCBaYJgDYIX
X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129508554"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 08 Oct 2012 22:51:58 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q98Mpwf2027733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:51:58 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:51:57 -0500
From: "Cullen Jennings (fluffy)" 
To: Christer Holmberg 
Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
Thread-Index: AQHNpaeFVModXV/jHU2y4UOnBKU1gw==
Date: Mon, 8 Oct 2012 22:51:57 +0000
Message-ID: 
References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com> <7A051DFAA46D0246A82293C7CEF621E9070A0D27D0@ESESSCMS0352.eemea.ericsson.se> <5066A49F.2040002@ericsson.com>  <506A49D4.40102@cisco.com>,  <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA62@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA62@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.86.152]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004
x-tm-as-result: No--31.987800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <378E794897BE294ABA9170ED5DCBBF2E@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Flemming Andreasen \(fandreas\)" , mmusic WG , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" 
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Oct 2012 22:52:00 -0000

On Oct 7, 2012, at 12:35 , Christer Holmberg  wrote:

> Hi,
>=20
>> As long as the  MMUSIC WG if fine with the RTCWeb WG having drafts that =
say do part of RFC XXXX, but not all of it - I don't see=20
>> any problem with leaving it all in one draft. If there not OK with that,=
 then we need split it apart but it sounds like folks are fine with keeping=
 it as one.
>=20
> I think we have other such examples.
>=20
> For example, RFC 6223 (SIP keep-alive) assumes support of RFC 5626 (SIP O=
utbound), but only the keep-alive part.
>=20
> Regards,
>=20
> Christer

Yes, Agree. =20

PS - as a side note, Christer you wanted the keep alive take out of outboun=
d and I argued against that on the basis it was done but it's one of theses=
 things where I think you were right and I wish we had done that. =

From petithug@acm.org  Mon Oct  8 16:57:52 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD8821F87BF for ; Mon,  8 Oct 2012 16:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.415
X-Spam-Level: 
X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GISiQuj8ZOS3 for ; Mon,  8 Oct 2012 16:57:52 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id B719F21F87B8 for ; Mon,  8 Oct 2012 16:57:51 -0700 (PDT)
Received: from [IPv6:2601:9:4b80:32:f482:7adc:e066:c1ac] (unknown [IPv6:2601:9:4b80:32:f482:7adc:e066:c1ac]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 887CD20480 for ; Mon,  8 Oct 2012 23:57:49 +0000 (UTC)
Message-ID: <5073687B.3000009@acm.org>
Date: Mon, 08 Oct 2012 16:57:47 -0700
From: Marc Petit-Huguenin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: "mmusic@ietf.org" 
References: <20121008234552.29875.93325.idtracker@ietfa.amsl.com>
In-Reply-To: <20121008234552.29875.93325.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.1
X-Forwarded-Message-Id: <20121008234552.29875.93325.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] Fwd: I-D Action: draft-petithuguenin-mmusic-ice-attributes-level-04.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Oct 2012 23:57:52 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I just uploaded a new version of this draft.

The bulk of this document will probably be integrated in rfc5245bis, but I
wanted to be sure that the new editor will have access to a recent version of
this document.

The problem with the ice-mismatch has been fixed in the IANA registry.  Thanks
to everyone involved in the process.

But there is one small thing that will probably do not have its place in
rfc5245bis.  Appendix B contains an analysis of all the session level only SDP
attributes, to be sure that the problems described in this spec were limited
to ICE.  My conclusion was that "only the ICE attributes are of concern but
that steps should be taken to ensure that these problems cannot happen for
future new attributes."

Because this draft will never be published as an RFC, perhaps
draft-ietf-mmusic-rfc4566bis would be a good place for adding text ensuring this.

Thanks.


- -------- Original Message --------
Subject: I-D Action: draft-petithuguenin-mmusic-ice-attributes-level-04.txt
Date: Mon, 08 Oct 2012 16:45:52 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


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


	Title           : Media level ice-options SDP attribute
	Author(s)       : Marc Petit-Huguenin
	Filename        : draft-petithuguenin-mmusic-ice-attributes-level-04.txt
	Pages           : 13
	Date            : 2012-10-08

Abstract:
   This document normatively updates RFC 5245 by redefining the ice-
   options SDP attribute as a session-level and media-level attribute.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-petithuguenin-mmusic-ice-attributes-level

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-petithuguenin-mmusic-ice-attributes-level-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-petithuguenin-mmusic-ice-attributes-level-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQc2h5AAoJECnERZXWan7E71AP/j5VjIN6rocEXCx4t2SUzYIv
Km2PQBZT0bHsiEYZo7V9EY9yNRVTsHcIssPo4ugS1xfIwtK/Vs4VHMOSuscElA1c
7oYLYADygmhkXNxanCmspd+bRPFDDNCco3ZZU3TS7Oc3bQgFNtqSk89zadDXPJC8
n4kvIK0bvguTigRu3bwA+7qlkydpaRtke1NKeCp8MtNPUGzRwlCncDQDyfcarAty
mQWWV0Az4D9+u4hPMrzXkgp6s1G44Uw04OS3gBH5wUVC4sAyT4glssBGaPNwFcdY
uhdSk/boYmA5Ux6BEqEg/q/sXq4RXqTlC8Ybjg+xJziJWlQB6NZr56f0x4JVLaub
/FwcrbSiJ00xmsykWVTAYFxb9kHV+ipPfnTeV6MVyQfjuSXlLjUeBgX4qN2IhuYY
lPT553OF3Vjg1XhUBEIg3ccaNVF8d/p1WJn2vrtDWHAaN3YNQ9fkH0511PH0dnHB
99CDtaeI9Zdw1kOzs9fbP8cF+CeREw2MR1FjyGlPtKC9tvDYSz9k2Jq8kgX9baEU
OuMqyMb5j4lING0qhidPb2wDcXntXUvTl1fUl8fSK7zFLREV3rjiLG/0yIJOQWTX
UcR+s3Q+zHk/BoJy2lF95LdseQB8xZlxNBfwVD23dz7hfIuTgwVgJoOWh9RcX59D
RNNGfGw4Tinz06uJRV3P
=qm4N
-----END PGP SIGNATURE-----

From miguel.a.garcia@ericsson.com  Tue Oct  9 06:24:12 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6122F11E80D1 for ; Tue,  9 Oct 2012 06:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Level: 
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id far+7KUKb6Kv for ; Tue,  9 Oct 2012 06:24:12 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9F32121F873C for ; Tue,  9 Oct 2012 06:24:11 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-d0-5074257a73f0
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F7.7B.25676.A7524705; Tue,  9 Oct 2012 15:24:10 +0200 (CEST)
Received: from [159.107.48.57] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Oct 2012 15:24:09 +0200
Message-ID: <50742574.6080200@ericsson.com>
Date: Tue, 9 Oct 2012 15:24:04 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3VrdKtSTAYPNaQ4v3F3QtjvV1sVlM Xf6YxYHZ48qEK6weU35vZPVYsuQnUwBzFJdNSmpOZllqkb5dAlfGl5er2QsmsFY8f7OBpYGx j6WLkZNDQsBE4knvYShbTOLCvfVsXYxcHEICpxgl2nfMYAdJCAmsYpTYNjsXxOYV0JaY3XuV CcRmEVCR+P14O1gzm4C5ROvGjWD1ogLBEuc2bmODqBeUODnzCViNiICMxN5Nm5lBbGaBCIkV 9y+DzREW0JR4MG8CVNxW4sKc6ywQtrzE9rdzmCFu0JSYfHMp8wRG/llIxs5C0jILScsCRuZV jMK5iZk56eVGeqlFmcnFxfl5esWpmxiBwXhwy2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA2OEztlD/19dCfVTiDL1WCNs/aFWXnTtveUT62LixSbZv3h4 usLqx0kuh6SfN/24bzkUHzm94B+31vt7XxolZfiTTP2OfPZfWThb/N1/k7CJHozvYpn6+ljl +I5bK5mWHi7qTJunfSnqTop9meq2H2fiQlwP8U5zahT4y84RL7tRrK1baI7+cSWW4oxEQy3m ouJEAOX2efgUAgAA
Cc: Flemming Andreasen 
Subject: [MMUSIC] WG poll for consensus MSID draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Oct 2012 13:24:12 -0000

At the last IETF meeting we had a presentation of the following draft:

http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/

At that time, there was interest in solving the problem of cross session 
stream identification.

We would like to poll the working group for consensus on adopting the 
above mentioned draft as a working group item, once we get an approved 
milestone.

If you support this work or have problems with the adoption of this 
document as WG item, please indicate it by replying to this e-mail within 
the next 5 days.

Flemming and Miguel (co-chairs)

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From emil@sip-communicator.org  Wed Oct 10 07:29:41 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5E321F877D for ; Wed, 10 Oct 2012 07:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjb59l6FWo9q for ; Wed, 10 Oct 2012 07:29:41 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 73D7D21F8782 for ; Wed, 10 Oct 2012 07:29:40 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so626358wib.13 for ; Wed, 10 Oct 2012 07:29:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-gm-message-state; bh=QidaPQVeSsl4cfXUdqKBy28T4jqziW+1LkYZ7uC+MSA=; b=mpCHfTUx4jnquWcyLjCwWY6XL6Re9kkxTOFsOrbGDlK/oAN4BnGPpOxBoX7gBD/vNf hVoV5MJLyk/3b/pIqYXIvjlXTUfUG1rNdNhWk/h3KVM6/heS/30FXFe+ED+Q7Vl2VlPw vev+EvKDBbU8zzZPbB6di1l5YIF3PXtp2y5o2H+B6d8Vld/kEHr7LRqCSo/klG8+Ha2K m3WsL5BtzyzX5QjiK5Rfpk9eoNh4KPwpR9mZQqXFXYCNzlSdikxWrvl8rWjKvS+sCepj Iv0OUWNpN5G7ljXgcrbR+d9I8zeYv9n35x0Z47p7g6qa57pMt5W3kGbkbCxtw0UVHZlZ +Bfg==
Received: by 10.216.194.222 with SMTP id m72mr15310757wen.34.1349879378981; Wed, 10 Oct 2012 07:29:38 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:682d:25ba:cc96:d9a0]) by mx.google.com with ESMTPS id eq2sm3084577wib.1.2012.10.10.07.29.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 07:29:37 -0700 (PDT)
Message-ID: <5075864F.3030700@jitsi.org>
Date: Wed, 10 Oct 2012 16:29:35 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "MMUSIC IETF WG" 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>
In-Reply-To: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlhWuiaNZUav+DwcyB0yX3JFTH6WfTNE9FTRkc7fY/2HnQeWftyt7h90llK3VIo/j4pmgLi
Subject: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Oct 2012 14:29:42 -0000

Hey all,

Eric, Justin and I have just submitted a first version of the
specification of a mechanism for incremental provisioning of ICE
candidates, also known as "Trickle ICE".

The spec is in an early state and will undoubtedly see a lot of changes
as implementations progress. It does however describe the main idea so
comments and questions are most welcome!

Cheers,
Emil


-------- Original Message --------
Subject: New Version Notification for
draft-rescorla-mmusic-ice-trickle-00.txt
Date: Wed, 10 Oct 2012 07:16:00 -0700
From: internet-drafts@ietf.org
To: emcho@jitsi.org
CC: justin@uberti.name, ekr@rtfm.com


A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:	 draft-rescorla-mmusic-ice-trickle
Revision:	 00
Title:		 Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol
Creation date:	 2012-10-10
WG ID:		 Individual Submission
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt
Status:
http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle
Htmlized:
http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00


Abstract:
   This document describes an extension to the Interactive Connectivity
   Establishment (ICE) protocol that allows ICE agents to send and
   receive candidates incrementally rather than exchanging complete
   lists.  With such incremental provisioning, ICE agents can begin
   connectivity checks while they are still gathering candidates and
   considerably shorten the time necessary for ICE processing to
   complete.

   The above mechanism is also referred to as "trickle ICE".





The IETF Secretariat





From martin.thomson@gmail.com  Wed Oct 10 09:03:04 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D99621F8681 for ; Wed, 10 Oct 2012 09:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.862
X-Spam-Level: 
X-Spam-Status: No, score=-3.862 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTB-+1PddTBx for ; Wed, 10 Oct 2012 09:03:03 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4645C21F8607 for ; Wed, 10 Oct 2012 09:03:03 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so751813wib.13 for ; Wed, 10 Oct 2012 09:03:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3L4JL13ChDwKxeLl4k0oL5WeEhMcQ0tVBWLM043+7XM=; b=aWcaMDCEfS0GUDiIGdftglmkJSDzXjwVrKaVQ86ckfhCaUsXbxjsFmHgRrYO38d0f+ XWqCMsdU1vN9JVIJr6uCIGXhCAh1OAKmZs59W3k1mcS/bpPYTvfa9KLJ6afOVgzkNnaQ yXpcBfOdxBX6XdTwh4zyZLeag6Ss5C9Y3wQZrnfOd8h5jA7pne6SPvjj3OlJfUoQb/rF 8SR8/02Z5U5xelszpxYVVMlbC6D9+cMMDwiI4nS0Gh1jvqnDiVCTauMY867fV3+2PP1E fxabHWYpXstbxl5f4RePdbaR0n0LZZgb74I2oAz1t9rBIsd4KyJqJPFuzr3sQ94PHLHD ERuw==
MIME-Version: 1.0
Received: by 10.216.141.16 with SMTP id f16mr15734250wej.130.1349884982292; Wed, 10 Oct 2012 09:03:02 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Wed, 10 Oct 2012 09:03:02 -0700 (PDT)
In-Reply-To: <5075864F.3030700@jitsi.org>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org>
Date: Wed, 10 Oct 2012 09:03:02 -0700
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Oct 2012 16:03:04 -0000

I haven't had a lot of time to think about this, but here are some
early comments:

It seems to me that the guidance in Section 6.2 regarding the
unfreezing of check lists needs a little more thought (and
specification).  The goals are clear: "so that checks for the same
media stream [component] would be performed simultaneously by both
agents".  The process by which each peer arrives at this point is less
so.

A naive implementation would use the set of known candidates on each
component to make this determination.  However, that set is
potentially different to the set of candidates known to their peer.
That could cause a mismatch if both peers "unfreeze the first
non-empty checklist."

Several points in the draft presume that this will be made "MUST
implement" for WebRTC.  That assumption is not stated, though it
should be.  In particular, this relates to the decision to require
signaling of support for trickle ICE outside of SDP (a decision that I
need to think about a little more).

--Martin

On 10 October 2012 07:29, Emil Ivov  wrote:
> Hey all,
>
> Eric, Justin and I have just submitted a first version of the
> specification of a mechanism for incremental provisioning of ICE
> candidates, also known as "Trickle ICE".
>
> The spec is in an early state and will undoubtedly see a lot of changes
> as implementations progress. It does however describe the main idea so
> comments and questions are most welcome!
>
> Cheers,
> Emil
>
>
> -------- Original Message --------
> Subject: New Version Notification for
> draft-rescorla-mmusic-ice-trickle-00.txt
> Date: Wed, 10 Oct 2012 07:16:00 -0700
> From: internet-drafts@ietf.org
> To: emcho@jitsi.org
> CC: justin@uberti.name, ekr@rtfm.com
>
>
> A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt
> has been successfully submitted by Emil Ivov and posted to the
> IETF repository.
>
> Filename:        draft-rescorla-mmusic-ice-trickle
> Revision:        00
> Title:           Trickle ICE: Incremental Provisioning of Candidates for the
> Interactive Connectivity Establishment (ICE) Protocol
> Creation date:   2012-10-10
> WG ID:           Individual Submission
> Number of pages: 14
> URL:
> http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle
> Htmlized:
> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00
>
>
> Abstract:
>    This document describes an extension to the Interactive Connectivity
>    Establishment (ICE) protocol that allows ICE agents to send and
>    receive candidates incrementally rather than exchanging complete
>    lists.  With such incremental provisioning, ICE agents can begin
>    connectivity checks while they are still gathering candidates and
>    considerably shorten the time necessary for ICE processing to
>    complete.
>
>    The above mechanism is also referred to as "trickle ICE".
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From christer.holmberg@ericsson.com  Wed Oct 10 11:18:53 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF03F21F84F9 for ; Wed, 10 Oct 2012 11:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.108
X-Spam-Level: 
X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Tymbi5W58t2 for ; Wed, 10 Oct 2012 11:18:53 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A449D21F84D5 for ; Wed, 10 Oct 2012 11:18:52 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-74-5075bc0a3151
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 91.D9.25676.A0CB5705; Wed, 10 Oct 2012 20:18:50 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 10 Oct 2012 20:18:50 +0200
From: Christer Holmberg 
To: Emil Ivov , MMUSIC IETF WG 
Date: Wed, 10 Oct 2012 20:18:49 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2m87HnACo1FkrWQ+uPdBOjq/I3SQABO+FW
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org>
In-Reply-To: <5075864F.3030700@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvrS7XntIAg7v9uhZrdk5gsZi6/DGL A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgytjxfTNzwQa5igk/W5gbGHdKdDFyckgImEhs u3OMDcIWk7hwbz2QzcUhJHCKUWLr4QmsIAkhgbmMEgs/unUxcnCwCVhIdP/TBgmLCDhKXGs5 D9bLIqAqcXv5aiYQW1hAUeLW8U1sEDVKEs+fT2KFsI0kpnU0M4PYvALhEpfetbNBjI+T6Dv8 EyzOKaApcXbJVrA4I9A930+tAZvJLCAucevJfCaIOwUkluw5zwxhi0q8fPyPFaJeVOJO+3pG iHodiQW7P7FB2NoSyxa+htorKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFM5NzMxJLzfS Sy3KTC4uzs/TK07dxAiMj4NbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGLu8y69tNTukdDEp6U/E8Zp31pP+iV09oHd80UEZf8OTnjfZvL40bMor3pDT v+Xg7e/BxyO4V1gtX32Q65LY8ienf0zRlot75m6ayrH25Lv3SlGuzzZzzzhYc6P8Jf/Jy5Of 6FY0t3/0zY1audQ3pU6aJTZOs070/XlXs34elw8716oKnPBfMkuJpTgj0VCLuag4EQDURKjZ XQIAAA==
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Oct 2012 18:18:53 -0000

Hi,

Thanks for submitting the document!

A couple of initial comments.


Q1: Remote endpoint support (SIP):
--------------------------------------------

You say that, before the first offer is sent, one SHOULD determine whether =
the remote endpoint supports trickle ICE.=20

For SIP, you give RFC 3840 as an example. I am not sure how that will work.=
 Yes, you can use 3840 to request that the offer is sent to an entity which=
 supports trickle ICE (for that, btw, you will also need to define an optio=
n tag, or something similar), but you cannot use it to determine whether th=
e remote endpoint supports trickle ICE. In addition, you typically use 3840=
 at the same time when you send the initial offer.

Of course, you could use SIP OPTIONS. But, there are a number of issues rel=
ated to that, and I don't think we want to define a mechanism which relies =
on the usage of OPTIONS.

And, if we simply say that it's "outside the scope of the document", we cou=
ld do the same for BUNDLE, and we wouldn't have issues with re-using the sa=
me ports in multiple m- lines etc :)



Q2: Offer/Answer Alignment:
------------------------------------

I assume the offers and answer are sent according to the rules in RFC 3264.

If so, when you talk about offers and/or answers "being sent at any point",=
 I think it needs to be clear that it's within the rules of 3264.


Q3: Enough is enough:
----------------------------

I think it could be useful for the answerer to tell the offerer that it doe=
sn't want/need any more candidates.




Thanks!

Regards,

Christer





________________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Emil I=
vov [emcho@jitsi.org]
Sent: Wednesday, October 10, 2012 5:29 PM
To: MMUSIC IETF WG
Subject: [MMUSIC] Trickle ICE

Hey all,

Eric, Justin and I have just submitted a first version of the
specification of a mechanism for incremental provisioning of ICE
candidates, also known as "Trickle ICE".

The spec is in an early state and will undoubtedly see a lot of changes
as implementations progress. It does however describe the main idea so
comments and questions are most welcome!

Cheers,
Emil


-------- Original Message --------
Subject: New Version Notification for
draft-rescorla-mmusic-ice-trickle-00.txt
Date: Wed, 10 Oct 2012 07:16:00 -0700
From: internet-drafts@ietf.org
To: emcho@jitsi.org
CC: justin@uberti.name, ekr@rtfm.com


A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:        draft-rescorla-mmusic-ice-trickle
Revision:        00
Title:           Trickle ICE: Incremental Provisioning of Candidates for th=
e
Interactive Connectivity Establishment (ICE) Protocol
Creation date:   2012-10-10
WG ID:           Individual Submission
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.tx=
t
Status:
http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle
Htmlized:
http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00


Abstract:
   This document describes an extension to the Interactive Connectivity
   Establishment (ICE) protocol that allows ICE agents to send and
   receive candidates incrementally rather than exchanging complete
   lists.  With such incremental provisioning, ICE agents can begin
   connectivity checks while they are still gathering candidates and
   considerably shorten the time necessary for ICE processing to
   complete.

   The above mechanism is also referred to as "trickle ICE".





The IETF Secretariat




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic=

From pkyzivat@alum.mit.edu  Wed Oct 10 13:48:38 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DA121F8543 for ; Wed, 10 Oct 2012 13:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.382
X-Spam-Level: 
X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe611zjih4p0 for ; Wed, 10 Oct 2012 13:48:38 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id C949521F853B for ; Wed, 10 Oct 2012 13:48:37 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id 9Pct1k0081HzFnQ5FYp6RQ; Wed, 10 Oct 2012 20:49:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id 9Yjh1k00f3ZTu2S3aYjhxp; Wed, 10 Oct 2012 20:43:41 +0000
Message-ID: <5075DDF8.5070200@alum.mit.edu>
Date: Wed, 10 Oct 2012 16:43:36 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50728B01.5060405@ericsson.com>
In-Reply-To: <50728B01.5060405@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] updating draft-ietf-mmusic-sctp-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Oct 2012 20:48:38 -0000

Salvatore,

Comment/question inline

On 10/8/12 4:12 AM, Salvatore Loreto wrote:
> Hi there,
>
> there has been a quite large discussion within the rtcweb mailing list and
> especially the w3c webrtc mailing list.
>
> Some of the points discussed are specific of how to negotiate the
> 'datachannel' protocol over SDP,
> and I lean on putting those in a separate draft and not in this one.
>
> However there are things that are general enough to is worth to insert
> in this draft
> as they can be used in other protocols that eventually will be specified
> in the future
> running on top of SCTP, or STCP over DTLS.
>
>   'streams' is some of those attributes,
>   so I am proposing to insert in the new version of the draft the
> following text
>
>   xxx.  Streams Attribute
>
>     The 'streams' attribute indicates time the number of streams to be supported by the association.
>     If this attribute is not present, the implementation should provide a default, with a suggested value
>     of 16.
>
>
>           streams-attr           =  "a=streams:" streamsnumbers
>           streamsnumbers         =1*DIGIT
>
>
> As I said, all the other attributes that has been discussed are tied to
> the 'datachannel'  protocol identifier ( to be registered?),
> which is describing the format of the media... so they should go in a
> different draft.

I'm confused by the above. The m-line syntax is:

     m=    ...

and this draft is defining SCTP, SCTP/DTLS and DTLS/SCTP values for 
. Are you suggesting that "datachannel" be defined (in a 
different draft) as an alternative to *these* values? I would think it 
would make more sense to define "datachannel" as a  value.

That brings up another issue:

According to 4566, the values of the  field are protocol specific. 
That means that *this* draft needs to specify how  values are to be 
understood for sctp. That is actually a problem, one might want 
different fmt semantics for each channel.

I have more to say, but I'll start another thread for that.

	Thanks,
	Paul



From pkyzivat@alum.mit.edu  Wed Oct 10 14:17:49 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7FA21F8607 for ; Wed, 10 Oct 2012 14:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.382
X-Spam-Level: 
X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZMOsAd+ea3B for ; Wed, 10 Oct 2012 14:17:48 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 38C8F21F8594 for ; Wed, 10 Oct 2012 14:17:48 -0700 (PDT)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id 9RUd1k00616LCl055ZHsC6; Wed, 10 Oct 2012 21:17:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 9ZCQ1k0093ZTu2S3SZCQ5D; Wed, 10 Oct 2012 21:12:24 +0000
Message-ID: <5075E4CE.7000108@alum.mit.edu>
Date: Wed, 10 Oct 2012 17:12:46 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50728B01.5060405@ericsson.com>
In-Reply-To: <50728B01.5060405@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] draft-ietf-mmusic-sctp-sdp: a concern from CLUE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Oct 2012 21:17:49 -0000

In the clue wg we have need for a data channel for some application 
level signaling. While not yet settled, we have a strong interest in 
using the same SCTP over DTLS mechanism that RTCWEB is using. We have a 
couple of reasons for that:
- it meets our needs for a reliable channel
- rtcweb is doing the work of defining a mechanism that will
   work through NATs, etc.
- we want to make it possible to implement clue in a webrtc client.
   But we don't want to require that clue be implemented over webrtc!

As far as we can see now, clue will only need a single channel.

An webrtc implementation of clue will need to use the webrtc APIs to 
request a channel for clue use. But a native sip implementation of clue 
won't have the webrtc APIs. In sip the natural way to assign something 
like this would be via SDP.

The bottom line for me is that there should be a mechanism via SDP to 
negotiate some SCTP channels for particular uses. If webrtc also wants 
to support dynamic assignment of channels, then the SDP mechanism could 
be used to negotiate a channel over which a dynamic assignment protocol 
can be run.

I realize this is a bit messy. I don't know whether it is better 
discussed in MMUSIC or RTCWEB.

	Thanks,
	Paul

On 10/8/12 4:12 AM, Salvatore Loreto wrote:
> Hi there,
>
> there has been a quite large discussion within the rtcweb mailing list and
> especially the w3c webrtc mailing list.
>
> Some of the points discussed are specific of how to negotiate the
> 'datachannel' protocol over SDP,
> and I lean on putting those in a separate draft and not in this one.
>
> However there are things that are general enough to is worth to insert
> in this draft
> as they can be used in other protocols that eventually will be specified
> in the future
> running on top of SCTP, or STCP over DTLS.
>
>   'streams' is some of those attributes,
>   so I am proposing to insert in the new version of the draft the
> following text
>
>   xxx.  Streams Attribute
>
>     The 'streams' attribute indicates time the number of streams to be supported by the association.
>     If this attribute is not present, the implementation should provide a default, with a suggested value
>     of 16.
>
>
>           streams-attr           =  "a=streams:" streamsnumbers
>           streamsnumbers         =1*DIGIT
>
>
> As I said, all the other attributes that has been discussed are tied to
> the 'datachannel'  protocol identifier ( to be registered?),
> which is describing the format of the media... so they should go in a
> different draft.
>
> opinion, thoughts are welcome and required
>
> thanks
> Salvatore
>
> --
> Salvatore Loreto, PhD
> www.sloreto.com
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From emil@sip-communicator.org  Wed Oct 10 15:46:34 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0380911E808D for ; Wed, 10 Oct 2012 15:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E11Lq0XOOf+7 for ; Wed, 10 Oct 2012 15:46:33 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3C1D21F854F for ; Wed, 10 Oct 2012 15:46:32 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so723840wey.31 for ; Wed, 10 Oct 2012 15:46:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=yAfP+aYBqjG0jf+iJnDPhpK3ebYja1gymGUBZQNSx+Q=; b=M0KFubcIJgovVLxwd+FGoSe+tTOZYVDXA/slwjpFOZmbx3IHY0CGa6PQSpjhVxmthS bY0Z9Tgx1ghHy1GKOkTGaUzKXl65RgV0E8JsoIFQJ3JQr0bFNInJr2h6ZazXBR9ioPoU A90ZmXHTrNEVfjom+151hR5A5+A1d+HEo72nyu5apcXmQBAlxiD4GZELeBa6p0iMEr/O DpsFvRFbJIw1VikrrfK99h4JR1UKL5hue/+JGrLPjzUYWXqDtzdfoo27DSbtd0x5h2FB B0ZUTreHC17xYDQDC0SbqS87ZkJtuCx3SzmkrUpm0LOkO3Coq3l/Yu2KJ0YkIbQhslz+ HiQg==
Received: by 10.180.84.41 with SMTP id v9mr16155842wiy.8.1349909191560; Wed, 10 Oct 2012 15:46:31 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:df4:37b5:8b8b:5b6]) by mx.google.com with ESMTPS id q7sm5253342wiy.11.2012.10.10.15.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 15:46:29 -0700 (PDT)
Message-ID: <5075FAC3.20709@jitsi.org>
Date: Thu, 11 Oct 2012 00:46:27 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnz8RNc+ntM44Qc4p2ynqYqienp3h9rixHY4Jr0rMJHat2rLI2qNYHkl4mJhAUhi3v6ynUR
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Oct 2012 22:46:34 -0000

Hey Martin,

On 10.10.12, 18:03, Martin Thomson wrote:
> I haven't had a lot of time to think about this, but here are some
> early comments:
> 
> It seems to me that the guidance in Section 6.2 regarding the
> unfreezing of check lists needs a little more thought 

Quite likely, yes.

> (and
> specification).  The goals are clear: "so that checks for the same
> media stream [component] would be performed simultaneously by both
> agents". The process by which each peer arrives at this point is less
> so.

Yes, the above sentence may indeed be misleadingly read as "respecting
the order of the streams is all there is to it". What was really meant
was something along the lines of: "respecting the order of streams
improves the chances of the connectivity checks being run simultaneously
for a particular stream/component"

> A naive implementation would use the set of known candidates on each
> component to make this determination.  However, that set is
> potentially different to the set of candidates known to their peer.
> That could cause a mismatch if both peers "unfreeze the first
> non-empty checklist."

Correct, but this is not going to be a problem. When the corresponding
candidates eventually find their way to the agent, it would unfreeze
their local counter-parts and, if necessary, rerun any in-progress or
failed checks. This is explained in Section 9:

   [snip] the agent examines the check
   list looking for another pair that would be redundant with the new
   one.  If such a pair exists and its state is:

   Failed:   the agent chooses the pair with the higher priority local
      candidate, places it in the Waiting state and removes the other
      one as redundant.
   In-Progress:   The agent cancels the in-progress transaction (where
      cancellation happens as explained in Section 7.2.1.4 of
      [RFC5245]), then it chooses the pair with the higher priority
      local candidate, places it in the Waiting state and removes the
      other one as redundant.

Does this sound reasonable or were you referring to something else?

> Several points in the draft presume that this will be made "MUST
> implement" for WebRTC. That assumption is not stated, though
> it should be. 

Mmm ... it might be my lack of IETF experience, but aren't references
supposed to happen the other way around? That is, if RTCWEB decides to
use Trickle ICE, then shouldn't RTCWEB documents be referring to this
spec and making whatever normative declarations they find appropriate?

Besides, trickle ICE is already in use by XMPP apps and SIP will
probably follow. Why would the RTCWEB usage be referred to and not the
others?

> In particular, this relates to the decision to require
> signaling of support for trickle ICE outside of SDP (a decision that I
> need to think about a little more).

Well the idea is that it doesn't really need to be signalling. The
example that we give is about a WebRTC app with no cross domain support.
In this case the WebRTC app can just enable trickle ICE without checking
anything since the remote agent is bound to have it too. Again, it's
just an example. We are not saying this is how it's going to be done for
RTCWEB.

Does this make sense?

Emil

> --Martin
> 
> On 10 October 2012 07:29, Emil Ivov  wrote:
>> Hey all,
>>
>> Eric, Justin and I have just submitted a first version of the
>> specification of a mechanism for incremental provisioning of ICE
>> candidates, also known as "Trickle ICE".
>>
>> The spec is in an early state and will undoubtedly see a lot of changes
>> as implementations progress. It does however describe the main idea so
>> comments and questions are most welcome!
>>
>> Cheers,
>> Emil
>>
>>
>> -------- Original Message --------
>> Subject: New Version Notification for
>> draft-rescorla-mmusic-ice-trickle-00.txt
>> Date: Wed, 10 Oct 2012 07:16:00 -0700
>> From: internet-drafts@ietf.org
>> To: emcho@jitsi.org
>> CC: justin@uberti.name, ekr@rtfm.com
>>
>>
>> A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt
>> has been successfully submitted by Emil Ivov and posted to the
>> IETF repository.
>>
>> Filename:        draft-rescorla-mmusic-ice-trickle
>> Revision:        00
>> Title:           Trickle ICE: Incremental Provisioning of Candidates for the
>> Interactive Connectivity Establishment (ICE) Protocol
>> Creation date:   2012-10-10
>> WG ID:           Individual Submission
>> Number of pages: 14
>> URL:
>> http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle
>> Htmlized:
>> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00
>>
>>
>> Abstract:
>>    This document describes an extension to the Interactive Connectivity
>>    Establishment (ICE) protocol that allows ICE agents to send and
>>    receive candidates incrementally rather than exchanging complete
>>    lists.  With such incremental provisioning, ICE agents can begin
>>    connectivity checks while they are still gathering candidates and
>>    considerably shorten the time necessary for ICE processing to
>>    complete.
>>
>>    The above mechanism is also referred to as "trickle ICE".
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31

From emil@sip-communicator.org  Wed Oct 10 15:48:04 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90D51F041F for ; Wed, 10 Oct 2012 15:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3YPWsG5QxUI for ; Wed, 10 Oct 2012 15:48:03 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 530E521F854F for ; Wed, 10 Oct 2012 15:48:03 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so724469wey.31 for ; Wed, 10 Oct 2012 15:48:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=VLIB8flOm2KMgHxwR2UdG+iZocCjkN+VZ3hFP+8zHZ0=; b=pAE6qlDLFFZYLk5qqja33j9wOCc95jr5UbfudxBtLU340fad4P9D7MzYtoaYI/0N72 oX8gW/lcHjxku2fmrkgsZ5qtRjPJSllU1Xg/+gkMWRow55j8Bueji1DxE+GvvgDepIRr JveEJ62GEginH0sbY70onX8YfxAAQF1SK1kt/qSu8Xi4d+YWc7LVVSJBmCaIjn+dHJyk Zu3BRcAzTlN0WPtQhoafHBHnQd4TX+DDydFnZN/tnYp0+fLP5nYatiyzKAj2XnNnBVTZ tza30dxVAIWvYCspDd9CfbEA2fmC6T2IwJx6kFunEIUH5O/u4Y8virl3mrJTYmSUNzsD Fn0A==
Received: by 10.180.8.134 with SMTP id r6mr16094731wia.18.1349909282520; Wed, 10 Oct 2012 15:48:02 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:df4:37b5:8b8b:5b6]) by mx.google.com with ESMTPS id cn6sm5251992wib.9.2012.10.10.15.48.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 15:48:01 -0700 (PDT)
Message-ID: <5075FB20.6070408@jitsi.org>
Date: Thu, 11 Oct 2012 00:48:00 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnaQKqjjPELDDVXMLUAp+uFMLNdy5o7W/WPMCTDqNzkpaK99K85mckbeq4hwFjVfkENiJPB
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Oct 2012 22:48:04 -0000

Hey Christer,

Thanks for your comments!

Replies inline.

On 10.10.12, 20:18, Christer Holmberg wrote:
> Hi,
> 
> Thanks for submitting the document!
> 
> A couple of initial comments.
> 
> Q1: Remote endpoint support (SIP): 
> --------------------------------------------
> 
> You say that, before the first offer is sent, one SHOULD determine
> whether the remote endpoint supports trickle ICE.
> 
> For SIP, you give RFC 3840 as an example. I am not sure how that will
> work. Yes, you can use 3840 to request that the offer is sent to an
> entity which supports trickle ICE (for that, btw, you will also need
> to define an option tag, or something similar),

Right, but we were hoping this would happen in a separate spec that
details use of trickle ICE with SIP.

> but you cannot use it
> to determine whether the remote endpoint supports trickle ICE. In
> addition, you typically use 3840 at the same time when you send the
> initial offer.
> 
> Of course, you could use SIP OPTIONS.

Yes, that was the idea. The way 3840 describes it in Section 8.

> But, there are a number of issues related to that, 
> and I don't think we want to define a
> mechanism which relies on the usage of OPTIONS.
> 
> And, if we simply say that it's "outside the scope of the document",

I was just about to say that ;).

But, seriously, determining and negotiating caps happens very
differently in different signalling protocols, so it doesn't seem
reasonable to try and find answers for all of them in the generic
trickle ICE spec.

XMPP for example, has this part covered pretty well. If we determine
that 3840 does not provide a way of doing the same then we can find
another way for SIP.

Eric had this idea, where a trickle ICE agent would simply fire a first
offer that only other trickle ICE agents would accept and that any other
SIP endpoint would answer with an error. This would be enough of a check
and if it fails the caller can fall back to vanilla ICE.

Another option would be for trickle ICE agents to send empty INVITEs
that somehow indicate they will be trickling but contain no actual
offer. The offer that the remote side then adds in an OK response (or a
provisional one) would clearly indicate whether they support vanilla,
trickle, or no ICE at all, so the trickle agent would be able to answer
accordingly with the ACK.

> we could do the same for BUNDLE, and we wouldn't have issues with
> re-using the same ports in multiple m- lines etc :)

Well, we are not saying that they should not be addressed at all, or
even now. Just that maybe they shouldn't be addressed by this specific
document.

> Q2: Offer/Answer Alignment: ------------------------------------
> 
> I assume the offers and answer are sent according to the rules in RFC
> 3264.
> 
> If so, when you talk about offers and/or answers "being sent at any
> point", I think it needs to be clear that it's within the rules of
> 3264.

Good point! I think the text is indeed a bit unclear in that regard and
we might be making some non-stated assumptions about the relation
between 3264 Offer/Answer, the actual call answering, and the
connectivity checks phase. We'll fix this.
> 
> 
> Q3: Enough is enough: ----------------------------
> 
> I think it could be useful for the answerer to tell the offerer that
> it doesn't want/need any more candidates.

Yes, sounds useful. Do you have any specific use cases in mind?

I am also wondering what would happen if the answerer says "enough" too
early in the process and causes negotiation to fail. Is there a reason
why an agent would be willing to risk that? Or are we going to say that
it would only do that after finding at least one valid pair for every
component?

Cheers,
Emil

> Thanks!
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> ________________________________________ From:
> mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Emil
> Ivov [emcho@jitsi.org] Sent: Wednesday, October 10, 2012 5:29 PM To:
> MMUSIC IETF WG Subject: [MMUSIC] Trickle ICE
> 
> Hey all,
> 
> Eric, Justin and I have just submitted a first version of the 
> specification of a mechanism for incremental provisioning of ICE 
> candidates, also known as "Trickle ICE".
> 
> The spec is in an early state and will undoubtedly see a lot of
> changes as implementations progress. It does however describe the
> main idea so comments and questions are most welcome!
> 
> Cheers, Emil
> 
> 
> -------- Original Message -------- Subject: New Version Notification
> for draft-rescorla-mmusic-ice-trickle-00.txt Date: Wed, 10 Oct 2012
> 07:16:00 -0700 From: internet-drafts@ietf.org To: emcho@jitsi.org CC:
> justin@uberti.name, ekr@rtfm.com
> 
> 
> A new version of I-D, draft-rescorla-mmusic-ice-trickle-00.txt has
> been successfully submitted by Emil Ivov and posted to the IETF
> repository.
> 
> Filename:        draft-rescorla-mmusic-ice-trickle Revision:
> 00 Title:           Trickle ICE: Incremental Provisioning of
> Candidates for the Interactive Connectivity Establishment (ICE)
> Protocol Creation date:   2012-10-10 WG ID:           Individual
> Submission Number of pages: 14 URL: 
> http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-00.txt
>
> 
Status:
> http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle 
> Htmlized: 
> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00
> 
> 
> Abstract: This document describes an extension to the Interactive
> Connectivity Establishment (ICE) protocol that allows ICE agents to
> send and receive candidates incrementally rather than exchanging
> complete lists.  With such incremental provisioning, ICE agents can
> begin connectivity checks while they are still gathering candidates
> and considerably shorten the time necessary for ICE processing to 
> complete.
> 
> The above mechanism is also referred to as "trickle ICE".
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________ mmusic mailing list 
> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31

From christer.holmberg@ericsson.com  Thu Oct 11 02:53:19 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5209D21F872E for ; Thu, 11 Oct 2012 02:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.125
X-Spam-Level: 
X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0bx7M+xI4Na for ; Thu, 11 Oct 2012 02:53:17 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7518921F8724 for ; Thu, 11 Oct 2012 02:53:16 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-40-5076970af2dc
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9E.65.17130.A0796705; Thu, 11 Oct 2012 11:53:15 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 11 Oct 2012 11:53:12 +0200
From: Christer Holmberg 
To: Emil Ivov 
Date: Thu, 11 Oct 2012 11:53:12 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2nOU5R0f8JuxLnSuW8I5J80vYnDQAW0xKR
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org>
In-Reply-To: <5075FB20.6070408@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvrS739LIAg48fuS3W7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAldFy4C9rwSbliu2P1zA3MH6R7mLk5JAQMJGY PqGHFcIWk7hwbz1bFyMXh5DAKUaJyW/7WEASQgILGSX+T/LqYuTgYBOwkOj+pw0SFhGQl+hu W8QEYjMLqEjsu3eDEcRmEVCV+PLtHJgtLKAocev4JjaIeiWJ588nsULYRhLLV6wCs3kFwiVe XdzADrH3JKNEV+d9sGZOAU2JJ+/nM4PYjEDHfT+1BmqZuMStJ/OZII4WkFiy5zwzhC0q8fLx P1aIelGJO+3rGSHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDI sopRODcxMye93FwvtSgzubg4P0+vOHUTIzByDm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwmrFEKjDe3cHypDo2sClpjhnT66tiJrI+MX8kdOSfRreG Pnq4bN2LHSHXQjZs7X379Jj37GUrFA20wyYGTfQ883T+t50vMp6eszqfuK0rZtedIlbBrgMh 92a+NzFZMuPVn5Lv8rtVvq997PdHxK94d9N5pndfFI8LXLZ9emrh3+PJHAr9yrcsVymxFGck GmoxFxUnAgCDM5p8agIAAA==
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 09:53:19 -0000

Hi,

Q1: Remote endpoint support (SIP):
--------------------------------------------

>> You say that, before the first offer is sent, one SHOULD determine
>> whether the remote endpoint supports trickle ICE.
>>
>> For SIP, you give RFC 3840 as an example. I am not sure how that will
>> work. Yes, you can use 3840 to request that the offer is sent to an
>> entity which supports trickle ICE (for that, btw, you will also need
>> to define an option tag, or something similar),
>
> Right, but we were hoping this would happen in a separate spec that
> details use of trickle ICE with SIP.
>
>> but you cannot use it
>> to determine whether the remote endpoint supports trickle ICE. In
>> addition, you typically use 3840 at the same time when you send the
>> initial offer.
>>
>> Of course, you could use SIP OPTIONS.
>
> Yes, that was the idea. The way 3840 describes it in Section 8.
>
>> But, there are a number of issues related to that,
>> and I don't think we want to define a
>> mechanism which relies on the usage of OPTIONS.
>>
>> And, if we simply say that it's "outside the scope of the document",
>
> I was just about to say that ;).
>
> But, seriously, determining and negotiating caps happens very
> differently in different signalling protocols, so it doesn't seem
> reasonable to try and find answers for all of them in the generic
> trickle ICE spec.
>
> XMPP for example, has this part covered pretty well. If we determine
> that 3840 does not provide a way of doing the same then we can find
> another way for SIP.
>
> Eric had this idea, where a trickle ICE agent would simply fire a first
> offer that only other trickle ICE agents would accept and that any other
> SIP endpoint would answer with an error. This would be enough of a check
> and if it fails the caller can fall back to vanilla ICE.

Sure, but that is not checking for trickle support before sending the trick=
le offer :)

Also, I guess I still haven't completely understood the backward compatibil=
ity issue, but I guess I need to do some more reading.

> Another option would be for trickle ICE agents to send empty INVITEs
> that somehow indicate they will be trickling but contain no actual
> offer. The offer that the remote side then adds in an OK response (or a
> provisional one) would clearly indicate whether they support vanilla,
> trickle, or no ICE at all, so the trickle agent would be able to answer
> accordingly with the ACK.

I don't think we want to rely on empty INVITEs either, because there are a =
number of issues related to that.

>> we could do the same for BUNDLE, and we wouldn't have issues with
>> re-using the same ports in multiple m- lines etc :)
>
> Well, we are not saying that they should not be addressed at all, or
> even now. Just that maybe they shouldn't be addressed by this specific
> document.

Perhaps we shouldn't say anything about finding out in advance, then. At le=
ast not use SHOULD.=20

We CAN describe what may happen if the remote peer does not support trickle=
 ICE, but leave it to that.


Q2: Offer/Answer Alignment:=20
------------------------------------

>> I assume the offers and answer are sent according to the rules in RFC
>> 3264.
>>
>> If so, when you talk about offers and/or answers "being sent at any
>> point", I think it needs to be clear that it's within the rules of
>> 3264.
>
> Good point! I think the text is indeed a bit unclear in that regard and
> we might be making some non-stated assumptions about the relation
> between 3264 Offer/Answer, the actual call answering, and the
> connectivity checks phase. We'll fix this.

Thanx! :)


Q3: Enough is enough:=20
----------------------------

>> I think it could be useful for the answerer to tell the offerer that
>> it doesn't want/need any more candidates.
>
> Yes, sounds useful. Do you have any specific use cases in mind?

Well, I guess any case where the remote peer knows it has a public IP addre=
ss (it will most likely be an ICE lite entity).

> I am also wondering what would happen if the answerer says "enough" too
> early in the process and causes negotiation to fail. Is there a reason
> why an agent would be willing to risk that? Or are we going to say that
> it would only do that after finding at least one valid pair for every
> component?

Well, the indication could mean please-try-whether-the-candidate-works-befo=
re-you-send-me-additional-ones :)

Regards,

Christer=

From emil@sip-communicator.org  Thu Oct 11 05:17:43 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE03521F853A for ; Thu, 11 Oct 2012 05:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuwVmMqMuFPH for ; Thu, 11 Oct 2012 05:17:42 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15021F84E2 for ; Thu, 11 Oct 2012 05:17:42 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hq12so6869500wib.13 for ; Thu, 11 Oct 2012 05:17:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=hF4RPsVXrcOxSLhsBohL50hG+NtjO+L2R1vAmbKa5Yc=; b=aZtOAEU1fRR0QPWBy2w2/rI81i2tJqqawWY2jeLzwFGqtzYv1pHSF7Wn1P6epc2HEj zoTCo1W/R8jDscDnCxsqzVzcV7pJqCYF9XIOiLYx9E3vD1LktwlqWHpdynjY51rrOLkq ENn0lmlqGbnydkpkXwWsBO3PxJ4YvRdzJ/3RsvpxjjYf8soSkJZXUTvtSHpVOsV/zZn4 aYLaQ4f9oYn46uYJjzyHXuS73SUni7uk+dJJHXSFqjF8ao6Y4INTrYlCc4FToIbWIqZe ORZxio5i9/6CBccqXCsEqxCMD32xX7aZbtbxVBSEzxq9szt8hqrfE+jzvOakg7QKURar sewQ==
Received: by 10.180.84.202 with SMTP id b10mr1894555wiz.13.1349957861444; Thu, 11 Oct 2012 05:17:41 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:d4bd:893b:9d69:213d]) by mx.google.com with ESMTPS id ei1sm8415354wid.7.2012.10.11.05.17.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 05:17:40 -0700 (PDT)
Message-ID: <5076B8E4.6050307@jitsi.org>
Date: Thu, 11 Oct 2012 14:17:40 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmpzHLcPgE+vNZY6jZK+M0n87RDra5gqU3y4YTFYMQQjL5nfW7en3WbwTmobvJx932IuYUD
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 12:17:43 -0000

Hey Christer,

On 11.10.12, 11:53, Christer Holmberg wrote:
> Hi,
> 
> Q1: Remote endpoint support (SIP):
> --------------------------------------------
> 
>>> You say that, before the first offer is sent, one SHOULD determine
>>> whether the remote endpoint supports trickle ICE.
>>>
>>> For SIP, you give RFC 3840 as an example. I am not sure how that will
>>> work. Yes, you can use 3840 to request that the offer is sent to an
>>> entity which supports trickle ICE (for that, btw, you will also need
>>> to define an option tag, or something similar),
>>
>> Right, but we were hoping this would happen in a separate spec that
>> details use of trickle ICE with SIP.
>>
>>> but you cannot use it
>>> to determine whether the remote endpoint supports trickle ICE. In
>>> addition, you typically use 3840 at the same time when you send the
>>> initial offer.
>>>
>>> Of course, you could use SIP OPTIONS.
>>
>> Yes, that was the idea. The way 3840 describes it in Section 8.
>>
>>> But, there are a number of issues related to that,
>>> and I don't think we want to define a
>>> mechanism which relies on the usage of OPTIONS.
>>>
>>> And, if we simply say that it's "outside the scope of the document",
>>
>> I was just about to say that ;).
>>
>> But, seriously, determining and negotiating caps happens very
>> differently in different signalling protocols, so it doesn't seem
>> reasonable to try and find answers for all of them in the generic
>> trickle ICE spec.
>>
>> XMPP for example, has this part covered pretty well. If we determine
>> that 3840 does not provide a way of doing the same then we can find
>> another way for SIP.
>>
>> Eric had this idea, where a trickle ICE agent would simply fire a first
>> offer that only other trickle ICE agents would accept and that any other
>> SIP endpoint would answer with an error. This would be enough of a check
>> and if it fails the caller can fall back to vanilla ICE.
> 
> Sure, but that is not checking for trickle support before sending the trickle offer :)

Yes, the wording may need to be reviewed if we go for this.

> Also, I guess I still haven't completely understood the backward compatibility issue, but I guess I need to do some more reading.

We describe these in Section 3 but the main problem is that a vanilla
ICE agent that gets a first subset of candidates (that may also be
empty) would declare failure prematurely.

>> Another option would be for trickle ICE agents to send empty INVITEs
>> that somehow indicate they will be trickling but contain no actual
>> offer. The offer that the remote side then adds in an OK response (or a
>> provisional one) would clearly indicate whether they support vanilla,
>> trickle, or no ICE at all, so the trickle agent would be able to answer
>> accordingly with the ACK.
> 
> I don't think we want to rely on empty INVITEs either, because there are a number of issues related to that.

Well, it might be worth investigating exactly what they are. The same
applies to using OPTIONS and 3840.

>>> we could do the same for BUNDLE, and we wouldn't have issues with
>>> re-using the same ports in multiple m- lines etc :)
>>
>> Well, we are not saying that they should not be addressed at all, or
>> even now. Just that maybe they shouldn't be addressed by this specific
>> document.
> 
> Perhaps we shouldn't say anything about finding out in advance, then. At least not use SHOULD. 
> 
> We CAN describe what may happen if the remote peer does not support trickle ICE, but leave it to that.

What we'd like to avoid is having trickle ICE offers to vanilla ICE
agents and then having them fail in a user-perceptible way.

Maybe we could modify the "SHOULD verify support" to "SHOULD verify
support or provide a mechanism for transparent fallback to vanilla ICE"

> Q2: Offer/Answer Alignment: 
> ------------------------------------
> 
>>> I assume the offers and answer are sent according to the rules in RFC
>>> 3264.
>>>
>>> If so, when you talk about offers and/or answers "being sent at any
>>> point", I think it needs to be clear that it's within the rules of
>>> 3264.
>>
>> Good point! I think the text is indeed a bit unclear in that regard and
>> we might be making some non-stated assumptions about the relation
>> between 3264 Offer/Answer, the actual call answering, and the
>> connectivity checks phase. We'll fix this.
> 
> Thanx! :)
> 
> 
> Q3: Enough is enough: 
> ----------------------------
> 
>>> I think it could be useful for the answerer to tell the offerer that
>>> it doesn't want/need any more candidates.
>>
>> Yes, sounds useful. Do you have any specific use cases in mind?
> 
> Well, I guess any case where the remote peer knows it has a public IP address (it will most likely be an ICE lite entity).

Right, but in such cases the offerer would also know that a certain pair
has succeeded so if they continue it might be with the purpose of
finding a better RTT or a higher priority local candidate.

I guess what I am trying to say is that a Binding Response is enough of
an indication that trickling can stop. If it doesn't then maybe it's for
a reason.

Cheers,
Emil

>> I am also wondering what would happen if the answerer says "enough" too
>> early in the process and causes negotiation to fail. Is there a reason
>> why an agent would be willing to risk that? Or are we going to say that
>> it would only do that after finding at least one valid pair for every
>> component?
> 
> Well, the indication could mean please-try-whether-the-candidate-works-before-you-send-me-additional-ones :)
> 
> Regards,
> 
> Christer
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31

From thomas.stach@siemens-enterprise.com  Thu Oct 11 06:12:55 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C483E21F84B6 for ; Thu, 11 Oct 2012 06:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYxcx55037S1 for ; Thu, 11 Oct 2012 06:12:55 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 44E3E21F849A for ; Thu, 11 Oct 2012 06:12:55 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id DC76B1EB84A9; Thu, 11 Oct 2012 15:12:53 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 15:12:53 +0200
From: "Stach, Thomas" 
To: Christer Holmberg , Harald Alvestrand , Jonathan Lennox , mmusic WG 
Thread-Topic: How does mmt grouping work with multiple streams of the same type?
Thread-Index: Ac2nsiFMoltmMsfNQpqK/fTAiq3/VQ==
Date: Thu, 11 Oct 2012 13:12:52 +0000
Message-ID: 
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 13:12:55 -0000

Christer, Harald, Jonathan,

I have the impression that the draft-holmberg-mmusic-sdp-mmt-negotiation is=
 based on Jonathan's proposal=20
to have an explicit desrciption for the bundled streams as proposed in
http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html

Among other points the following is stated:
* The m=3Dbundle is a complete description of an entirely separate m-line; =
if it's used, the other m-lines in the group are rejected and the informati=
on they carry is ignored.
I think this a desirable property

Now, consider a case were you have 4 streams, i.e. 4 m-lines (e.g. 2 audio =
and 2 video).
How would that be mapped to the m=3Danymedia line?=20
How does mmt grouping work with multiple streams of the same type?

>From the currently proposed syntax for the m=3Danymedia line I cannot deduc=
e that multiple audio or video streams are offered.
I would have to look into the "legacy" m-lines to recognize this.
In case that e.g. the video stream use different codecs, I could also learn=
 that only from the legacy m-lines.

Regards
Thomas



From harald@alvestrand.no  Thu Oct 11 06:38:44 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D1D21F84A2 for ; Thu, 11 Oct 2012 06:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.799
X-Spam-Level: 
X-Spam-Status: No, score=-108.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWAD9QY-EICY for ; Thu, 11 Oct 2012 06:38:43 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 94EBC21F846E for ; Thu, 11 Oct 2012 06:38:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC1E239E0FA; Thu, 11 Oct 2012 15:38:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bulMEeRFZHNO; Thu, 11 Oct 2012 15:38:40 +0200 (CEST)
Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DA2E639E04C; Thu, 11 Oct 2012 15:38:39 +0200 (CEST)
Message-ID: <5076CC50.7000103@alvestrand.no>
Date: Thu, 11 Oct 2012 15:40:32 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Stach, Thomas" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 13:38:44 -0000

On 10/11/2012 03:12 PM, Stach, Thomas wrote:
> Christer, Harald, Jonathan,
>
> I have the impression that the draft-holmberg-mmusic-sdp-mmt-negotiation is based on Jonathan's proposal
> to have an explicit desrciption for the bundled streams as proposed in
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
>
> Among other points the following is stated:
> * The m=bundle is a complete description of an entirely separate m-line; if it's used, the other m-lines in the group are rejected and the information they carry is ignored.
> I think this a desirable property
>
> Now, consider a case were you have 4 streams, i.e. 4 m-lines (e.g. 2 audio and 2 video).
> How would that be mapped to the m=anymedia line?
> How does mmt grouping work with multiple streams of the same type?
>
>  From the currently proposed syntax for the m=anymedia line I cannot deduce that multiple audio or video streams are offered.
> I would have to look into the "legacy" m-lines to recognize this.
> In case that e.g. the video stream use different codecs, I could also learn that only from the legacy m-lines.

In the case where it's desirable to carry multiple video streams in one 
RTP session, and have different descriptions in SDP for the different 
video streams, there has to be some signalling that tells the recipient 
which description applies to which video stream.

The video streams will have different SSRCSs. Therefore, the only 
reasonable answer in the MMT grouping case seems to be SSRC-associated 
signalling.

In the other variants, it's actually unclear to me how the video streams 
described by the different m= lines would be detected by the recipients; 
I'd been assuming SSRC-associated signalling for other reasons, so only 
when this discussion resurfaced, I started thinking about this again, 
and discovered that I didn't have an answer.

That is, in the description

a=group:bundle foo bar baz
m=video 4270
a=mid:foo
a=property-x:1
m=video
a=mid:bar
a=property-x:2
m=video
a=mid:baz
a=property-x:3

one would expect a single RTP stream to be set up; when the recipient 
gets 3 video streams with SSRCS 234, 235 and 236, how does he know which 
stream should have which value for "property-x"?
One can solve it with SSRC-associated signalling in this case too:

a=ssrc:234 property-x:1

but then you're back to doing SSRC-associated signalling, and if you're 
already doing that, we're not very different from the MMT description 
anyway.

That's how I think of it at the moment, anyway - YMMV.




From stefan.lk.hakansson@ericsson.com  Thu Oct 11 07:12:44 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7FF11E80A4 for ; Thu, 11 Oct 2012 07:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bek1DfFgf4w3 for ; Thu, 11 Oct 2012 07:12:39 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EB30021F8775 for ; Thu, 11 Oct 2012 07:12:38 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-0e-5076d3d5f719
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 49.01.04547.5D3D6705; Thu, 11 Oct 2012 16:12:37 +0200 (CEST)
Received: from [150.132.142.225] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 11 Oct 2012 16:12:37 +0200
Message-ID: <5076D3D3.2070108@ericsson.com>
Date: Thu, 11 Oct 2012 16:12:35 +0200
From: Stefan Hakansson LK 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvre7Vy2UBBq1f9S2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI33mxgLXrJVnLj1iK2BcSNrFyMnh4SAicSkC5sYIWwxiQv3 1rN1MXJxCAmcYpTontjJCOGsZZTYe3Q/WAevgLbE7P0v2EBsFgFViddbz4LZbAI2Emu7pzCB 2KICYRLvfh2FqheUODnzCQuILSIgLDHj7V+wemEBI4nWcxfB6pkFbCUuzLnOAmHLS2x/O4cZ xBYS0JV49/oe6wRGvllIRs1C0jILScsCRuZVjMK5iZk56eVGeqlFmcnFxfl5esWpmxiBAXVw y2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Ps5ZLlRx5w b7m+Qe0zb8ipssMlnuWX2hhDKy79OrffXpGVWWy/134Vi8vh81QPxgbv5TV6uO+9Huu1meUH i/RuTH3bO7WaZdLXJPZtLur3kp6syn12+OsU9aTHu/evLtb9vKh5mnXB3B3rVY84MV9L/rfq oLDLt07N7GlPPBcsazp+ofTxIlseJZbijERDLeai4kQAH7feH/YBAAA=
Subject: [MMUSIC]  WG poll for consensus MSID draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 14:12:44 -0000

I'm not a MMUSIC regular, but active in rtcweb. I would like this draft 
to go forward as the info that msid provides is necessary for "gluing 
together" the JS API and the actual rtp streams.

Stefan


"At the last IETF meeting we had a presentation of the following draft:

http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/

At that time, there was interest in solving the problem of cross session 
stream identification.


We would like to poll the working group for consensus on adopting the 
above mentioned draft as a working group item, once we get an approved 
milestone.


If you support this work or have problems with the adoption of this 
document as WG item, please indicate it by replying to this e-mail 
within the next 5 days.


Flemming and Miguel (co-chairs)

--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain"

From thomas.stach@siemens-enterprise.com  Thu Oct 11 07:13:25 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5221F8472 for ; Thu, 11 Oct 2012 07:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level: 
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4026E6S5xecC for ; Thu, 11 Oct 2012 07:13:25 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id DC1B121F8775 for ; Thu, 11 Oct 2012 07:13:24 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 1A17F1EB8481; Thu, 11 Oct 2012 16:13:24 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 16:13:23 +0200
From: "Stach, Thomas" 
To: Harald Alvestrand 
Thread-Topic: How does mmt grouping work with multiple streams of the same type?
Thread-Index: AQHNp7X7oltmMsfNQpqK/fTAiq3/VZe0IqpA
Date: Thu, 11 Oct 2012 14:13:23 +0000
Message-ID: 
References:  <5076CC50.7000103@alvestrand.no>
In-Reply-To: <5076CC50.7000103@alvestrand.no>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 14:13:25 -0000

Harald,

thanks for the reply.
It helps for my second question, but not for my main question.
How can the answerer recognize (from the m=3Danymedia line alone) that mult=
iple video streams need to be set up in the same RTP session?

Regards
Thomas =20

> -----Urspr=FCngliche Nachricht-----
> Von: Harald Alvestrand [mailto:harald@alvestrand.no]=20
> Gesendet: Donnerstag, 11. Oktober 2012 15:41
> An: Stach, Thomas
> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> Betreff: Re: How does mmt grouping work with multiple streams=20
> of the same type?
>=20
> On 10/11/2012 03:12 PM, Stach, Thomas wrote:
> > Christer, Harald, Jonathan,
> >
> > I have the impression that the=20
> draft-holmberg-mmusic-sdp-mmt-negotiation is based on=20
> Jonathan's proposal
> > to have an explicit desrciption for the bundled streams as=20
> proposed in
> > http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
> >
> > Among other points the following is stated:
> > * The m=3Dbundle is a complete description of an entirely=20
> separate m-line; if it's used, the other m-lines in the group=20
> are rejected and the information they carry is ignored.
> > I think this a desirable property
> >
> > Now, consider a case were you have 4 streams, i.e. 4=20
> m-lines (e.g. 2 audio and 2 video).
> > How would that be mapped to the m=3Danymedia line?
> > How does mmt grouping work with multiple streams of the same type?
> >
> >  From the currently proposed syntax for the m=3Danymedia line=20
> I cannot deduce that multiple audio or video streams are offered.
> > I would have to look into the "legacy" m-lines to recognize this.
> > In case that e.g. the video stream use different codecs, I=20
> could also learn that only from the legacy m-lines.
>=20
> In the case where it's desirable to carry multiple video=20
> streams in one=20
> RTP session, and have different descriptions in SDP for the different=20
> video streams, there has to be some signalling that tells the=20
> recipient=20
> which description applies to which video stream.
>=20
> The video streams will have different SSRCSs. Therefore, the only=20
> reasonable answer in the MMT grouping case seems to be=20
> SSRC-associated=20
> signalling.
>=20
> In the other variants, it's actually unclear to me how the=20
> video streams=20
> described by the different m=3D lines would be detected by the=20
> recipients;=20
> I'd been assuming SSRC-associated signalling for other=20
> reasons, so only=20
> when this discussion resurfaced, I started thinking about this again,=20
> and discovered that I didn't have an answer.
>=20
> That is, in the description
>=20
> a=3Dgroup:bundle foo bar baz
> m=3Dvideo 4270
> a=3Dmid:foo
> a=3Dproperty-x:1
> m=3Dvideo
> a=3Dmid:bar
> a=3Dproperty-x:2
> m=3Dvideo
> a=3Dmid:baz
> a=3Dproperty-x:3
>=20
> one would expect a single RTP stream to be set up; when the recipient=20
> gets 3 video streams with SSRCS 234, 235 and 236, how does he=20
> know which=20
> stream should have which value for "property-x"?
> One can solve it with SSRC-associated signalling in this case too:
>=20
> a=3Dssrc:234 property-x:1
>=20
> but then you're back to doing SSRC-associated signalling, and=20
> if you're=20
> already doing that, we're not very different from the MMT description=20
> anyway.
>=20
> That's how I think of it at the moment, anyway - YMMV.
>=20
>=20
>=20
> =

From bernard_aboba@hotmail.com  Thu Oct 11 07:30:16 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A47421F8620 for ; Thu, 11 Oct 2012 07:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.193
X-Spam-Level: 
X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPGklcgcQwAO for ; Thu, 11 Oct 2012 07:30:15 -0700 (PDT)
Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8483B21F844A for ; Thu, 11 Oct 2012 07:30:15 -0700 (PDT)
Received: from BLU169-DS38 ([65.55.111.71]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 11 Oct 2012 07:30:15 -0700
X-Originating-IP: [24.16.96.166]
X-EIP: [iday/s3vSpKtii9ulRid0SIYl1iET5kn]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
From: Bernard Aboba 
To: 
Date: Thu, 11 Oct 2012 07:30:35 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac2nvHwKi0PY4005RheMcN6U2Vremg==
Content-Language: en-us
X-OriginalArrivalTime: 11 Oct 2012 14:30:15.0006 (UTC) FILETIME=[EDDE1FE0:01CDA7BC]
Subject: Re: [MMUSIC] MSID and mslabel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 14:30:16 -0000

Question:  Can someone comment on the difference between msid and the
"mslabel" attribute?

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
Stefan Hakansson LK
Sent: Thursday, October 11, 2012 7:13 AM
To: mmusic@ietf.org
Subject: [MMUSIC] WG poll for consensus MSID draft

I'm not a MMUSIC regular, but active in rtcweb. I would like this draft to
go forward as the info that msid provides is necessary for "gluing together"
the JS API and the actual rtp streams.

Stefan


"At the last IETF meeting we had a presentation of the following draft:

http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/

At that time, there was interest in solving the problem of cross session
stream identification.


We would like to poll the working group for consensus on adopting the 
above mentioned draft as a working group item, once we get an approved 
milestone.


If you support this work or have problems with the adoption of this 
document as WG item, please indicate it by replying to this e-mail 
within the next 5 days.


Flemming and Miguel (co-chairs)

--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain"
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


From harald@alvestrand.no  Thu Oct 11 07:42:59 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FC721F872E for ; Thu, 11 Oct 2012 07:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.799
X-Spam-Level: 
X-Spam-Status: No, score=-108.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryc5axr4KnVR for ; Thu, 11 Oct 2012 07:42:58 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 48CAE21F871D for ; Thu, 11 Oct 2012 07:42:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DD6739E057; Thu, 11 Oct 2012 16:42:56 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNxCgZoDLZhE; Thu, 11 Oct 2012 16:42:55 +0200 (CEST)
Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1661F39E04C; Thu, 11 Oct 2012 16:42:55 +0200 (CEST)
Message-ID: <5076DB5F.5030205@alvestrand.no>
Date: Thu, 11 Oct 2012 16:44:47 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Stach, Thomas" 
References:  <5076CC50.7000103@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 14:42:59 -0000

On 10/11/2012 04:13 PM, Stach, Thomas wrote:
> Harald,
>
> thanks for the reply.
> It helps for my second question, but not for my main question.
> How can the answerer recognize (from the m=anymedia line alone) that multiple video streams need to be set up in the same RTP session?
If each video stream is signalled by the presence of SSRC-associated 
signalling for that video stream, you count the number of video streams 
signalled.

>
> Regards
> Thomas
>
>> -----Ursprüngliche Nachricht-----
>> Von: Harald Alvestrand [mailto:harald@alvestrand.no]
>> Gesendet: Donnerstag, 11. Oktober 2012 15:41
>> An: Stach, Thomas
>> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
>> Betreff: Re: How does mmt grouping work with multiple streams
>> of the same type?
>>
>> On 10/11/2012 03:12 PM, Stach, Thomas wrote:
>>> Christer, Harald, Jonathan,
>>>
>>> I have the impression that the
>> draft-holmberg-mmusic-sdp-mmt-negotiation is based on
>> Jonathan's proposal
>>> to have an explicit desrciption for the bundled streams as
>> proposed in
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
>>>
>>> Among other points the following is stated:
>>> * The m=bundle is a complete description of an entirely
>> separate m-line; if it's used, the other m-lines in the group
>> are rejected and the information they carry is ignored.
>>> I think this a desirable property
>>>
>>> Now, consider a case were you have 4 streams, i.e. 4
>> m-lines (e.g. 2 audio and 2 video).
>>> How would that be mapped to the m=anymedia line?
>>> How does mmt grouping work with multiple streams of the same type?
>>>
>>>   From the currently proposed syntax for the m=anymedia line
>> I cannot deduce that multiple audio or video streams are offered.
>>> I would have to look into the "legacy" m-lines to recognize this.
>>> In case that e.g. the video stream use different codecs, I
>> could also learn that only from the legacy m-lines.
>>
>> In the case where it's desirable to carry multiple video
>> streams in one
>> RTP session, and have different descriptions in SDP for the different
>> video streams, there has to be some signalling that tells the
>> recipient
>> which description applies to which video stream.
>>
>> The video streams will have different SSRCSs. Therefore, the only
>> reasonable answer in the MMT grouping case seems to be
>> SSRC-associated
>> signalling.
>>
>> In the other variants, it's actually unclear to me how the
>> video streams
>> described by the different m= lines would be detected by the
>> recipients;
>> I'd been assuming SSRC-associated signalling for other
>> reasons, so only
>> when this discussion resurfaced, I started thinking about this again,
>> and discovered that I didn't have an answer.
>>
>> That is, in the description
>>
>> a=group:bundle foo bar baz
>> m=video 4270
>> a=mid:foo
>> a=property-x:1
>> m=video
>> a=mid:bar
>> a=property-x:2
>> m=video
>> a=mid:baz
>> a=property-x:3
>>
>> one would expect a single RTP stream to be set up; when the recipient
>> gets 3 video streams with SSRCS 234, 235 and 236, how does he
>> know which
>> stream should have which value for "property-x"?
>> One can solve it with SSRC-associated signalling in this case too:
>>
>> a=ssrc:234 property-x:1
>>
>> but then you're back to doing SSRC-associated signalling, and
>> if you're
>> already doing that, we're not very different from the MMT description
>> anyway.
>>
>> That's how I think of it at the moment, anyway - YMMV.
>>
>>
>>


From thomas.stach@siemens-enterprise.com  Thu Oct 11 07:55:15 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BCC21F86B8 for ; Thu, 11 Oct 2012 07:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.949
X-Spam-Level: 
X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOWYoTT4GXbb for ; Thu, 11 Oct 2012 07:55:14 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0120A21F86C4 for ; Thu, 11 Oct 2012 07:55:13 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id C146E1EB84EB; Thu, 11 Oct 2012 16:55:12 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 16:55:12 +0200
From: "Stach, Thomas" 
To: Harald Alvestrand 
Thread-Topic: AW: How does mmt grouping work with multiple streams of the same type?
Thread-Index: AQHNp760LlzeyMAvekOpo0q27dYr2pe0L52Q
Date: Thu, 11 Oct 2012 14:55:11 +0000
Message-ID: 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>
In-Reply-To: <5076DB5F.5030205@alvestrand.no>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 14:55:15 -0000

inline

> -----Urspr=FCngliche Nachricht-----
> Von: Harald Alvestrand [mailto:harald@alvestrand.no]=20
> Gesendet: Donnerstag, 11. Oktober 2012 16:45
> An: Stach, Thomas
> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> Betreff: Re: AW: How does mmt grouping work with multiple=20
> streams of the same type?
>=20
> On 10/11/2012 04:13 PM, Stach, Thomas wrote:
> > Harald,
> >
> > thanks for the reply.
> > It helps for my second question, but not for my main question.
> > How can the answerer recognize (from the m=3Danymedia line=20
> alone) that multiple video streams need to be set up in the=20
> same RTP session?
> If each video stream is signalled by the presence of SSRC-associated=20
> signalling for that video stream, you count the number of=20
> video streams signalled.

Could that be done by e.g. enhancing the new a=3Dmmtype with an ssrc elemen=
t?
E.g.

       a=3Dmmtype: 0 audio ssrc=3D1
       a=3Dmmtype: 8 audio ssrc=3D1
       a=3Dmmtype: 97 audio ssrc=3D2
       a=3Dmmtype: 31 video ssrc=3D3
       a=3Dmmtype: 32 video ssrc=3D4=20

would mean 2 audio streams and 2 video streams, whereas=20

       a=3Dmmtype: 0 audio ssrc=3D1
       a=3Dmmtype: 8 audio ssrc=3D1
       a=3Dmmtype: 97 audio ssrc=3D1
       a=3Dmmtype: 31 video ssrc=3D2
       a=3Dmmtype: 32 video ssrc=3D2=20

means 1 audio and 1 video stream based on the number of different SSRCs?

>=20
> >
> > Regards
> > Thomas
> >
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: Harald Alvestrand [mailto:harald@alvestrand.no]
> >> Gesendet: Donnerstag, 11. Oktober 2012 15:41
> >> An: Stach, Thomas
> >> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> >> Betreff: Re: How does mmt grouping work with multiple streams
> >> of the same type?
> >>
> >> On 10/11/2012 03:12 PM, Stach, Thomas wrote:
> >>> Christer, Harald, Jonathan,
> >>>
> >>> I have the impression that the
> >> draft-holmberg-mmusic-sdp-mmt-negotiation is based on
> >> Jonathan's proposal
> >>> to have an explicit desrciption for the bundled streams as
> >> proposed in
> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
> >>>
> >>> Among other points the following is stated:
> >>> * The m=3Dbundle is a complete description of an entirely
> >> separate m-line; if it's used, the other m-lines in the group
> >> are rejected and the information they carry is ignored.
> >>> I think this a desirable property
> >>>
> >>> Now, consider a case were you have 4 streams, i.e. 4
> >> m-lines (e.g. 2 audio and 2 video).
> >>> How would that be mapped to the m=3Danymedia line?
> >>> How does mmt grouping work with multiple streams of the same type?
> >>>
> >>>   From the currently proposed syntax for the m=3Danymedia line
> >> I cannot deduce that multiple audio or video streams are offered.
> >>> I would have to look into the "legacy" m-lines to recognize this.
> >>> In case that e.g. the video stream use different codecs, I
> >> could also learn that only from the legacy m-lines.
> >>
> >> In the case where it's desirable to carry multiple video
> >> streams in one
> >> RTP session, and have different descriptions in SDP for=20
> the different
> >> video streams, there has to be some signalling that tells the
> >> recipient
> >> which description applies to which video stream.
> >>
> >> The video streams will have different SSRCSs. Therefore, the only
> >> reasonable answer in the MMT grouping case seems to be
> >> SSRC-associated
> >> signalling.
> >>
> >> In the other variants, it's actually unclear to me how the
> >> video streams
> >> described by the different m=3D lines would be detected by the
> >> recipients;
> >> I'd been assuming SSRC-associated signalling for other
> >> reasons, so only
> >> when this discussion resurfaced, I started thinking about=20
> this again,
> >> and discovered that I didn't have an answer.
> >>
> >> That is, in the description
> >>
> >> a=3Dgroup:bundle foo bar baz
> >> m=3Dvideo 4270
> >> a=3Dmid:foo
> >> a=3Dproperty-x:1
> >> m=3Dvideo
> >> a=3Dmid:bar
> >> a=3Dproperty-x:2
> >> m=3Dvideo
> >> a=3Dmid:baz
> >> a=3Dproperty-x:3
> >>
> >> one would expect a single RTP stream to be set up; when=20
> the recipient
> >> gets 3 video streams with SSRCS 234, 235 and 236, how does he
> >> know which
> >> stream should have which value for "property-x"?
> >> One can solve it with SSRC-associated signalling in this case too:
> >>
> >> a=3Dssrc:234 property-x:1
> >>
> >> but then you're back to doing SSRC-associated signalling, and
> >> if you're
> >> already doing that, we're not very different from the MMT=20
> description
> >> anyway.
> >>
> >> That's how I think of it at the moment, anyway - YMMV.
> >>
> >>
> >>
>=20
> =

From harald@alvestrand.no  Thu Oct 11 08:14:11 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E76F21F866D for ; Thu, 11 Oct 2012 08:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.549
X-Spam-Level: 
X-Spam-Status: No, score=-109.549 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRWPtGjFixIu for ; Thu, 11 Oct 2012 08:14:07 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B368821F8625 for ; Thu, 11 Oct 2012 08:14:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B124039E057; Thu, 11 Oct 2012 17:14:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xhcNMM4OSzo; Thu, 11 Oct 2012 17:14:03 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:3900:9657:23b1:d58d] (unknown [IPv6:2001:470:de0a:27:3900:9657:23b1:d58d]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6668139E04C; Thu, 11 Oct 2012 17:14:03 +0200 (CEST)
Message-ID: <5076E2AB.2070507@alvestrand.no>
Date: Thu, 11 Oct 2012 17:15:55 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Stach, Thomas" 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 15:14:11 -0000

On 10/11/2012 04:55 PM, Stach, Thomas wrote:
> inline
>
>> -----Ursprüngliche Nachricht-----
>> Von: Harald Alvestrand [mailto:harald@alvestrand.no]
>> Gesendet: Donnerstag, 11. Oktober 2012 16:45
>> An: Stach, Thomas
>> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
>> Betreff: Re: AW: How does mmt grouping work with multiple
>> streams of the same type?
>>
>> On 10/11/2012 04:13 PM, Stach, Thomas wrote:
>>> Harald,
>>>
>>> thanks for the reply.
>>> It helps for my second question, but not for my main question.
>>> How can the answerer recognize (from the m=anymedia line
>> alone) that multiple video streams need to be set up in the
>> same RTP session?
>> If each video stream is signalled by the presence of SSRC-associated
>> signalling for that video stream, you count the number of
>> video streams signalled.
> Could that be done by e.g. enhancing the new a=mmtype with an ssrc element?
> E.g.
>
>         a=mmtype: 0 audio ssrc=1
>         a=mmtype: 8 audio ssrc=1
>         a=mmtype: 97 audio ssrc=2
>         a=mmtype: 31 video ssrc=3
>         a=mmtype: 32 video ssrc=4
>
> would mean 2 audio streams and 2 video streams, whereas
>
>         a=mmtype: 0 audio ssrc=1
>         a=mmtype: 8 audio ssrc=1
>         a=mmtype: 97 audio ssrc=1
>         a=mmtype: 31 video ssrc=2
>         a=mmtype: 32 video ssrc=2
>
> means 1 audio and 1 video stream based on the number of different SSRCs?

On the principle of "don't invent new stuff if you already have stuff", 
I think we should continue to use RFC 5576 for this purpose:

a=ssrc:1 

The suggestion above wouldn't work for the case of two SSRCs both using 
the same payload type.

>
>>> Regards
>>> Thomas
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Harald Alvestrand [mailto:harald@alvestrand.no]
>>>> Gesendet: Donnerstag, 11. Oktober 2012 15:41
>>>> An: Stach, Thomas
>>>> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
>>>> Betreff: Re: How does mmt grouping work with multiple streams
>>>> of the same type?
>>>>
>>>> On 10/11/2012 03:12 PM, Stach, Thomas wrote:
>>>>> Christer, Harald, Jonathan,
>>>>>
>>>>> I have the impression that the
>>>> draft-holmberg-mmusic-sdp-mmt-negotiation is based on
>>>> Jonathan's proposal
>>>>> to have an explicit desrciption for the bundled streams as
>>>> proposed in
>>>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
>>>>>
>>>>> Among other points the following is stated:
>>>>> * The m=bundle is a complete description of an entirely
>>>> separate m-line; if it's used, the other m-lines in the group
>>>> are rejected and the information they carry is ignored.
>>>>> I think this a desirable property
>>>>>
>>>>> Now, consider a case were you have 4 streams, i.e. 4
>>>> m-lines (e.g. 2 audio and 2 video).
>>>>> How would that be mapped to the m=anymedia line?
>>>>> How does mmt grouping work with multiple streams of the same type?
>>>>>
>>>>>    From the currently proposed syntax for the m=anymedia line
>>>> I cannot deduce that multiple audio or video streams are offered.
>>>>> I would have to look into the "legacy" m-lines to recognize this.
>>>>> In case that e.g. the video stream use different codecs, I
>>>> could also learn that only from the legacy m-lines.
>>>>
>>>> In the case where it's desirable to carry multiple video
>>>> streams in one
>>>> RTP session, and have different descriptions in SDP for
>> the different
>>>> video streams, there has to be some signalling that tells the
>>>> recipient
>>>> which description applies to which video stream.
>>>>
>>>> The video streams will have different SSRCSs. Therefore, the only
>>>> reasonable answer in the MMT grouping case seems to be
>>>> SSRC-associated
>>>> signalling.
>>>>
>>>> In the other variants, it's actually unclear to me how the
>>>> video streams
>>>> described by the different m= lines would be detected by the
>>>> recipients;
>>>> I'd been assuming SSRC-associated signalling for other
>>>> reasons, so only
>>>> when this discussion resurfaced, I started thinking about
>> this again,
>>>> and discovered that I didn't have an answer.
>>>>
>>>> That is, in the description
>>>>
>>>> a=group:bundle foo bar baz
>>>> m=video 4270
>>>> a=mid:foo
>>>> a=property-x:1
>>>> m=video
>>>> a=mid:bar
>>>> a=property-x:2
>>>> m=video
>>>> a=mid:baz
>>>> a=property-x:3
>>>>
>>>> one would expect a single RTP stream to be set up; when
>> the recipient
>>>> gets 3 video streams with SSRCS 234, 235 and 236, how does he
>>>> know which
>>>> stream should have which value for "property-x"?
>>>> One can solve it with SSRC-associated signalling in this case too:
>>>>
>>>> a=ssrc:234 property-x:1
>>>>
>>>> but then you're back to doing SSRC-associated signalling, and
>>>> if you're
>>>> already doing that, we're not very different from the MMT
>> description
>>>> anyway.
>>>>
>>>> That's how I think of it at the moment, anyway - YMMV.
>>>>
>>>>
>>>>


From salvatore.loreto@ericsson.com  Thu Oct 11 08:28:36 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F8A21F84D6 for ; Thu, 11 Oct 2012 08:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.52
X-Spam-Level: 
X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n6cG2eYAG3C for ; Thu, 11 Oct 2012 08:28:35 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C30BD21F84D4 for ; Thu, 11 Oct 2012 08:28:33 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-2c-5076e59f9600
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C7.F1.17130.F95E6705; Thu, 11 Oct 2012 17:28:32 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 11 Oct 2012 17:28:32 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 7DCBA2AFB	for ; Thu, 11 Oct 2012 18:28:31 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 193535399A	for ; Thu, 11 Oct 2012 18:28:31 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AE0F253981	for ; Thu, 11 Oct 2012 18:28:30 +0300 (EEST)
Message-ID: <5076E59E.3020501@ericsson.com>
Date: Thu, 11 Oct 2012 18:28:30 +0300
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50728B01.5060405@ericsson.com> <5075DDF8.5070200@alum.mit.edu>
In-Reply-To: <5075DDF8.5070200@alum.mit.edu>
Content-Type: multipart/alternative; boundary="------------050404090808070400010801"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+Jvre6Cp2UBBnsXMVpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGdd2vWYsmG5V0XfqAXsD4z7dLkZODgkBE4n9666wQdhiEhfu rQeyuTiEBE4xSqx6tZcZwtnAKDH/YyMjhHORUaLt0wcmCOcIo0Tjh4dQPWcZJY58OMkMMoxX QFvi1L5OdhCbRUBV4kLXWxYQm03ATOL5wy1gNaICyRK983cyQtQLSpyc+QSsRkRAWGLG279g RwkLWEqcPvITzBYS8JZY23AfrIZTQEfi59+7YHOYBcIk2l8cZoF4Qk3i6rlNzBD1WhK9ZzuZ JjAKz0KyYhaSFgjbVuLCnOtQtrzE9rdzmCFsXYkL/6egiC9gZFvFKJybmJmTXm6ul1qUmVxc nJ+nV5y6iREYFwe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGEPFUlfe42WLfBpx5bv6nmzVN59D98s7V0fFX4/Wf/VGSX45f/mtzYbHDhhNidnmyfD5 dI2SZoXkvFMnnMQZ2TUm/Ex9maYtkM1m8fdP7vyjhxm2RvzfU5f4ecuF65vWTFgmGqxunDjr qLrBaqvpARmvbGIvXpbZtNxm2aTut0qx9zVux4cfyVRiKc5INNRiLipOBAB4XL/yWQIAAA==
Subject: Re: [MMUSIC] updating draft-ietf-mmusic-sctp-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 15:28:36 -0000

--------------050404090808070400010801
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 10/10/12 11:43 PM, Paul Kyzivat wrote:
> Salvatore,
>
> Comment/question inline
>
> On 10/8/12 4:12 AM, Salvatore Loreto wrote:
>> Hi there,
>>
>> there has been a quite large discussion within the rtcweb mailing list and
>> especially the w3c webrtc mailing list.
>>
>> Some of the points discussed are specific of how to negotiate the
>> 'datachannel' protocol over SDP,
>> and I lean on putting those in a separate draft and not in this one.
>>
>> However there are things that are general enough to is worth to insert
>> in this draft
>> as they can be used in other protocols that eventually will be specified
>> in the future
>> running on top of SCTP, or STCP over DTLS.
>>
>>    'streams' is some of those attributes,
>>    so I am proposing to insert in the new version of the draft the
>> following text
>>
>>    xxx.  Streams Attribute
>>
>>      The 'streams' attribute indicates time the number of streams to be supported by the association.
>>      If this attribute is not present, the implementation should provide a default, with a suggested value
>>      of 16.
>>
>>
>>            streams-attr           =  "a=streams:" streamsnumbers
>>            streamsnumbers         =1*DIGIT
>>
>>
>> As I said, all the other attributes that has been discussed are tied to
>> the 'datachannel'  protocol identifier ( to be registered?),
>> which is describing the format of the media... so they should go in a
>> different draft.
> I'm confused by the above. The m-line syntax is:
>
>       m=    ...
>
> and this draft is defining SCTP, SCTP/DTLS and DTLS/SCTP values for
> . Are you suggesting that "datachannel" be defined (in a
> different draft) as an alternative to *these* values? I would think it
> would make more sense to define "datachannel" as a  value.
no, I also think that "datachannel" has to be defined as a  value.
sorry not to have been enough clear about that.

> That brings up another issue:
>
> According to 4566, the values of the  field are protocol specific.
> That means that *this* draft needs to specify how  values are to be
> understood for sctp. That is actually a problem, one might want
> different fmt semantics for each channel.

as always you are right, RFC4566 states

     For media using other transport protocols, the  field is
       protocol specific.  Rules for interpretation of the  sub-
       field MUST be defined when registering new protocols (seeSection  
       8.2.2  ).


so we can define simply the data-channel  field as a

     "A bidirectional channel consisting of two SCTP streams."


> I have more to say, but I'll start another thread for that.
let me read it before

thanks for your comments

/Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com


--------------050404090808070400010801
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/10/12 11:43 PM, Paul Kyzivat
      wrote:

    

    

      
Salvatore,

Comment/question inline

On 10/8/12 4:12 AM, Salvatore Loreto wrote:


      

        
Hi there,

there has been a quite large discussion within the rtcweb mailing list and
especially the w3c webrtc mailing list.

Some of the points discussed are specific of how to negotiate the
'datachannel' protocol over SDP,
and I lean on putting those in a separate draft and not in this one.

However there are things that are general enough to is worth to insert
in this draft
as they can be used in other protocols that eventually will be specified
in the future
running on top of SCTP, or STCP over DTLS.

  'streams' is some of those attributes,
  so I am proposing to insert in the new version of the draft the
following text

  xxx.  Streams Attribute

    The 'streams' attribute indicates time the number of streams to be supported by the association.
    If this attribute is not present, the implementation should provide a default, with a suggested value
    of 16.


          streams-attr           =  "a=streams:" streamsnumbers
          streamsnumbers         =1*DIGIT


As I said, all the other attributes that has been discussed are tied to
the 'datachannel'  protocol identifier ( to be registered?),
which is describing the format of the media... so they should go in a
different draft.


      

      
I'm confused by the above. The m-line syntax is:

     m=<media> <port> <proto> <fmt> ...

and this draft is defining SCTP, SCTP/DTLS and DTLS/SCTP values for 
<proto>. Are you suggesting that "datachannel" be defined (in a 
different draft) as an alternative to *these* values? I would think it 
would make more sense to define "datachannel" as a <fmt> value.

    

    no, I also think that "datachannel" has to be defined as a
    <fmt> value.

    sorry not to have been enough clear about that.

    

    

      
That brings up another issue:

According to 4566, the values of the <fmt> field are protocol specific. 
That means that *this* draft needs to specify how <fmt> values are to be 
understood for sctp. That is actually a problem, one might want 
different fmt semantics for each channel.

    

    
    

    as always you are right, RFC4566 states

    

    
    
    For media using other transport protocols, the <fmt> field is
      protocol specific.  Rules for interpretation of the <fmt> sub-
      field MUST be defined when registering new protocols (see Section
      8.2.2).

    

    so we can define simply the data-channel <fmt> field as a

    
    
    "A bidirectional channel consisting of two SCTP streams."



    

    

      
I have more to say, but I'll start another thread for that.

    

    let me read it before 

    

    thanks for your comments

    

    /Salvatore

    
-- 
Salvatore Loreto, PhD
www.sloreto.com

  


--------------050404090808070400010801--

From salvatore.loreto@ericsson.com  Thu Oct 11 08:45:18 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF621F8789 for ; Thu, 11 Oct 2012 08:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.19
X-Spam-Level: 
X-Spam-Status: No, score=-106.19 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j68XJtBLDFux for ; Thu, 11 Oct 2012 08:45:17 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E074B21F877C for ; Thu, 11 Oct 2012 08:45:16 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-b8-5076e98c2a1b
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1D.1D.04547.C89E6705; Thu, 11 Oct 2012 17:45:16 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 11 Oct 2012 17:45:16 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 1AEFD2AFB	for ; Thu, 11 Oct 2012 18:45:16 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CFB465399A	for ; Thu, 11 Oct 2012 18:45:15 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7C60553981	for ; Thu, 11 Oct 2012 18:45:15 +0300 (EEST)
Message-ID: <5076E98B.7030009@ericsson.com>
Date: Thu, 11 Oct 2012 18:45:15 +0300
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50728B01.5060405@ericsson.com> <5075E4CE.7000108@alum.mit.edu>
In-Reply-To: <5075E4CE.7000108@alum.mit.edu>
Content-Type: multipart/alternative; boundary="------------040603090904080601080903"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+JvrW7Py7IAg6XzVSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ1XDrAW/AuvuH75PksD41LXLkZODgkBE4nNt56wQNhiEhfu rWcDsYUETjFKzHzO0cXIBWRvYJQ4PO87O4RzkVFicfNxVgjnCKNE66pPLBAtZxklFnYFgti8 AtoSe68cZQKxWQRUJe7/Ws4OYrMJmEk8f7iFGcQWFUiW6J2/kxGiXlDi5EyIM0QEhCVmvP0L doawgKtE3+xljBDzvSU63n4G6+UU0JH4enYy2HxmgTCJ5+v2s0O8oCZx9dwmZoh6LYnes51M ExiFZyFZMQtJC4RtK3FhznWouLzE9rdzmCFsXYkL/6egiC9gZFvFKJybmJmTXm6kl1qUmVxc nJ+nV5y6iREYEwe3/FbdwXjnnMghRmkOFiVxXuute/yFBNITS1KzU1MLUovii0pzUosPMTJx cEo1MPpt6r628uGC5svHftbsfHr9096MeTfivafx/jw223hSpbW6WPW6ia/O9Eim7Mmffmtr yvmwnv99fW2zhIsvRbtzR9etnJanprjVdnInw7+/VncPHDJtl7hWtWrDtwMx+4/snylwSr5q kdjHGp1L9Wnqk3rly3n7wm/8tfOJ7TeLs34cc3tTxEolluKMREMt5qLiRADeLDflVwIAAA==
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp: a concern from CLUE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 15:45:18 -0000

--------------040603090904080601080903
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 10/11/12 12:12 AM, Paul Kyzivat wrote:
> In the clue wg we have need for a data channel for some application
> level signaling.
what is a data channel for CLUE wg.
As I said in the other thread in 
http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-03
we have the following definitions:

3.  Terminology

    This document uses the following terms:
    Association:  An SCTP association.
    Stream:  A unidirectional stream of an SCTP association.  It is
       uniquely identified by a stream identifier.
    Channel:  A bidirectional channel consisting of two SCTP streams.


>   While not yet settled, we have a strong interest in
> using the same SCTP over DTLS mechanism that RTCWEB is using. We have a
> couple of reasons for that:
> - it meets our needs for a reliable channel
> - rtcweb is doing the work of defining a mechanism that will
>     work through NATs, etc.
great!
> - we want to make it possible to implement clue in a webrtc client.
>     But we don't want to require that clue be implemented over webrtc!

this is reasonable
>
> As far as we can see now, clue will only need a single channel.
then you can do something like

m=application 60878 SCTP/DTLS
c=IN IP4 79.97.215.79
a=fmtp:datachannel streams=1

i.e. you are negotiating to establish an SCTP association with only one 
single stream in each direction,
and use it to establish a datachanel

>
> An webrtc implementation of clue will need to use the webrtc APIs to
> request a channel for clue use. But a native sip implementation of clue
> won't have the webrtc APIs. In sip the natural way to assign something
> like this would be via SDP.
>
> The bottom line for me is that there should be a mechanism via SDP to
> negotiate some SCTP channels for particular uses. If webrtc also wants
> to support dynamic assignment of channels, then the SDP mechanism could
> be used to negotiate a channel over which a dynamic assignment protocol
> can be run.

then perhaps what you need is a way to declare (in a label attribute?) what
you want to run within a specific channel
perhaps something like that

a=datachannel:0 stream=0;label=CLUE


i.e. the only datachannel that you have negotiated use the stream 0 and then
the "label" attribute tell you what you are going to run on top of it.

>
> I realize this is a bit messy. I don't know whether it is better
> discussed in MMUSIC or RTCWEB.

lets discuss in MMUSIC, as all the SPD expert are here!


-- 
Salvatore Loreto, PhD
www.sloreto.com


>
> 	Thanks,
> 	Paul
>
> On 10/8/12 4:12 AM, Salvatore Loreto wrote:
>> Hi there,
>>
>> there has been a quite large discussion within the rtcweb mailing list and
>> especially the w3c webrtc mailing list.
>>
>> Some of the points discussed are specific of how to negotiate the
>> 'datachannel' protocol over SDP,
>> and I lean on putting those in a separate draft and not in this one.
>>
>> However there are things that are general enough to is worth to insert
>> in this draft
>> as they can be used in other protocols that eventually will be specified
>> in the future
>> running on top of SCTP, or STCP over DTLS.
>>
>>    'streams' is some of those attributes,
>>    so I am proposing to insert in the new version of the draft the
>> following text
>>
>>    xxx.  Streams Attribute
>>
>>      The 'streams' attribute indicates time the number of streams to be supported by the association.
>>      If this attribute is not present, the implementation should provide a default, with a suggested value
>>      of 16.
>>
>>
>>            streams-attr           =  "a=streams:" streamsnumbers
>>            streamsnumbers         =1*DIGIT
>>
>>
>> As I said, all the other attributes that has been discussed are tied to
>> the 'datachannel'  protocol identifier ( to be registered?),
>> which is describing the format of the media... so they should go in a
>> different draft.
>>
>> opinion, thoughts are welcome and required
>>
>> thanks
>> Salvatore
>>
>> --
>> Salvatore Loreto, PhD
>> www.sloreto.com
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>



--------------040603090904080601080903
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/11/12 12:12 AM, Paul Kyzivat
      wrote:

    

    

      
In the clue wg we have need for a data channel for some application 
level signaling.

    

    what is a data channel for CLUE wg.

    As I said in the other thread in
    http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-03

    we have the following definitions:

    

    
    
    
3.  Terminology

   This document uses the following terms:
   Association:  An SCTP association.
   Stream:  A unidirectional stream of an SCTP association.  It is
      uniquely identified by a stream identifier.
   Channel:  A bidirectional channel consisting of two SCTP streams.

    

    

      
 While not yet settled, we have a strong interest in 
using the same SCTP over DTLS mechanism that RTCWEB is using. We have a 
couple of reasons for that:
- it meets our needs for a reliable channel
- rtcweb is doing the work of defining a mechanism that will
   work through NATs, etc.

    

    great!

    

      
- we want to make it possible to implement clue in a webrtc client.
   But we don't want to require that clue be implemented over webrtc!

    

    

    this is reasonable

    

      

As far as we can see now, clue will only need a single channel.

    

    then you can do something like 

    

    
m=application 60878 SCTP/DTLS
c=IN IP4 79.97.215.79
a=fmtp:datachannel streams=1



    i.e. you are negotiating to establish an SCTP association with only
    one single stream in each direction,

    and use it to establish a datachanel

    

    

      

An webrtc implementation of clue will need to use the webrtc APIs to 
request a channel for clue use. But a native sip implementation of clue 
won't have the webrtc APIs. In sip the natural way to assign something 
like this would be via SDP.

The bottom line for me is that there should be a mechanism via SDP to 
negotiate some SCTP channels for particular uses. If webrtc also wants 
to support dynamic assignment of channels, then the SDP mechanism could 
be used to negotiate a channel over which a dynamic assignment protocol 
can be run.

    

    

    then perhaps what you need is a way to declare (in a label
    attribute?) what

    you want to run within a specific channel

    perhaps something like that

    
a=datachannel:0 stream=0;label=CLUE

    

    i.e. the only datachannel that you have negotiated use the stream 0
    and then

    the "label" attribute tell you what you are going to run on top of
    it.

    

    

      

I realize this is a bit messy. I don't know whether it is better 
discussed in MMUSIC or RTCWEB.

    

    

    lets discuss in MMUSIC, as all the SPD expert are here!

    

    

    
-- 
Salvatore Loreto, PhD
www.sloreto.com

    

    

      

	Thanks,
	Paul

On 10/8/12 4:12 AM, Salvatore Loreto wrote:


      

        
Hi there,

there has been a quite large discussion within the rtcweb mailing list and
especially the w3c webrtc mailing list.

Some of the points discussed are specific of how to negotiate the
'datachannel' protocol over SDP,
and I lean on putting those in a separate draft and not in this one.

However there are things that are general enough to is worth to insert
in this draft
as they can be used in other protocols that eventually will be specified
in the future
running on top of SCTP, or STCP over DTLS.

  'streams' is some of those attributes,
  so I am proposing to insert in the new version of the draft the
following text

  xxx.  Streams Attribute

    The 'streams' attribute indicates time the number of streams to be supported by the association.
    If this attribute is not present, the implementation should provide a default, with a suggested value
    of 16.


          streams-attr           =  "a=streams:" streamsnumbers
          streamsnumbers         =1*DIGIT


As I said, all the other attributes that has been discussed are tied to
the 'datachannel'  protocol identifier ( to be registered?),
which is describing the format of the media... so they should go in a
different draft.

opinion, thoughts are welcome and required

thanks
Salvatore

--
Salvatore Loreto, PhD
www.sloreto.com



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic



      

      
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic



    

    

    

  


--------------040603090904080601080903--

From pkyzivat@alum.mit.edu  Thu Oct 11 09:04:54 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD7421F8510 for ; Thu, 11 Oct 2012 09:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAZUWfculZDE for ; Thu, 11 Oct 2012 09:04:53 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3121F8508 for ; Thu, 11 Oct 2012 09:04:53 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id 9mGn1k0030Fqzac53s4xtS; Thu, 11 Oct 2012 16:04:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 9rzi1k0133ZTu2S3Urzjhn; Thu, 11 Oct 2012 15:59:43 +0000
Message-ID: <5076ECF7.2090500@alum.mit.edu>
Date: Thu, 11 Oct 2012 11:59:51 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50728B01.5060405@ericsson.com> <5075DDF8.5070200@alum.mit.edu> <5076E59E.3020501@ericsson.com>
In-Reply-To: <5076E59E.3020501@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] updating draft-ietf-mmusic-sctp-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 16:04:54 -0000

On 10/11/12 11:28 AM, Salvatore Loreto wrote:
> On 10/10/12 11:43 PM, Paul Kyzivat wrote:
>> Salvatore,
>>
>> Comment/question inline
>>
>> On 10/8/12 4:12 AM, Salvatore Loreto wrote:
>>> Hi there,
>>>
>>> there has been a quite large discussion within the rtcweb mailing list and
>>> especially the w3c webrtc mailing list.
>>>
>>> Some of the points discussed are specific of how to negotiate the
>>> 'datachannel' protocol over SDP,
>>> and I lean on putting those in a separate draft and not in this one.
>>>
>>> However there are things that are general enough to is worth to insert
>>> in this draft
>>> as they can be used in other protocols that eventually will be specified
>>> in the future
>>> running on top of SCTP, or STCP over DTLS.
>>>
>>>    'streams' is some of those attributes,
>>>    so I am proposing to insert in the new version of the draft the
>>> following text
>>>
>>>    xxx.  Streams Attribute
>>>
>>>      The 'streams' attribute indicates time the number of streams to be supported by the association.
>>>      If this attribute is not present, the implementation should provide a default, with a suggested value
>>>      of 16.
>>>
>>>
>>>            streams-attr           =  "a=streams:" streamsnumbers
>>>            streamsnumbers         =1*DIGIT
>>>
>>>
>>> As I said, all the other attributes that has been discussed are tied to
>>> the 'datachannel'  protocol identifier ( to be registered?),
>>> which is describing the format of the media... so they should go in a
>>> different draft.
>> I'm confused by the above. The m-line syntax is:
>>
>>       m=    ...
>>
>> and this draft is defining SCTP, SCTP/DTLS and DTLS/SCTP values for
>> . Are you suggesting that "datachannel" be defined (in a
>> different draft) as an alternative to *these* values? I would think it
>> would make more sense to define "datachannel" as a  value.
> no, I also think that "datachannel" has to be defined as a  value.
> sorry not to have been enough clear about that.

OK. Glad to have that cleared up.

>> That brings up another issue:
>>
>> According to 4566, the values of the  field are protocol specific.
>> That means that *this* draft needs to specify how  values are to be
>> understood for sctp. That is actually a problem, one might want
>> different fmt semantics for each channel.
>
> as always you are right, RFC4566 states
>
>      For media using other transport protocols, the  field is
>        protocol specific.  Rules for interpretation of the  sub-
>        field MUST be defined when registering new protocols (seeSection  
>        8.2.2  ).
>
> so we can define simply the data-channel  field as a
>
>      "A bidirectional channel consisting of two SCTP streams."

I'm not going to let you get by simply hand waving. :-)

You are proposing to define this syntax with only a single valid value 
for  and no mechanism for extending it???

For RTP the  values are payload type numbers, and there is a rich 
syntax for mapping them to codecs, etc. So this covers many kinds of 
content.

For UDP the  values are MIME subtypes, which when combined with the 
 field give a complete MIME type that defines the packet format 
for UDP packets. The MIME registration procedures provide the way to 
define new wire formats.

I would expect that the definition for SCTP would provide a similarly 
open ended mechanism, that can support various uses of SCTP. Surely 
there will be more uses of SCTP media than just RTCWEB.

Also, SCTP by its nature provides multiple unidirectional channels in 
both directions. The description you give above suggests that you are 
describing the intended RTCWEB usage, where two SCTP channels, one in 
each direction, are semantically bound. And RTCWEB intends to support 
multiple such pairs. The description above says nothing about this. At a 
minimum there should be a reference from the particular  value to a 
specification of the semantics corresponding to that value.

It occurs to me that the nature of SCTP with multiple channels lends 
itself to a  syntax similar to that used for RTP, with "channel 
numbers" being used in a way analogous to payload type numbers with RTP. 
Then there could be a-lines binding particular channel numbers to 
properties of that channel, such as the packet format, etc.

	Thanks,
	Paul


From pkyzivat@alum.mit.edu  Thu Oct 11 09:58:18 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F1021F85C2 for ; Thu, 11 Oct 2012 09:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.22
X-Spam-Level: 
X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[AWL=-0.543,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Eh4Q1TYxYJ5 for ; Thu, 11 Oct 2012 09:58:17 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 866AF21F84A6 for ; Thu, 11 Oct 2012 09:58:17 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta14.westchester.pa.mail.comcast.net with comcast id 9sqp1k0070cZkys5EsyMjP; Thu, 11 Oct 2012 16:58:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id 9stF1k0043ZTu2S3WstF1D; Thu, 11 Oct 2012 16:53:15 +0000
Message-ID: <5076F97C.80203@alum.mit.edu>
Date: Thu, 11 Oct 2012 12:53:16 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50728B01.5060405@ericsson.com> <5075E4CE.7000108@alum.mit.edu> <5076E98B.7030009@ericsson.com>
In-Reply-To: <5076E98B.7030009@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp: a concern from CLUE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 16:58:18 -0000

On 10/11/12 11:45 AM, Salvatore Loreto wrote:
> On 10/11/12 12:12 AM, Paul Kyzivat wrote:
>> In the clue wg we have need for a data channel for some application
>> level signaling.
> what is a data channel for CLUE wg.
> As I said in the other thread in
> http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-03
> we have the following definitions:
>
> 3.  Terminology
>
>     This document uses the following terms:
>     Association:  An SCTP association.
>     Stream:  A unidirectional stream of an SCTP association.  It is
>        uniquely identified by a stream identifier.
>     Channel:  A bidirectional channel consisting of two SCTP streams.

Sorry - I didn't pay enough attention when I re-reviewed the draft and 
forgot the terminology.

Yes, we need a single bidirectional channel for the clue signaling.

There may be reasons to use other channels for separate but related 
purposes. For instance, we are likely to want to use bfcp with clue. If 
there were an SCTP mapping for bfcp then there would be an opportunity 
to use a single SCTP connection with one channel for clue-specific 
signaling and another channel for bfcp. While AFAIK there is currently 
no work to define bfcp over SCTP it would be nice if such a combined use 
could be supported.

>>   While not yet settled, we have a strong interest in
>> using the same SCTP over DTLS mechanism that RTCWEB is using. We have a
>> couple of reasons for that:
>> - it meets our needs for a reliable channel
>> - rtcweb is doing the work of defining a mechanism that will
>>     work through NATs, etc.
> great!
>> - we want to make it possible to implement clue in a webrtc client.
>>     But we don't want to require that clue be implemented over webrtc!
>
> this is reasonable
>>
>> As far as we can see now, clue will only need a single channel.
> then you can do something like
>
> m=application 60878 SCTP/DTLS
> c=IN IP4 79.97.215.79
> a=fmtp:datachannel streams=1
>
> i.e. you are negotiating to establish an SCTP association with only one
> single stream in each direction,
> and use it to establish a datachanel

AFAICT the above doesn't specify what streamids are to be used. As long 
as the number of streams is just 1 this question is moot since the only 
valid value is 0. But in a more general case it is not.

Is the intent that the definition of datachannel means that the streamid 
in each direction is always the same? Or can arbitrary streamids be 
paired into a channel?

>> An webrtc implementation of clue will need to use the webrtc APIs to
>> request a channel for clue use. But a native sip implementation of clue
>> won't have the webrtc APIs. In sip the natural way to assign something
>> like this would be via SDP.
>>
>> The bottom line for me is that there should be a mechanism via SDP to
>> negotiate some SCTP channels for particular uses. If webrtc also wants
>> to support dynamic assignment of channels, then the SDP mechanism could
>> be used to negotiate a channel over which a dynamic assignment protocol
>> can be run.
>
> then perhaps what you need is a way to declare (in a label attribute?) what
> you want to run within a specific channel
> perhaps something like that
>
> a=datachannel:0 stream=0;label=CLUE

> i.e. the only datachannel that you have negotiated use the stream 0 and then
> the "label" attribute tell you what you are going to run on top of it.

Something like that. We would need to work out how the protocol and 
intended use for each channel is signaled. This is very similar to the 
issues now being confronted about signaling information about individual 
RTP streams within a single RTP session.

>> I realize this is a bit messy. I don't know whether it is better
>> discussed in MMUSIC or RTCWEB.
>
> lets discuss in MMUSIC, as all the SPD expert are here!

OK.

	Thanks,
	Paul


From martin.thomson@gmail.com  Thu Oct 11 10:13:19 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0121F86B8 for ; Thu, 11 Oct 2012 10:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.857
X-Spam-Level: 
X-Spam-Status: No, score=-3.857 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca2oShY+TLLl for ; Thu, 11 Oct 2012 10:13:18 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E5E3221F86C3 for ; Thu, 11 Oct 2012 10:13:17 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so2093375wib.13 for ; Thu, 11 Oct 2012 10:13:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xIsSOzKlQgAyt7lOIFpDDgPI+SlCZC8hrQbTRwab6Lg=; b=ioYuKwCk93xynJ5CZcH/q+PsorEiGHt2KNCiU5/7+4dmp7mnKk+DmeBmfcN0r/w0pM fsHF+1UaWpqDd5lKX4jM11a+xbgTnVimVIft0Z1sL/ajZcKDMCAYT2n9Hnj8MF2yJV8I tgIXcs/zu+CEtg7z8vGZ9ZYUVjmlAGCD+G9/QwoL8k/9iHGT6sIcWQaHxW1P7yYzgjFN PWgM08ZfKa2L5X+asiR31jZQn0Hd9pa63TWVNPv6bjSXxsY6gT6+oZyDDXUFRnGlpi88 n5jRSBazqTMm5BDKOvRycnX0iD1ev4ZcO3seGNMn9KMB3JH9+w02QRtDrkUpj/+R4peH UUCw==
MIME-Version: 1.0
Received: by 10.180.93.33 with SMTP id cr1mr22199339wib.8.1349975597009; Thu, 11 Oct 2012 10:13:17 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Thu, 11 Oct 2012 10:13:16 -0700 (PDT)
In-Reply-To: <5075FAC3.20709@jitsi.org>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org>  <5075FAC3.20709@jitsi.org>
Date: Thu, 11 Oct 2012 10:13:16 -0700
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 17:13:19 -0000

On 10 October 2012 15:46, Emil Ivov  wrote:
> Yes, the above sentence may indeed be misleadingly read as "respecting
> the order of the streams is all there is to it". What was really meant
> was something along the lines of: "respecting the order of streams
> improves the chances of the connectivity checks being run simultaneously
> for a particular stream/component"
>
>> A naive implementation would use the set of known candidates on each
>> component to make this determination.  However, that set is
>> potentially different to the set of candidates known to their peer.
>> That could cause a mismatch if both peers "unfreeze the first
>> non-empty checklist."
>
> Correct, but this is not going to be a problem. When the corresponding
> candidates eventually find their way to the agent, it would unfreeze
> their local counter-parts and, if necessary, rerun any in-progress or
> failed checks. This is explained in Section 9:
>
>    [snip] the agent examines the check
>    list looking for another pair that would be redundant with the new
>    one.  If such a pair exists and its state is:
>
>    Failed:   the agent chooses the pair with the higher priority local
>       candidate, places it in the Waiting state and removes the other
>       one as redundant.
>    In-Progress:   The agent cancels the in-progress transaction (where
>       cancellation happens as explained in Section 7.2.1.4 of
>       [RFC5245]), then it chooses the pair with the higher priority
>       local candidate, places it in the Waiting state and removes the
>       other one as redundant.
>
> Does this sound reasonable or were you referring to something else?

Actually, this part in Section 9 wasn't very clear.  I think that the
terms aren't quite right.  "Redundant" and "priority" have specific
meanings in ICE that I think aren't quite right for using here.

This wasn't immediately clear, though I get where you are going with
this.  Though I do think that you need to ensure that this
cancellation doesn't occur to the highest priority"

You aren't talking about priority or redundancy, I think.  You want to
ensure that you are making checks on the first component (of the first
media stream).  What you want is probably more like:

The agent examines the check list and looks for a pair with the same
foundation.  Where multiple such pairs exist, the one from the
component that is first in order is selected.  If an existing pair is
selected, based on its state, the following actions are taken:

 Failed:  The agent marks the new pair as Failed.  [[?: not sure that
this is entirely safe, might need to re-open this one to prevent a
race condition...]]
 In-Progress: If the new pair is for a component [[i.e. media stream +
component]] after the existing pair, the new pair is Frozen.  If the
new pair is for a component that comes before the existing pair's
component the existing pair becomes Frozen, the outstanding
transaction on the existing pair is cancelled, and the new pair is
placed in the Waiting state.
  Waiting: If the new pair is for a component [[i.e. media stream +
component]] after the existing pair, the new pair is Frozen.  If the
new pair is for a component that comes before the existing pair's
component the existing pair becomes Frozen and the new pair is placed
in the Waiting state.
 etc...

Does *that* make sense?

> Mmm ... it might be my lack of IETF experience, but aren't references
> supposed to happen the other way around? That is, if RTCWEB decides to
> use Trickle ICE, then shouldn't RTCWEB documents be referring to this
> spec and making whatever normative declarations they find appropriate?

Yes, but the draft makes the claim about a WebRTC app that is
contacting peers in the same domain.  This makes a big assumption:
namely, that ALL the other entities in that domain implement trickle
ICE.  I infer from this that you are assuming that rtcweb is going to
make this MUST implement, so that you can at least expect all browsers
to implement trickle ICE.  That is if you are assuming that the same
domain is only using browsers.

> Besides, trickle ICE is already in use by XMPP apps and SIP will
> probably follow. Why would the RTCWEB usage be referred to and not the
> others?

SIP may well follow, but that doesn't mean that you can make any
assumptions about support.

>> In particular, this relates to the decision to require
>> signaling of support for trickle ICE outside of SDP (a decision that I
>> need to think about a little more).
>
> Well the idea is that it doesn't really need to be signalling. The
> example that we give is about a WebRTC app with no cross domain support.
> In this case the WebRTC app can just enable trickle ICE without checking
> anything since the remote agent is bound to have it too. Again, it's
> just an example. We are not saying this is how it's going to be done for
> RTCWEB.

You can't send an offer sans candidates and expect it to work.  That's
part of the reason you are writing this draft, as I understand.
Unless you know for certain that the other side implements it.  I
don't think that this is realistic.  Therefore, signaling.

> Does this make sense?

Not entirely ;)

From martin.thomson@gmail.com  Thu Oct 11 10:16:40 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0501021F86C6 for ; Thu, 11 Oct 2012 10:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXBOusVJOt9J for ; Thu, 11 Oct 2012 10:16:39 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C497721F86C3 for ; Thu, 11 Oct 2012 10:16:38 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1080036wgb.13 for ; Thu, 11 Oct 2012 10:16:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NIORz6wPHmrE+6Akw6pqjQ6YTtVFLGaxac9nVCeuVxg=; b=Iv4ad3INoP0YUDHim7i4Dnc/CJZw2CKwps+R8d9VWeIooCojPgLt+tuckQ9dm7SqBX t9vvF0TPmuick6bV2pZWvBp/zByUjqPCos8j+IL5CYVjDzwbQjNyq0JdyWVn8VbW1Y4n v9YZsZsrI0LzGSiIWgqzAt69mxpm7hHsCYOtGwz19utZPVE3L8PB6kFuuMq9mp+hSBUe L+ch0SeBXCdUMNnH+YLsdG8RPtelWLuiUSc0uRm8qYDoCitgodeX6sligOTdvlY+pe5T qYKbjevqbNKsmmq7NAvus6G7Yr/pNR2+hg+1zHdHticNNsZzaoWEul9mR4Umxfo4zZjy hiCA==
MIME-Version: 1.0
Received: by 10.216.209.40 with SMTP id r40mr953795weo.144.1349975797738; Thu, 11 Oct 2012 10:16:37 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Thu, 11 Oct 2012 10:16:37 -0700 (PDT)
In-Reply-To: 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org>  <5075FAC3.20709@jitsi.org> 
Date: Thu, 11 Oct 2012 10:16:37 -0700
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 17:16:40 -0000

Forgot something, inline below...

On 11 October 2012 10:13, Martin Thomson  wrote:
> On 10 October 2012 15:46, Emil Ivov  wrote:
>> Yes, the above sentence may indeed be misleadingly read as "respecting
>> the order of the streams is all there is to it". What was really meant
>> was something along the lines of: "respecting the order of streams
>> improves the chances of the connectivity checks being run simultaneously
>> for a particular stream/component"
>>
>>> A naive implementation would use the set of known candidates on each
>>> component to make this determination.  However, that set is
>>> potentially different to the set of candidates known to their peer.
>>> That could cause a mismatch if both peers "unfreeze the first
>>> non-empty checklist."
>>
>> Correct, but this is not going to be a problem. When the corresponding
>> candidates eventually find their way to the agent, it would unfreeze
>> their local counter-parts and, if necessary, rerun any in-progress or
>> failed checks. This is explained in Section 9:
>>
>>    [snip] the agent examines the check
>>    list looking for another pair that would be redundant with the new
>>    one.  If such a pair exists and its state is:
>>
>>    Failed:   the agent chooses the pair with the higher priority local
>>       candidate, places it in the Waiting state and removes the other
>>       one as redundant.
>>    In-Progress:   The agent cancels the in-progress transaction (where
>>       cancellation happens as explained in Section 7.2.1.4 of
>>       [RFC5245]), then it chooses the pair with the higher priority
>>       local candidate, places it in the Waiting state and removes the
>>       other one as redundant.
>>
>> Does this sound reasonable or were you referring to something else?
>
> Actually, this part in Section 9 wasn't very clear.  I think that the
> terms aren't quite right.  "Redundant" and "priority" have specific
> meanings in ICE that I think aren't quite right for using here.
>
> This wasn't immediately clear, though I get where you are going with
> this.  Though I do think that you need to ensure that this
> cancellation doesn't occur to the highest priority"
>
> You aren't talking about priority or redundancy, I think.  You want to
> ensure that you are making checks on the first component (of the first
> media stream).  What you want is probably more like:
>
> The agent examines the check list and looks for a pair with the same
> foundation.  Where multiple such pairs exist, the one from the
> component that is first in order is selected.  If an existing pair is
> selected, based on its state, the following actions are taken:
>
>  Failed:  The agent marks the new pair as Failed.  [[?: not sure that
> this is entirely safe, might need to re-open this one to prevent a
> race condition...]]
>  In-Progress: If the new pair is for a component [[i.e. media stream +
> component]] after the existing pair, the new pair is Frozen.  If the
> new pair is for a component that comes before the existing pair's
> component the existing pair becomes Frozen, the outstanding
> transaction on the existing pair is cancelled, and the new pair is
> placed in the Waiting state.
>   Waiting: If the new pair is for a component [[i.e. media stream +
> component]] after the existing pair, the new pair is Frozen.  If the
> new pair is for a component that comes before the existing pair's
> component the existing pair becomes Frozen and the new pair is placed
> in the Waiting state.
>  etc...
>
> Does *that* make sense?

Note: we probably also need to note that a transaction can succeed for
a Frozen candidate pair (due to the fact that you can't take a STUN
packet back, so "cancelling" a transaction might still result in a
successful Binding response.  I don't know what you would do with
this, but I'd just move the pair to Succeeded.


>> Mmm ... it might be my lack of IETF experience, but aren't references
>> supposed to happen the other way around? That is, if RTCWEB decides to
>> use Trickle ICE, then shouldn't RTCWEB documents be referring to this
>> spec and making whatever normative declarations they find appropriate?
>
> Yes, but the draft makes the claim about a WebRTC app that is
> contacting peers in the same domain.  This makes a big assumption:
> namely, that ALL the other entities in that domain implement trickle
> ICE.  I infer from this that you are assuming that rtcweb is going to
> make this MUST implement, so that you can at least expect all browsers
> to implement trickle ICE.  That is if you are assuming that the same
> domain is only using browsers.
>
>> Besides, trickle ICE is already in use by XMPP apps and SIP will
>> probably follow. Why would the RTCWEB usage be referred to and not the
>> others?
>
> SIP may well follow, but that doesn't mean that you can make any
> assumptions about support.
>
>>> In particular, this relates to the decision to require
>>> signaling of support for trickle ICE outside of SDP (a decision that I
>>> need to think about a little more).
>>
>> Well the idea is that it doesn't really need to be signalling. The
>> example that we give is about a WebRTC app with no cross domain support.
>> In this case the WebRTC app can just enable trickle ICE without checking
>> anything since the remote agent is bound to have it too. Again, it's
>> just an example. We are not saying this is how it's going to be done for
>> RTCWEB.
>
> You can't send an offer sans candidates and expect it to work.  That's
> part of the reason you are writing this draft, as I understand.
> Unless you know for certain that the other side implements it.  I
> don't think that this is realistic.  Therefore, signaling.
>
>> Does this make sense?
>
> Not entirely ;)

From christer.holmberg@ericsson.com  Thu Oct 11 12:23:30 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F3611E80D2 for ; Thu, 11 Oct 2012 12:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.13
X-Spam-Level: 
X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzHDqrdhZt5V for ; Thu, 11 Oct 2012 12:23:27 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6157921F84F1 for ; Thu, 11 Oct 2012 12:23:26 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-68-50771ca78598
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AE.C4.17130.7AC17705; Thu, 11 Oct 2012 21:23:19 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 11 Oct 2012 21:23:19 +0200
From: Christer Holmberg 
To: 'Emil Ivov' 
Date: Thu, 11 Oct 2012 21:23:18 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2nqmmMInWwRMoFTXe0KE38VnvaCgAMlC6A
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org>
In-Reply-To: <5076B8E4.6050307@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre5ymfIAg4vrDSzW7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlXF5xj3Ggv+mFbt7frA1MH7V6mLk5JAQMJHo +/qeGcIWk7hwbz1bFyMXh5DAKUaJqW/nM0E4Cxkl2lZcYOxi5OBgE7CQ6P6nDdIgIqAo0fxl MxuIzSygIrHv3g1GEJtFQFVi6uI5YHFhoJpbxzexQdQrSTx/PokVwjaS6JtyhQVkJK9AuMSr qdIQq7YxSVyb9ocJpIZTQFNiUuspsOMYgY77fmoNE8QucYlbT+YzQRwtILFkz3moB0QlXj7+ xwpRLypxp309I0S9jsSC3Z+g7tSWWLbwNVg9r4CgxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDI sopRODcxMye93FwvtSgzubg4P0+vOHUTIzByDm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwWgnnKG3PNZecekVkV3d/kdqKw7NipOJ7Z5WdYU1u/uIi tF5z9t7sraE3ZhxKFV7S+VzsScu3nfP/x11Ye0egpH9H2eJkm9NhZo/z65qDFZez33454emC i8+WqqzcOpNbVfRj4z3PKjm+eMmnKmu4TE0izbJTvj38rZRnv9gheuXq1T4X/68zUWIpzkg0 1GIuKk4EAAyWHrpqAgAA
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 19:23:31 -0000

Hi,=20

Q1: Remote endpoint support (SIP):
----------------------------------

>>>> You say that, before the first offer is sent, one SHOULD determine=20
>>>> whether the remote endpoint supports trickle ICE.
>>>>
>>>> For SIP, you give RFC 3840 as an example. I am not sure how that=20
>>>> will work. Yes, you can use 3840 to request that the offer is sent=20
>>>> to an entity which supports trickle ICE (for that, btw, you will=20
>>>> also need to define an option tag, or something similar),
>>>
>>> Right, but we were hoping this would happen in a separate spec that=20
>>> details use of trickle ICE with SIP.
>>>
>>>> but you cannot use it
>>>> to determine whether the remote endpoint supports trickle ICE. In=20
>>>> addition, you typically use 3840 at the same time when you send the=20
>>>> initial offer.
>>>>
>>>> Of course, you could use SIP OPTIONS.
>>>
>>> Yes, that was the idea. The way 3840 describes it in Section 8.
>>>
>>>> But, there are a number of issues related to that, and I don't think=20
>>>> we want to define a mechanism which relies on the usage of OPTIONS.
>>>>
>>>> And, if we simply say that it's "outside the scope of the document",
>>>
>>> I was just about to say that ;).
>>>
>>> But, seriously, determining and negotiating caps happens very=20
>>> differently in different signalling protocols, so it doesn't seem=20
>>> reasonable to try and find answers for all of them in the generic=20
>>> trickle ICE spec.
>>>
>>> XMPP for example, has this part covered pretty well. If we determine=20
>>> that 3840 does not provide a way of doing the same then we can find=20
>>> another way for SIP.
>>>
>>> Eric had this idea, where a trickle ICE agent would simply fire a=20
>>> first offer that only other trickle ICE agents would accept and that=20
>>> any other SIP endpoint would answer with an error. This would be=20
>>> enough of a check and if it fails the caller can fall back to vanilla I=
CE.
>>=20
>> Sure, but that is not checking for trickle support before sending the=20
>> trickle offer :)
>
> Yes, the wording may need to be reviewed if we go for this.
>
>> Also, I guess I still haven't completely understood the backward compati=
bility issue, but I guess I need to do some more reading.
>
> We describe these in Section 3 but the main problem is that a vanilla ICE=
 agent that gets a first subset of candidates (that may also be
> empty) would declare failure prematurely.

The text gives an example where the receiver (Bob) receives a host-candidat=
e-only offer, and start checks which fail.

I think it's quite strange if Bob would reject the call at that point. Beca=
use, no matter how many candidates the offer contains, there might still be=
 peer reflexive candidates created later, once the offerer (Alice) starts s=
ending the STUN binding requests. So, one would think that Bob at least wou=
ld wait for those.

>>> Another option would be for trickle ICE agents to send empty INVITEs=20
>>> that somehow indicate they will be trickling but contain no actual=20
>>> offer. The offer that the remote side then adds in an OK response (or=20
>>> a provisional one) would clearly indicate whether they support=20
>>> vanilla, trickle, or no ICE at all, so the trickle agent would be=20
>>> able to answer accordingly with the ACK.
>>=20
>> I don't think we want to rely on empty INVITEs either, because there are=
 a number of issues related to that.
>
> Well, it might be worth investigating exactly what they are. The same app=
lies to using OPTIONS and 3840.

Well, to start with, empty INVITEs will work very badly with legacy.

In addition, there migth be other functions which do not work with empty IN=
VITEs.

And, I am not sure how it would work with JSEP.


>>>>> we could do the same for BUNDLE, and we wouldn't have issues with=20
>>>>> re-using the same ports in multiple m- lines etc :)
>>>>
>>>> Well, we are not saying that they should not be addressed at all, or=20
>>>> even now. Just that maybe they shouldn't be addressed by this=20
>>>> specific document.
>>>=20
>>> Perhaps we shouldn't say anything about finding out in advance, then. A=
t least not use SHOULD.=20
>>>=20
>>> We CAN describe what may happen if the remote peer does not support tri=
ckle ICE, but leave it to that.
>>
>> What we'd like to avoid is having trickle ICE offers to vanilla ICE agen=
ts and then having them fail in a user-perceptible way.
>>
> Maybe we could modify the "SHOULD verify support" to "SHOULD verify suppo=
rt or provide a mechanism for transparent fallback to vanilla ICE"

In my opinion, if one has to do something extra (e.g. send OPTIONS), the wh=
ole idea of trickle-ICE goes away, because at the end of the day you won't =
save any time in call establishment.

Now, if the browser is communicating with a ICE terminating gateway, and if=
 the browser performs SIP registration, then the gateway can indicate trick=
le-ICE during registration.

But, in the peer-to-peer case I don't know how it would work. It's not even=
 sure OPTIONS would reach the same remote peer as the INVITE...


Q2: Offer/Answer Alignment:=20
---------------------------
=20
>>>> I assume the offers and answer are sent according to the rules in=20
>>>> RFC 3264.
>>>>
>>>> If so, when you talk about offers and/or answers "being sent at any=20
>>>> point", I think it needs to be clear that it's within the rules of=20
>>>> 3264.
>>>
>>> Good point! I think the text is indeed a bit unclear in that regard=20
>>> and we might be making some non-stated assumptions about the relation=20
>>> between 3264 Offer/Answer, the actual call answering, and the=20
>>> connectivity checks phase. We'll fix this.
>>=20
>> Thanx! :)

=20
Q3: Enough is enough:=20
---------------------

>>>> I think it could be useful for the answerer to tell the offerer that=20
>>>> it doesn't want/need any more candidates.
>>>
>>> Yes, sounds useful. Do you have any specific use cases in mind?
>>=20
>> Well, I guess any case where the remote peer knows it has a public IP ad=
dress (it will most likely be an ICE lite entity).
>
> Right, but in such cases the offerer would also know that a certain pair =
has succeeded so if they continue it might be with the purpose of finding a=
 better RTT or a higher priority local candidate.
>
> I guess what I am trying to say is that a Binding Response is enough of a=
n indication that trickling can stop. If it doesn't then maybe it's for a r=
eason.

Maybe it is enough... In any case I think it would be good to document :)

Also, at least in cases where the remote peer only provide a host candidate=
 (because it has a public IP address), one should be smart enough to figure=
 out that there most likely will be no better alternative.


Regards,

Christer


From fandreas@cisco.com  Thu Oct 11 12:35:44 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DE821F8673 for ; Thu, 11 Oct 2012 12:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.575
X-Spam-Level: 
X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN3kgYZ7+VQ2 for ; Thu, 11 Oct 2012 12:35:43 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA4B21F8672 for ; Thu, 11 Oct 2012 12:35:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31122; q=dns/txt; s=iport; t=1349984143; x=1351193743; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ELiQFEv85hjj763VHTH2yb2uceSSQHriCEsPJdv0LHA=; b=Q/0I0UcWWtK/WAmDbSUC5zGbTPYuIKNiJvUR8MYTKxOvOZi62wNIvMPF sBsClAGqYYcd6Dbe1enlPjHBVzVNoqx+IhyXqRDPbIWE/3/mtGmTq2KCX HUwSKzQjXsdzD3v8+sFOHVmCIhhBBjlLHJ3FYd0dD7X8M+DddgEcIBU+y o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAHged1CtJXHA/2dsb2JhbABEv1WBCIIgAQEBBAEBAQ8BCkoHChELGAkWAQENCQMCAQIBFTAGAQwGAgEBBRIHh2ILmVKgMYtHCoYWA5VtjkWBa4MJ
X-IronPort-AV: E=Sophos;i="4.80,573,1344211200";  d="scan'208,217";a="127717995"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 11 Oct 2012 19:35:42 +0000
Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9BJZfC4021171;  Thu, 11 Oct 2012 19:35:41 GMT
Message-ID: <50771F8D.8040004@cisco.com>
Date: Thu, 11 Oct 2012 15:35:41 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org
References: <505FD907.9070800@cisco.com>
In-Reply-To: <505FD907.9070800@cisco.com>
Content-Type: multipart/alternative; boundary="------------040704070609050205060406"
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-05
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 19:35:44 -0000

This is a multi-part message in MIME format.
--------------040704070609050205060406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I have reviewed the RTSP NAT Evaluation document and have several 
comments on it, both technical and editorial. I will provide the main 
technical comments below and send the minor and editorial comments 
directly to the authors in a more "user-friendly" format.


Major comments

- STUN based on either RFC 3489 or RFC 5389 (or both). The draft 
discusses use of STUN as a NAT traversal mechanism (with some RTSP 
operational "extensions"), and in so doing it references both RFC 3489 
(which is obsolete) and RFC 5389 (the replacement). Furthermore, in 
several places, it bases and describes operation on now defunct 
(obsolete) RFC 3489 logic and messages instead of RFC 5389. This either 
needs to be rectified, or we should have a very good explanation in the 
document as to why we are using RFC 3489 (and then be clear which parts 
are based on RFC 3489 and which are based on RFC 5389).

- "Symmetric RTP" is called out as a potential solution for NAT 
traversal with 3 different variations. Note that symmetric RTP is 
defined in RFC 4961, and what is described in this document as 
"symmetric RTP" looks a lot more like latching to me, with all the 
potential issues that brings (and then some due to the shared use of 
ports and hence shared SSRC space between different clients, as noted in 
the document). The document needs to clear up its terminology in this 
area ("connect", "binding", latch, symmetric RTP, etc.) and be clearer 
about what is being proposed (which is latching as far as I can tell, 
however it makes reference to certain mechanisms that aren't fully 
described, e.g. binding packets with random nonces).


Other significant comments

- The draft intends to investigate and outline different RTSP NAT 
traversal proposals with the goal of picking one for further detailed 
specification (which can be found in the draft-ietf-mmusic-rtsp-nat 
spec). There is a mixture of RFC 2119 language and more informal 
language in several of these descriptions. Given that these are 
high-level descriptions and have not been specified in detail, I do not 
think we should give any other impression and hence I think RFC 2119 
language should be avoided.

- The draft suggests that the RTSP server needs to enforce that 
signaling and media come from the same IP-address as a security remedy 
in several places, however this may not work with larger scale NATs 
(e.g. carrier-grade NATs) where the NAT may be using more than one 
external IP-address.

- The comparison section is missing two of the alternatives considered 
(namely ALG and TCP tunneling). Also, the comparison chart would lead 
most people to a different solution than the one chosen. To some extent, 
I think it's because the requirements list is a simplified list of all 
the considerations behind each of the proposals (as more fully explained 
in the document overall). There are additional drawbacks to some of 
these other solutions that do not show up in the table (e.g. 
unauthenticated "latching" and requirement for RTSP server to have 
public IP-address). It would be worthwhile briefly recapping those and 
hence further motivate the choice of ICE in this section.

Thanks

-- Flemming



On 9/23/12 11:52 PM, Flemming Andreasen wrote:
> This is to announce a 2 week Working Group Last Call for
>
>     draft-ietf-mmusic-rtsp-nat-evaluation-05
>
> as Informational. Please review and provide any comments you may have 
> on the document by October 7, 2012. Comments should be sent to the 
> document authors and the MMUSIC WG list. If you review the document 
> but do not have any comments, please send a note to that effect as well.
>
>
> Thanks
>
>        Flemming
>
>
>
> Draft Info:
>
> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>
> 	Title           : The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
> 	Author(s)       : Magnus Westerlund
>                            Thomas Zeng
> 	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
> 	Pages           : 38
> 	Date            : 2012-05-07
>
>     This document describes several Network Address Translator (NAT)
>     traversal techniques that was considered to be used by Real-time
>     Streaming Protocol (RTSP).  Each technique includes a description on
>     how it would be used, the security implications of using it and any
>     other deployment considerations it has.  There are also disussions on
>     how NAT traversal techniques relates to firewalls and how each
>     technique can be applied in different use cases.  These findings
>     where used when selecting the NAT traversal for RTSP 2.0 standardized
>     in the MMUSIC WG.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--------------040704070609050205060406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I have reviewed the RTSP NAT Evaluation document and have several
    comments on it, both technical and editorial. I will provide the
    main technical comments below and send the minor and editorial
    comments directly to the authors in a more "user-friendly" format. 

    

    

    Major comments

    

    - STUN based on either RFC 3489 or RFC 5389 (or both). The draft
    discusses use of STUN as a NAT traversal mechanism (with some RTSP
    operational "extensions"), and in so doing it references both RFC
    3489 (which is obsolete) and RFC 5389 (the replacement).
    Furthermore, in several places, it bases and describes operation on
    now defunct (obsolete) RFC 3489 logic and messages instead of RFC
    5389. This either needs to be rectified, or we should have a very
    good explanation in the document as to why we are using RFC 3489
    (and then be clear which parts are based on RFC 3489 and which are
    based on RFC 5389). 

    

    - "Symmetric RTP" is called out as a potential solution for NAT
    traversal with 3 different variations. Note that symmetric RTP is
    defined in RFC 4961, and what is described in this document as
    "symmetric RTP" looks a lot more like latching to me, with all the
    potential issues that brings (and then some due to the shared use of
    ports and hence shared SSRC space between different clients, as
    noted in the document). The document needs to clear up its
    terminology in this area ("connect", "binding", latch, symmetric
    RTP, etc.) and be clearer about what is being proposed (which is
    latching as far as I can tell, however it makes reference to certain
    mechanisms that aren't fully described, e.g. binding packets with
    random nonces). 

    

    

    Other significant comments

    

    - The draft intends to investigate and outline different RTSP NAT
    traversal proposals with the goal of picking one for further
    detailed specification (which can be found in the
    draft-ietf-mmusic-rtsp-nat spec). There is a mixture of RFC 2119
    language and more informal language in several of these
    descriptions. Given that these are high-level descriptions and have
    not been specified in detail, I do not think we should give any
    other impression and hence I think RFC 2119 language should be
    avoided. 

    

    - The draft suggests that the RTSP server needs to enforce that
    signaling and media come from the same IP-address as a security
    remedy in several places, however this may not work with larger
    scale NATs (e.g. carrier-grade NATs) where the NAT may be using more
    than one external IP-address. 

    

    - The comparison section is missing two of the alternatives
    considered (namely ALG and TCP tunneling). Also, the comparison
    chart would lead most people to a different solution than the one
    chosen. To some extent, I think it's because the requirements list
    is a simplified list of all the considerations behind each of the
    proposals (as more fully explained in the document overall). There
    are additional drawbacks to some of these other solutions that do
    not show up in the table (e.g. unauthenticated "latching" and
    requirement for RTSP server to have public IP-address). It would be
    worthwhile briefly recapping those and hence further motivate the
    choice of ICE in this section. 

    

    Thanks 

    

    -- Flemming 

    

    

    

    
On 9/23/12 11:52 PM, Flemming Andreasen
      wrote:

    

    

      
      This is to announce a 2 week
                    Working Group Last Call for

      

          draft-ietf-mmusic-rtsp-nat-evaluation-05

                    

                    as Informational. Please review and provide any
                    comments you may have on the document by October 7,
                    2012. Comments should be sent to the document
                    authors and the MMUSIC WG list. If you review the
                    document but do not have any comments, please send a
                    note to that effect as well. 

                    

                    

                                  Thanks 

                                  

                                         Flemming

                                  

                                  

                                  

                                  Draft Info:

                                

      
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
	Author(s)       : Magnus Westerlund
                          Thomas Zeng
	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
	Pages           : 38
	Date            : 2012-05-07

   This document describes several Network Address Translator (NAT)
   traversal techniques that was considered to be used by Real-time
   Streaming Protocol (RTSP).  Each technique includes a description on
   how it would be used, the security implications of using it and any
   other deployment considerations it has.  There are also disussions on
   how NAT traversal techniques relates to firewalls and how each
   technique can be applied in different use cases.  These findings
   where used when selecting the NAT traversal for RTSP 2.0 standardized
   in the MMUSIC WG.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/

      

                                
      

      

      

      
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


    

    

  


--------------040704070609050205060406--

From fandreas@cisco.com  Thu Oct 11 12:57:59 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3522E11E8097 for ; Thu, 11 Oct 2012 12:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.577
X-Spam-Level: 
X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 274kWGJR6que for ; Thu, 11 Oct 2012 12:57:58 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3F08321F861B for ; Thu, 11 Oct 2012 12:57:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4216; q=dns/txt; s=iport; t=1349985478; x=1351195078; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=piKnu9gTFGsXYL1J+S9oJd5TwmCinVPJm951kujMwoQ=; b=mDL9cpzK7kTqCtrY8rUWXmpIFPmittd6LxTsK7+kXFW9THKpzMb8pKev t553X3qNo+KWAPFs9gvQsIcgbyrjmmqvoB18G9TfCUDNTLMg8WR3Pi0BV mEk+6ctTeeVFHFI34sOOvo1a/J3w/5loUzl7J1+g3pvphEjownZ78oEA9 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADIkd1CtJV2Y/2dsb2JhbABEv1WBCIIgAQEBBAEBAQ8BJTMDCgEQCxgJDwcPCQMCAQIBFTAGDQEFAgEBBRIHh2ILmUegL45Igx8DlW2BFYoRgx+Ba4MJ
X-IronPort-AV: E=Sophos;i="4.80,573,1344211200"; d="scan'208";a="130725383"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 11 Oct 2012 19:57:57 +0000
Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9BJvuKM020538;  Thu, 11 Oct 2012 19:57:56 GMT
Message-ID: <507724C4.5090601@cisco.com>
Date: Thu, 11 Oct 2012 15:57:56 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Magnus Westerlund 
References: <20120507075517.12573.64357.idtracker@ietfa.amsl.com> <4FA78A27.4040004@ericsson.com>
In-Reply-To: <4FA78A27.4040004@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "mmusic \(E-mail\)" 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 19:57:59 -0000

Hi Magnus

I have taken a look at the document and, the only real technical 
comments I have at this point are:

- Section 6.3 (Non-Supporting Proxies), last paragraph says that:

This variance in results is the reason
    we don't recommend the usage of the Proxy-Require header. Instead we
    recommend the usage of the Supported header to force proxies to
    include the feature tags they support in the proxy-supported which
    will provide a positive indication when all proxies in the chain
    between the client and server support the functionality.  Even if not
    explicitly indicating support, any SETUP response including a
    transport specification with "D-ICE" will be implicit indication that
    the proxy chain supports at least passthrough of this media.


I didn't follow the inferred logic in the last sentence (how does the 
response convey support for the entire chain). Can you elaborate on that 
part ?

- Section 8 (Fallback)
Section title and overall description is a bit confusing (it seems to be 
about about backwards compatibility with non-ICE supporting RTSP entities).
Also, the section recommends use of defunct (obsolete) behavior defined 
in RFC 3489 to try and determine the NAT type. Why is that (shouldn't we 
be based on RFC 5389) ?


I have some editorial/minor comments as well that I will send to the 
authors directly.

Also, we could really use another set of eyes on it (preferably by 
somebody that has both ICE and RTSP expertise)

Thanks

-- Flemming


On 5/7/12 4:39 AM, Magnus Westerlund wrote:
> WG,
>
> This version of the RTSP NAT specification contains some actual changes.
>
> - Specifies how one may Optionally use RFC 6544 TCP based candidates
> with RTSP.
>
> - Found a syntax bug related to ICE password and ufrag. They may
> contain characters that aren't allowed outside of double quote in RTSP
> transport parameters. Thus the syntax has been changed to put the
> password and ufrag values inside double quotes.
>
> - Updated IANA section to better meet the respective registries rules.
>
> - A number of editorial changes.
>
> Diff from the previous version.
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-12
>
> I would appreciate a review of this to confirm that this document is in
> fact ready for WG last call.
>
> Thanks
>
> Magnus Westerlund
>
>
> On 2012-05-07 09:55, 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           : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)
>> 	Author(s)       : Jeff Goldberg
>>                            Magnus Westerlund
>>                            Thomas Zeng
>> 	Filename        : draft-ietf-mmusic-rtsp-nat-12.txt
>> 	Pages           : 30
>> 	Date            : 2012-05-07
>>
>>     This document defines a solution for Network Address Translation
>>     (NAT) traversal for datagram based media streams setup and controlled
>>     with Real-time Streaming Protocol version 2 (RTSP 2.0).  It uses
>>     Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
>>     signalling channel, defining the necessary extra RTSP extensions and
>>     procedures.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-12.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-12.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>


From oej@edvina.net  Thu Oct 11 13:00:26 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AEF1F0C3E for ; Thu, 11 Oct 2012 13:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qn3SdOWuuUM for ; Thu, 11 Oct 2012 13:00:25 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4521F862B for ; Thu, 11 Oct 2012 13:00:24 -0700 (PDT)
Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6B3E6754A8A7; Thu, 11 Oct 2012 20:00:22 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
Date: Thu, 11 Oct 2012 22:00:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <39EF1F75-DE97-4175-89A5-6A26278883A5@edvina.net>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg 
X-Mailer: Apple Mail (2.1499)
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 20:00:26 -0000

11 okt 2012 kl. 11:53 skrev Christer Holmberg =
:

> Hi,
>=20
> Q1: Remote endpoint support (SIP):
> --------------------------------------------
>=20
>>> You say that, before the first offer is sent, one SHOULD determine
>>> whether the remote endpoint supports trickle ICE.
>>>=20
>>> For SIP, you give RFC 3840 as an example. I am not sure how that =
will
>>> work. Yes, you can use 3840 to request that the offer is sent to an
>>> entity which supports trickle ICE (for that, btw, you will also need
>>> to define an option tag, or something similar),
>>=20
>> Right, but we were hoping this would happen in a separate spec that
>> details use of trickle ICE with SIP.

I think that we should start that work in parallell. Doing trickle ICE =
with SIP O/A
can be trick(l)y and the solution for that may affect the Trickly ICE =
core.

I do think trickle ICE will help SIP quite a lot, especially in a b2bua =
situation.

/O

>>=20
>>> but you cannot use it
>>> to determine whether the remote endpoint supports trickle ICE. In
>>> addition, you typically use 3840 at the same time when you send the
>>> initial offer.
>>>=20
>>> Of course, you could use SIP OPTIONS.
>>=20
>> Yes, that was the idea. The way 3840 describes it in Section 8.
>>=20
>>> But, there are a number of issues related to that,
>>> and I don't think we want to define a
>>> mechanism which relies on the usage of OPTIONS.
>>>=20
>>> And, if we simply say that it's "outside the scope of the document",
>>=20
>> I was just about to say that ;).
>>=20
>> But, seriously, determining and negotiating caps happens very
>> differently in different signalling protocols, so it doesn't seem
>> reasonable to try and find answers for all of them in the generic
>> trickle ICE spec.
>>=20
>> XMPP for example, has this part covered pretty well. If we determine
>> that 3840 does not provide a way of doing the same then we can find
>> another way for SIP.
>>=20
>> Eric had this idea, where a trickle ICE agent would simply fire a =
first
>> offer that only other trickle ICE agents would accept and that any =
other
>> SIP endpoint would answer with an error. This would be enough of a =
check
>> and if it fails the caller can fall back to vanilla ICE.
>=20
> Sure, but that is not checking for trickle support before sending the =
trickle offer :)
>=20
> Also, I guess I still haven't completely understood the backward =
compatibility issue, but I guess I need to do some more reading.
>=20
>> Another option would be for trickle ICE agents to send empty INVITEs
>> that somehow indicate they will be trickling but contain no actual
>> offer. The offer that the remote side then adds in an OK response (or =
a
>> provisional one) would clearly indicate whether they support vanilla,
>> trickle, or no ICE at all, so the trickle agent would be able to =
answer
>> accordingly with the ACK.
>=20
> I don't think we want to rely on empty INVITEs either, because there =
are a number of issues related to that.
>=20
>>> we could do the same for BUNDLE, and we wouldn't have issues with
>>> re-using the same ports in multiple m- lines etc :)
>>=20
>> Well, we are not saying that they should not be addressed at all, or
>> even now. Just that maybe they shouldn't be addressed by this =
specific
>> document.
>=20
> Perhaps we shouldn't say anything about finding out in advance, then. =
At least not use SHOULD.=20
>=20
> We CAN describe what may happen if the remote peer does not support =
trickle ICE, but leave it to that.
>=20
>=20
> Q2: Offer/Answer Alignment:=20
> ------------------------------------
>=20
>>> I assume the offers and answer are sent according to the rules in =
RFC
>>> 3264.
>>>=20
>>> If so, when you talk about offers and/or answers "being sent at any
>>> point", I think it needs to be clear that it's within the rules of
>>> 3264.
>>=20
>> Good point! I think the text is indeed a bit unclear in that regard =
and
>> we might be making some non-stated assumptions about the relation
>> between 3264 Offer/Answer, the actual call answering, and the
>> connectivity checks phase. We'll fix this.
>=20
> Thanx! :)
>=20
>=20
> Q3: Enough is enough:=20
> ----------------------------
>=20
>>> I think it could be useful for the answerer to tell the offerer that
>>> it doesn't want/need any more candidates.
>>=20
>> Yes, sounds useful. Do you have any specific use cases in mind?
>=20
> Well, I guess any case where the remote peer knows it has a public IP =
address (it will most likely be an ICE lite entity).
>=20
>> I am also wondering what would happen if the answerer says "enough" =
too
>> early in the process and causes negotiation to fail. Is there a =
reason
>> why an agent would be willing to risk that? Or are we going to say =
that
>> it would only do that after finding at least one valid pair for every
>> component?
>=20
> Well, the indication could mean =
please-try-whether-the-candidate-works-before-you-send-me-additional-ones =
:)
>=20
> Regards,
>=20
> Christer
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From emil@sip-communicator.org  Thu Oct 11 14:34:38 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7836D1F0C4A for ; Thu, 11 Oct 2012 14:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxtKqwnQAgCs for ; Thu, 11 Oct 2012 14:34:37 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1BB1F041F for ; Thu, 11 Oct 2012 14:34:36 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so1454146wey.31 for ; Thu, 11 Oct 2012 14:34:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=biR9rg87XOfbHn7QwE4io3vKxSeWLpq7dd5jCWE8/PI=; b=GiP8kZmTE/Em0XqZFGCgKzmnQi7iCuV/Uy55jjZly35ACUdsaMtXN08ceRDA6Kxa5o 9FD2Bswd0LEkAG68uqBYyHMCDvTLfBkyWRaoD7MjpL9lv3Pha0fuZEiCQED2oLzDL9bN w0lmNCLEZr9g/l64VGIiM/jQqbM1U4yTPEqZUpdU3J8MjiKcL9MSgihNMj9War7LKEnB 6BkqdbVUi6ywWvqcltwZ5f+lofMtOr4N5FBNKdrY6bcLCpDo46NMBisGx/yGJPSE3Qvp SboLl3F1AqNXj/tC1rnGopXxrpHnMz0Osf+mFvYXntRMtNfOdTkYzg9ytoDGgi/cnPUy 6OgQ==
Received: by 10.216.123.130 with SMTP id v2mr1327977weh.117.1349991276300; Thu, 11 Oct 2012 14:34:36 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:8495:bad6:30a7:8ed9]) by mx.google.com with ESMTPS id a10sm707398wiz.4.2012.10.11.14.34.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 14:34:35 -0700 (PDT)
Message-ID: <50773B68.10707@jitsi.org>
Date: Thu, 11 Oct 2012 23:34:32 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org>  <5075FAC3.20709@jitsi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlURLULFA28iRMaB+i/g7Luz+Nb1Ef/aluQmXmdVUmtAW+uA1DG6Z/y6Bwzpu8VBSR2ttbm
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 21:34:38 -0000

Hey Martin,

On 11.10.12, 19:13, Martin Thomson wrote:
> On 10 October 2012 15:46, Emil Ivov  wrote:
>> Yes, the above sentence may indeed be misleadingly read as "respecting
>> the order of the streams is all there is to it". What was really meant
>> was something along the lines of: "respecting the order of streams
>> improves the chances of the connectivity checks being run simultaneously
>> for a particular stream/component"
>>
>>> A naive implementation would use the set of known candidates on each
>>> component to make this determination.  However, that set is
>>> potentially different to the set of candidates known to their peer.
>>> That could cause a mismatch if both peers "unfreeze the first
>>> non-empty checklist."
>>
>> Correct, but this is not going to be a problem. When the corresponding
>> candidates eventually find their way to the agent, it would unfreeze
>> their local counter-parts and, if necessary, rerun any in-progress or
>> failed checks. This is explained in Section 9:
>>
>>    [snip] the agent examines the check
>>    list looking for another pair that would be redundant with the new
>>    one.  If such a pair exists and its state is:
>>
>>    Failed:   the agent chooses the pair with the higher priority local
>>       candidate, places it in the Waiting state and removes the other
>>       one as redundant.
>>    In-Progress:   The agent cancels the in-progress transaction (where
>>       cancellation happens as explained in Section 7.2.1.4 of
>>       [RFC5245]), then it chooses the pair with the higher priority
>>       local candidate, places it in the Waiting state and removes the
>>       other one as redundant.
>>
>> Does this sound reasonable or were you referring to something else?
> 
> Actually, this part in Section 9 wasn't very clear. 

Sorry about that. We'll try to add clarifications before the 01 deadline.

> I think that the
> terms aren't quite right.  "Redundant" and "priority" have specific
> meanings in ICE that I think aren't quite right for using here.

Yes they do, and those same meanings apply here.

> This wasn't immediately clear, though I get where you are going with
> this.  Though I do think that you need to ensure that this
> cancellation doesn't occur to the highest priority"

Why not?

> You aren't talking about priority or redundancy, I think. 

I believe we are.

> You want to
> ensure that you are making checks on the first component (of the first
> media stream). 

No, not really. What we want to ensure is that if a number of checks
fail because pairs are in an asymmetric state, those checks will be
retried later.

Imagine the following case (described by Eric in his original mail to
RTCWEB):

* Alice calls Bob with a list containing server reflexive candidates.
* Bob responds with host candidates only.
* Bob then starts checks but the pairs containing Alice's server
reflexive address won't be succeeding because Alice is not doing checks
to open up the filtering on the NAT.
* Bob then gets SR addresses and sends them to Alice so she also starts
conn checks.
* With the rules in Secion 9, Bob also places the pairs that failed just
above into the Waiting state, so this time checks are simultaneous and
they succeed.

> What you want is probably more like:
> 
> The agent examines the check list 

When is this happening? When learning new local candidates? Remote? In
the beginning of ICE processing? At some other point?

> and looks for a pair with the same
> foundation.  Where multiple such pairs exist, the one from the
> component that is first in order is selected.  If an existing pair is
> selected, based on its state, the following actions are taken:
> 
>  Failed:  The agent marks the new pair as Failed.  [[?: not sure that
> this is entirely safe, might need to re-open this one to prevent a
> race condition...]]
>  In-Progress: If the new pair is for a component [[i.e. media stream +
> component]] after the existing pair, the new pair is Frozen.  If the
> new pair is for a component that comes before the existing pair's
> component the existing pair becomes Frozen, the outstanding
> transaction on the existing pair is cancelled, and the new pair is
> placed in the Waiting state.
>   Waiting: If the new pair is for a component [[i.e. media stream +
> component]] after the existing pair, the new pair is Frozen.  If the
> new pair is for a component that comes before the existing pair's
> component the existing pair becomes Frozen and the new pair is placed
> in the Waiting state.
>  etc...
> 
> Does *that* make sense?

Not entirely ;)

Could you please describe a scenario that you think would file with the
text currently in the draft, and that would succeed with the above?

>> Mmm ... it might be my lack of IETF experience, but aren't references
>> supposed to happen the other way around? That is, if RTCWEB decides to
>> use Trickle ICE, then shouldn't RTCWEB documents be referring to this
>> spec and making whatever normative declarations they find appropriate?
> 
> Yes, but the draft makes the claim about a WebRTC app that is
> contacting peers in the same domain.  This makes a big assumption:
> namely, that ALL the other entities in that domain implement trickle
> ICE.  I infer from this that you are assuming that rtcweb is going to
> make this MUST implement, so that you can at least expect all browsers
> to implement trickle ICE.  That is if you are assuming that the same
> domain is only using browsers.

Oh right. We'll make sure the assumption is stated.

>> Besides, trickle ICE is already in use by XMPP apps and SIP will
>> probably follow. Why would the RTCWEB usage be referred to and not the
>> others?
> 
> SIP may well follow, but that doesn't mean that you can make any
> assumptions about support.
> 
>>> In particular, this relates to the decision to require
>>> signaling of support for trickle ICE outside of SDP (a decision that I
>>> need to think about a little more).
>>
>> Well the idea is that it doesn't really need to be signalling. The
>> example that we give is about a WebRTC app with no cross domain support.
>> In this case the WebRTC app can just enable trickle ICE without checking
>> anything since the remote agent is bound to have it too. Again, it's
>> just an example. We are not saying this is how it's going to be done for
>> RTCWEB.
> 
> You can't send an offer sans candidates and expect it to work. 

Indeed not. I would expect it to fail for non-trickle agents (without
alerting the remote user) which would then be my cue to fallback to
vanilla ICE.

> Note: we probably also need to note that a transaction can succeed for
> a Frozen candidate pair (due to the fact that you can't take a STUN
> packet back, so "cancelling" a transaction might still result in a
> successful Binding response.  I don't know what you would do with
> this, but I'd just move the pair to Succeeded.

The case where a cancelled transaction ends up succeeding is indeed
worth covering, but given how the concept is defined in 5245 then maybe
at least part of the coverage should go in 5245bis?


Cheers,
Emil

> That's
> part of the reason you are writing this draft, as I understand.
> Unless you know for certain that the other side implements it.  I
> don't think that this is realistic.  Therefore, signaling.
> 
>> Does this make sense?
> 
> Not entirely ;)
> 

From emil@sip-communicator.org  Thu Oct 11 14:34:49 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4118A1F0C4A for ; Thu, 11 Oct 2012 14:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6+cI1Qa5-he for ; Thu, 11 Oct 2012 14:34:48 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D426A1F041F for ; Thu, 11 Oct 2012 14:34:45 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so2359788wib.13 for ; Thu, 11 Oct 2012 14:34:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=BmB02Cgvz6vCPYXAtrUGyV91gqTFPLSMms2/PN86gkE=; b=hud16YRzZxV5dL6yitceRij7ixKvrNsecFNNXD6vOiFcYhcpAfxwP2rPlCy5lj5Xh6 fViP/X1c17mU+YznZQPU4qCOJe8kVH7qv6j9+7UWB88LBa7lPd/XRgNe5Mvi19n4sQEK QNRgF7Q99isZakjccnMOFv8NsCbsIgfgCsg3xFyy8D4NWepI4GMPNC/1gAYAQbzKb7ec a2dqZoK2dPYei/8FcjeuacA2eaND0sHlBxvS4QVo9ScPl+vdSzMDiV5hFSdS8a50yUWR zbLAYAFSjtcVykf/tA0++qv4+59TwAW5mDfjTzkdLgFub/5x+Q2ZSKy8A/GZ70ome8HZ MgRg==
Received: by 10.181.13.239 with SMTP id fb15mr834853wid.22.1349991284934; Thu, 11 Oct 2012 14:34:44 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:8495:bad6:30a7:8ed9]) by mx.google.com with ESMTPS id p4sm723347wix.0.2012.10.11.14.34.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 14:34:44 -0700 (PDT)
Message-ID: <50773B73.6060508@jitsi.org>
Date: Thu, 11 Oct 2012 23:34:43 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnB1GGeb9YyMrzFwthGhzdvxnAI6gQomXRAIcW5WXo8s1upHRsxEybUW5YcWpquVwbEsiOi
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 21:34:49 -0000

Hey Christer,

On 11.10.12, 21:23, Christer Holmberg wrote:
> 
> Hi,
> 
> Q1: Remote endpoint support (SIP): 
> ----------------------------------
> 
>>>>> You say that, before the first offer is sent, one SHOULD
>>>>> determine whether the remote endpoint supports trickle ICE.
>>>>> 
>>>>> For SIP, you give RFC 3840 as an example. I am not sure how
>>>>> that will work. Yes, you can use 3840 to request that the
>>>>> offer is sent to an entity which supports trickle ICE (for
>>>>> that, btw, you will also need to define an option tag, or
>>>>> something similar),
>>>> 
>>>> Right, but we were hoping this would happen in a separate spec
>>>> that details use of trickle ICE with SIP.
>>>> 
>>>>> but you cannot use it to determine whether the remote
>>>>> endpoint supports trickle ICE. In addition, you typically use
>>>>> 3840 at the same time when you send the initial offer.
>>>>> 
>>>>> Of course, you could use SIP OPTIONS.
>>>> 
>>>> Yes, that was the idea. The way 3840 describes it in Section
>>>> 8.
>>>> 
>>>>> But, there are a number of issues related to that, and I
>>>>> don't think we want to define a mechanism which relies on the
>>>>> usage of OPTIONS.
>>>>> 
>>>>> And, if we simply say that it's "outside the scope of the
>>>>> document",
>>>> 
>>>> I was just about to say that ;).
>>>> 
>>>> But, seriously, determining and negotiating caps happens very 
>>>> differently in different signalling protocols, so it doesn't
>>>> seem reasonable to try and find answers for all of them in the
>>>> generic trickle ICE spec.
>>>> 
>>>> XMPP for example, has this part covered pretty well. If we
>>>> determine that 3840 does not provide a way of doing the same
>>>> then we can find another way for SIP.
>>>> 
>>>> Eric had this idea, where a trickle ICE agent would simply fire
>>>> a first offer that only other trickle ICE agents would accept
>>>> and that any other SIP endpoint would answer with an error.
>>>> This would be enough of a check and if it fails the caller can
>>>> fall back to vanilla ICE.
>>> 
>>> Sure, but that is not checking for trickle support before sending
>>> the trickle offer :)
>> 
>> Yes, the wording may need to be reviewed if we go for this.
>> 
>>> Also, I guess I still haven't completely understood the backward
>>> compatibility issue, but I guess I need to do some more reading.
>> 
>> We describe these in Section 3 but the main problem is that a
>> vanilla ICE agent that gets a first subset of candidates (that may
>> also be empty) would declare failure prematurely.
> 
> The text gives an example where the receiver (Bob) receives a
> host-candidate-only offer, and start checks which fail.
> 
> I think it's quite strange if Bob would reject the call at that
> point. Because, no matter how many candidates the offer contains,
> there might still be peer reflexive candidates created later,

How does Bob know that there's going to be a "later" ? It's just a
vanilla ICE agent that assumed it received a full set of candidates, it
checked them all, all checks failed.

Now, we could rely on Bob not doing anything rash and waiting patiently
for reINVITEs from Alice in order to get more candidates ... but that
might be about as risky as relying on empty INVITEs to be handled
properly by everyone or on OPTIONS to be transmitted end-to-end.

Besides there are other possible failures, like for example the case
where I get your server reflexive candidates long before you get mine so
we perform checks out of sync (the case that I also described in my
other mail to Martin).

> once
> the offerer (Alice) starts sending the STUN binding requests. So, one
> would think that Bob at least would wait for those.
> 
>>>> Another option would be for trickle ICE agents to send empty
>>>> INVITEs that somehow indicate they will be trickling but
>>>> contain no actual offer. The offer that the remote side then
>>>> adds in an OK response (or a provisional one) would clearly
>>>> indicate whether they support vanilla, trickle, or no ICE at
>>>> all, so the trickle agent would be able to answer accordingly
>>>> with the ACK.
>>> 
>>> I don't think we want to rely on empty INVITEs either, because
>>> there are a number of issues related to that.
>> 
>> Well, it might be worth investigating exactly what they are. The
>> same applies to using OPTIONS and 3840.
> 
> Well, to start with, empty INVITEs will work very badly with legacy.

You mean, because legacy devices don't properly implement 3261 in that
regard?

That might actually be a good thing. An error response at this point
would be a good indication that there's no trickle ICE support at the
remote side.

> In addition, there migth be other functions which do not work with
> empty INVITEs.

OK, I agree. It's a clumsy solution at best. It would be impossible for
SIP user agents to translate a user request to start an audio,
audio/video or some other media session (which is the typical rant you
get for handling empty INVITEs). It was just a thought :)

> And, I am not sure how it would work with JSEP.

You mean, in cases of gatewaying SIP to WebRTC? I suppose it could just
be translated to some custom signalling that actually does capability
negotiation and then triggers a remote INVITE ... OK I know, it's a stretch.
> 
> 
>>>>>> we could do the same for BUNDLE, and we wouldn't have
>>>>>> issues with re-using the same ports in multiple m- lines
>>>>>> etc :)
>>>>> 
>>>>> Well, we are not saying that they should not be addressed at
>>>>> all, or even now. Just that maybe they shouldn't be addressed
>>>>> by this specific document.
>>>> 
>>>> Perhaps we shouldn't say anything about finding out in advance,
>>>> then. At least not use SHOULD.
>>>> 
>>>> We CAN describe what may happen if the remote peer does not
>>>> support trickle ICE, but leave it to that.
>>> 
>>> What we'd like to avoid is having trickle ICE offers to vanilla
>>> ICE agents and then having them fail in a user-perceptible way.
>>> 
>> Maybe we could modify the "SHOULD verify support" to "SHOULD verify
>> support or provide a mechanism for transparent fallback to vanilla
>> ICE"
> 
> In my opinion, if one has to do something extra (e.g. send OPTIONS),
> the whole idea of trickle-ICE goes away, because at the end of the
> day you won't save any time in call establishment.

The OPTIONS request does not need to be sent right before the call. It
can be done once, upon bootstrap.

> Now, if the browser is communicating with a ICE terminating gateway,
> and if the browser performs SIP registration, then the gateway can
> indicate trickle-ICE during registration.
> 
> But, in the peer-to-peer case I don't know how it would work. It's
> not even sure OPTIONS would reach the same remote peer as the
> INVITE...

I agree. Not sure what to say other than, I agree that SIP does not have
good mechanisms for XMPP like negotiation of entity caps but,
personally, I do believe that finding one would be helpful here.

Maybe we can work on making sure that 3840 (or some other mechanism)
would better allow for caps to be discovered in advance.

At the very least, if we can't find a way to do this gracefully with
SIP, we can RECOMMEND it whenever the protocol allows it and try to
devise a fall back strategy when it does not (e.g. with SIP).

> Q2: Offer/Answer Alignment: ---------------------------
> 
>>>>> I assume the offers and answer are sent according to the
>>>>> rules in RFC 3264.
>>>>> 
>>>>> If so, when you talk about offers and/or answers "being sent
>>>>> at any point", I think it needs to be clear that it's within
>>>>> the rules of 3264.
>>>> 
>>>> Good point! I think the text is indeed a bit unclear in that
>>>> regard and we might be making some non-stated assumptions about
>>>> the relation between 3264 Offer/Answer, the actual call
>>>> answering, and the connectivity checks phase. We'll fix this.
>>> 
>>> Thanx! :)
> 
> 
> Q3: Enough is enough: ---------------------
> 
>>>>> I think it could be useful for the answerer to tell the
>>>>> offerer that it doesn't want/need any more candidates.
>>>> 
>>>> Yes, sounds useful. Do you have any specific use cases in
>>>> mind?
>>> 
>>> Well, I guess any case where the remote peer knows it has a
>>> public IP address (it will most likely be an ICE lite entity).
>> 
>> Right, but in such cases the offerer would also know that a certain
>> pair has succeeded so if they continue it might be with the purpose
>> of finding a better RTT or a higher priority local candidate.
>> 
>> I guess what I am trying to say is that a Binding Response is
>> enough of an indication that trickling can stop. If it doesn't then
>> maybe it's for a reason.
> 
> Maybe it is enough... In any case I think it would be good to
> document :)

OK. Agreed.

> Also, at least in cases where the remote peer only provide a host
> candidate (because it has a public IP address), one should be smart
> enough to figure out that there most likely will be no better
> alternative.

I am not sure I got this.

Cheers,
Emil
> 
> 
> Regards,
> 
> Christer
> 
> 

From emil@sip-communicator.org  Thu Oct 11 14:36:02 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE31F041F for ; Thu, 11 Oct 2012 14:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkLmmRE-OUeV for ; Thu, 11 Oct 2012 14:36:01 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2A51F0C3E for ; Thu, 11 Oct 2012 14:35:54 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hm2so83056wib.1 for ; Thu, 11 Oct 2012 14:35:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=GCy2bVPhUNUAcUWEuaJaMereSOSa5YmDy5KGHRLBejg=; b=XuqfLOMIhdSPM0+6qRLklLyWqQem3xl2VvJtinJXvSwZqLgaCCvCw+XgIsvXEtYfo6 Fiyy2nhUQE9zklD7oowbbcdWD4+4sFz+9Z2Dow/5mj7Tsuu6v1YMGv2sQ9yYTPKglakb DIv3GUP8U169K09kAr3/i+lAjMrJYNaxP7YY9drxiZuFe/x1ST99AHnm4VSxUL8E7VxU V/nKkqgBSRr0TOmNlrKd2HJEvu8HUXgw65egbFsE6x5QLEIbh9H+ROXEPH65tOM7kkGT YMqDLG9KaNPbxeDkXbk776Nrt/ANkU+3pbGu9hnR/HzH23W3eFJoAgzLmfuNoOmvFrtu HZPQ==
Received: by 10.180.84.202 with SMTP id b10mr890299wiz.13.1349991353323; Thu, 11 Oct 2012 14:35:53 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:8495:bad6:30a7:8ed9]) by mx.google.com with ESMTPS id dt9sm645970wib.1.2012.10.11.14.35.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 14:35:52 -0700 (PDT)
Message-ID: <50773BB7.1000608@jitsi.org>
Date: Thu, 11 Oct 2012 23:35:51 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Olle E. Johansson" 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <39EF1F75-DE97-4175-89A5-6A26278883A5@edvina.net>
In-Reply-To: <39EF1F75-DE97-4175-89A5-6A26278883A5@edvina.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmr1NE1kVD4p4Qi0FK2M0JZyiH2NavWMrHH9GcJNNlIMeVsq+ec3PX/x/b9zyr1fILQ/atH
Cc: MMUSIC IETF WG , Christer Holmberg 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Oct 2012 21:36:02 -0000

Hey Olle,

On 11.10.12, 22:00, Olle E. Johansson wrote:
> 
> 11 okt 2012 kl. 11:53 skrev Christer Holmberg :
> 
>> Hi,
>>
>> Q1: Remote endpoint support (SIP):
>> --------------------------------------------
>>
>>>> You say that, before the first offer is sent, one SHOULD determine
>>>> whether the remote endpoint supports trickle ICE.
>>>>
>>>> For SIP, you give RFC 3840 as an example. I am not sure how that will
>>>> work. Yes, you can use 3840 to request that the offer is sent to an
>>>> entity which supports trickle ICE (for that, btw, you will also need
>>>> to define an option tag, or something similar),
>>>
>>> Right, but we were hoping this would happen in a separate spec that
>>> details use of trickle ICE with SIP.
> 
> I think that we should start that work in parallell. Doing trickle ICE with SIP O/A
> can be trick(l)y and the solution for that may affect the Trickly ICE core.

Agreed.

Emil

> I do think trickle ICE will help SIP quite a lot, especially in a b2bua situation.
> 
> /O
> 
>>>
>>>> but you cannot use it
>>>> to determine whether the remote endpoint supports trickle ICE. In
>>>> addition, you typically use 3840 at the same time when you send the
>>>> initial offer.
>>>>
>>>> Of course, you could use SIP OPTIONS.
>>>
>>> Yes, that was the idea. The way 3840 describes it in Section 8.
>>>
>>>> But, there are a number of issues related to that,
>>>> and I don't think we want to define a
>>>> mechanism which relies on the usage of OPTIONS.
>>>>
>>>> And, if we simply say that it's "outside the scope of the document",
>>>
>>> I was just about to say that ;).
>>>
>>> But, seriously, determining and negotiating caps happens very
>>> differently in different signalling protocols, so it doesn't seem
>>> reasonable to try and find answers for all of them in the generic
>>> trickle ICE spec.
>>>
>>> XMPP for example, has this part covered pretty well. If we determine
>>> that 3840 does not provide a way of doing the same then we can find
>>> another way for SIP.
>>>
>>> Eric had this idea, where a trickle ICE agent would simply fire a first
>>> offer that only other trickle ICE agents would accept and that any other
>>> SIP endpoint would answer with an error. This would be enough of a check
>>> and if it fails the caller can fall back to vanilla ICE.
>>
>> Sure, but that is not checking for trickle support before sending the trickle offer :)
>>
>> Also, I guess I still haven't completely understood the backward compatibility issue, but I guess I need to do some more reading.
>>
>>> Another option would be for trickle ICE agents to send empty INVITEs
>>> that somehow indicate they will be trickling but contain no actual
>>> offer. The offer that the remote side then adds in an OK response (or a
>>> provisional one) would clearly indicate whether they support vanilla,
>>> trickle, or no ICE at all, so the trickle agent would be able to answer
>>> accordingly with the ACK.
>>
>> I don't think we want to rely on empty INVITEs either, because there are a number of issues related to that.
>>
>>>> we could do the same for BUNDLE, and we wouldn't have issues with
>>>> re-using the same ports in multiple m- lines etc :)
>>>
>>> Well, we are not saying that they should not be addressed at all, or
>>> even now. Just that maybe they shouldn't be addressed by this specific
>>> document.
>>
>> Perhaps we shouldn't say anything about finding out in advance, then. At least not use SHOULD. 
>>
>> We CAN describe what may happen if the remote peer does not support trickle ICE, but leave it to that.
>>
>>
>> Q2: Offer/Answer Alignment: 
>> ------------------------------------
>>
>>>> I assume the offers and answer are sent according to the rules in RFC
>>>> 3264.
>>>>
>>>> If so, when you talk about offers and/or answers "being sent at any
>>>> point", I think it needs to be clear that it's within the rules of
>>>> 3264.
>>>
>>> Good point! I think the text is indeed a bit unclear in that regard and
>>> we might be making some non-stated assumptions about the relation
>>> between 3264 Offer/Answer, the actual call answering, and the
>>> connectivity checks phase. We'll fix this.
>>
>> Thanx! :)
>>
>>
>> Q3: Enough is enough: 
>> ----------------------------
>>
>>>> I think it could be useful for the answerer to tell the offerer that
>>>> it doesn't want/need any more candidates.
>>>
>>> Yes, sounds useful. Do you have any specific use cases in mind?
>>
>> Well, I guess any case where the remote peer knows it has a public IP address (it will most likely be an ICE lite entity).
>>
>>> I am also wondering what would happen if the answerer says "enough" too
>>> early in the process and causes negotiation to fail. Is there a reason
>>> why an agent would be willing to risk that? Or are we going to say that
>>> it would only do that after finding at least one valid pair for every
>>> component?
>>
>> Well, the indication could mean please-try-whether-the-candidate-works-before-you-send-me-additional-ones :)
>>
>> Regards,
>>
>> Christer
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31

From lishitao@huawei.com  Thu Oct 11 19:43:44 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A48611E808D for ; Thu, 11 Oct 2012 19:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.261
X-Spam-Level: 
X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=0.338,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sfx3yVxyACAR for ; Thu, 11 Oct 2012 19:43:43 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D98421F84A7 for ; Thu, 11 Oct 2012 19:43:42 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKN37803; Fri, 12 Oct 2012 02:43:41 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 12 Oct 2012 03:43:04 +0100
Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 12 Oct 2012 03:43:24 +0100
Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.56]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 12 Oct 2012 10:43:16 +0800
From: Lishitao 
To: Emil Ivov , Christer Holmberg 
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: AQHNpvO2fKOXlR6+7kycNVqmYvnvwZeyU1+AgABLNgCAALnaAIAAKF0AgAB27ACAACS4gIAA2bqQ
Date: Fri, 12 Oct 2012 02:43:15 +0000
Message-ID: 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org>
In-Reply-To: <50773B73.6060508@jitsi.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.73.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 02:43:44 -0000

Hi Emil

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Emil Ivov
> Sent: Friday, October 12, 2012 5:35 AM
> To: Christer Holmberg
> Cc: MMUSIC IETF WG
> Subject: Re: [MMUSIC] Trickle ICE
>=20
> Hey Christer,
>=20
> On 11.10.12, 21:23, Christer Holmberg wrote:
> >
> > Hi,
> >
> > Q1: Remote endpoint support (SIP):
> > ----------------------------------
> >
> >>>>> You say that, before the first offer is sent, one SHOULD
> >>>>> determine whether the remote endpoint supports trickle ICE.
> >>>>>
> >>>>> For SIP, you give RFC 3840 as an example. I am not sure how
> >>>>> that will work. Yes, you can use 3840 to request that the
> >>>>> offer is sent to an entity which supports trickle ICE (for
> >>>>> that, btw, you will also need to define an option tag, or
> >>>>> something similar),
> >>>>
> >>>> Right, but we were hoping this would happen in a separate spec
> >>>> that details use of trickle ICE with SIP.
> >>>>
> >>>>> but you cannot use it to determine whether the remote
> >>>>> endpoint supports trickle ICE. In addition, you typically use
> >>>>> 3840 at the same time when you send the initial offer.
> >>>>>
> >>>>> Of course, you could use SIP OPTIONS.
> >>>>
> >>>> Yes, that was the idea. The way 3840 describes it in Section
> >>>> 8.
> >>>>
> >>>>> But, there are a number of issues related to that, and I
> >>>>> don't think we want to define a mechanism which relies on the
> >>>>> usage of OPTIONS.
> >>>>>
> >>>>> And, if we simply say that it's "outside the scope of the
> >>>>> document",
> >>>>
> >>>> I was just about to say that ;).
> >>>>
> >>>> But, seriously, determining and negotiating caps happens very
> >>>> differently in different signalling protocols, so it doesn't
> >>>> seem reasonable to try and find answers for all of them in the
> >>>> generic trickle ICE spec.
> >>>>
> >>>> XMPP for example, has this part covered pretty well. If we
> >>>> determine that 3840 does not provide a way of doing the same
> >>>> then we can find another way for SIP.
> >>>>
> >>>> Eric had this idea, where a trickle ICE agent would simply fire
> >>>> a first offer that only other trickle ICE agents would accept
> >>>> and that any other SIP endpoint would answer with an error.
> >>>> This would be enough of a check and if it fails the caller can
> >>>> fall back to vanilla ICE.
> >>>
> >>> Sure, but that is not checking for trickle support before sending
> >>> the trickle offer :)
> >>
> >> Yes, the wording may need to be reviewed if we go for this.
> >>
> >>> Also, I guess I still haven't completely understood the backward
> >>> compatibility issue, but I guess I need to do some more reading.
> >>
> >> We describe these in Section 3 but the main problem is that a
> >> vanilla ICE agent that gets a first subset of candidates (that may
> >> also be empty) would declare failure prematurely.
> >
> > The text gives an example where the receiver (Bob) receives a
> > host-candidate-only offer, and start checks which fail.
> >
> > I think it's quite strange if Bob would reject the call at that
> > point. Because, no matter how many candidates the offer contains,
> > there might still be peer reflexive candidates created later,
>=20
> How does Bob know that there's going to be a "later" ? It's just a
> vanilla ICE agent that assumed it received a full set of candidates, it
> checked them all, all checks failed.
>=20
> Now, we could rely on Bob not doing anything rash and waiting patiently
> for reINVITEs from Alice in order to get more candidates ... but that
> might be about as risky as relying on empty INVITEs to be handled
> properly by everyone or on OPTIONS to be transmitted end-to-end.
>=20
> Besides there are other possible failures, like for example the case
> where I get your server reflexive candidates long before you get mine so
> we perform checks out of sync (the case that I also described in my
> other mail to Martin).
>=20
> > once
> > the offerer (Alice) starts sending the STUN binding requests. So, one
> > would think that Bob at least would wait for those.
> >
> >>>> Another option would be for trickle ICE agents to send empty
> >>>> INVITEs that somehow indicate they will be trickling but
> >>>> contain no actual offer. The offer that the remote side then
> >>>> adds in an OK response (or a provisional one) would clearly
> >>>> indicate whether they support vanilla, trickle, or no ICE at
> >>>> all, so the trickle agent would be able to answer accordingly
> >>>> with the ACK.
> >>>
> >>> I don't think we want to rely on empty INVITEs either, because
> >>> there are a number of issues related to that.
> >>
> >> Well, it might be worth investigating exactly what they are. The
> >> same applies to using OPTIONS and 3840.
> >
> > Well, to start with, empty INVITEs will work very badly with legacy.
>=20
> You mean, because legacy devices don't properly implement 3261 in that
> regard?
>=20
> That might actually be a good thing. An error response at this point
> would be a good indication that there's no trickle ICE support at the
> remote side.

In this way , as christer described, it won't save any time in call establi=
shment.=20

> > In addition, there migth be other functions which do not work with
> > empty INVITEs.
>=20
> OK, I agree. It's a clumsy solution at best. It would be impossible for
> SIP user agents to translate a user request to start an audio,
> audio/video or some other media session (which is the typical rant you
> get for handling empty INVITEs). It was just a thought :)
>=20
> > And, I am not sure how it would work with JSEP.
>=20
> You mean, in cases of gatewaying SIP to WebRTC? I suppose it could just
> be translated to some custom signalling that actually does capability
> negotiation and then triggers a remote INVITE ... OK I know, it's a stret=
ch.
> >
> >
> >>>>>> we could do the same for BUNDLE, and we wouldn't have
> >>>>>> issues with re-using the same ports in multiple m- lines
> >>>>>> etc :)
> >>>>>
> >>>>> Well, we are not saying that they should not be addressed at
> >>>>> all, or even now. Just that maybe they shouldn't be addressed
> >>>>> by this specific document.
> >>>>
> >>>> Perhaps we shouldn't say anything about finding out in advance,
> >>>> then. At least not use SHOULD.
> >>>>
> >>>> We CAN describe what may happen if the remote peer does not
> >>>> support trickle ICE, but leave it to that.
> >>>
> >>> What we'd like to avoid is having trickle ICE offers to vanilla
> >>> ICE agents and then having them fail in a user-perceptible way.
> >>>
> >> Maybe we could modify the "SHOULD verify support" to "SHOULD verify
> >> support or provide a mechanism for transparent fallback to vanilla
> >> ICE"
> >
> > In my opinion, if one has to do something extra (e.g. send OPTIONS),
> > the whole idea of trickle-ICE goes away, because at the end of the
> > day you won't save any time in call establishment.
>=20
> The OPTIONS request does not need to be sent right before the call. It
> can be done once, upon bootstrap.

If the callee has already in your contact list, of course you can do that, =
but if you=20
call a strange number at the first time, the OPTION request should be sent =
right=20
before the call.


/Shitao

> > Now, if the browser is communicating with a ICE terminating gateway,
> > and if the browser performs SIP registration, then the gateway can
> > indicate trickle-ICE during registration.
> >
> > But, in the peer-to-peer case I don't know how it would work. It's
> > not even sure OPTIONS would reach the same remote peer as the
> > INVITE...
>=20
> I agree. Not sure what to say other than, I agree that SIP does not have
> good mechanisms for XMPP like negotiation of entity caps but,
> personally, I do believe that finding one would be helpful here.
>=20
> Maybe we can work on making sure that 3840 (or some other mechanism)
> would better allow for caps to be discovered in advance.
>=20
> At the very least, if we can't find a way to do this gracefully with
> SIP, we can RECOMMEND it whenever the protocol allows it and try to
> devise a fall back strategy when it does not (e.g. with SIP).
>=20
> > Q2: Offer/Answer Alignment: ---------------------------
> >
> >>>>> I assume the offers and answer are sent according to the
> >>>>> rules in RFC 3264.
> >>>>>
> >>>>> If so, when you talk about offers and/or answers "being sent
> >>>>> at any point", I think it needs to be clear that it's within
> >>>>> the rules of 3264.
> >>>>
> >>>> Good point! I think the text is indeed a bit unclear in that
> >>>> regard and we might be making some non-stated assumptions about
> >>>> the relation between 3264 Offer/Answer, the actual call
> >>>> answering, and the connectivity checks phase. We'll fix this.
> >>>
> >>> Thanx! :)
> >
> >
> > Q3: Enough is enough: ---------------------
> >
> >>>>> I think it could be useful for the answerer to tell the
> >>>>> offerer that it doesn't want/need any more candidates.
> >>>>
> >>>> Yes, sounds useful. Do you have any specific use cases in
> >>>> mind?
> >>>
> >>> Well, I guess any case where the remote peer knows it has a
> >>> public IP address (it will most likely be an ICE lite entity).
> >>
> >> Right, but in such cases the offerer would also know that a certain
> >> pair has succeeded so if they continue it might be with the purpose
> >> of finding a better RTT or a higher priority local candidate.
> >>
> >> I guess what I am trying to say is that a Binding Response is
> >> enough of an indication that trickling can stop. If it doesn't then
> >> maybe it's for a reason.
> >
> > Maybe it is enough... In any case I think it would be good to
> > document :)
>=20
> OK. Agreed.
>=20
> > Also, at least in cases where the remote peer only provide a host
> > candidate (because it has a public IP address), one should be smart
> > enough to figure out that there most likely will be no better
> > alternative.
>=20
> I am not sure I got this.
>=20
> Cheers,
> Emil
> >
> >
> > Regards,
> >
> > Christer
> >
> >
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From juberti@google.com  Thu Oct 11 23:08:54 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5472621F847C for ; Thu, 11 Oct 2012 23:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.143
X-Spam-Level: 
X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufNKjAMiOgY0 for ; Thu, 11 Oct 2012 23:08:53 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A43C821F8468 for ; Thu, 11 Oct 2012 23:08:53 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so2311864qcg.31 for ; Thu, 11 Oct 2012 23:08:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=YgZvngF5j8KE8LV6QusNqL0oS2JiKf+p8sYomKjxlnc=; b=hXcdetq3aNPWUqMI+JpXtgTbDzUrLl3yf6NcFhzgXSQr2INYdSDpGKg6bKrkLRJ+SF UwWA264yPODnpFoYdK+LtafpAe5Hf1pp81qDSElUzh4ZVGyacKLgaIL7hlIRkLuwAw41 n+RY62NuR9POxBaWJPe30eLdWFPrN/l5p3yULHu+OmW1M6PQVBNIVO0rzHxTbg3utgHs f1/HZ4MtYP//G5lJnpgMQKPCeZ2OWK26jkXYBn79n7W6BdZDPtkSaVqXkYBReUje48Cr NfSBv513W9vRlDU174/xMDjoBKuWesNeqlGFiujCX0Axowz+V6+FnY08s5jzDJWUEM0K SttA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=YgZvngF5j8KE8LV6QusNqL0oS2JiKf+p8sYomKjxlnc=; b=akWICYQi+IjN1CNFkQdB8jexm5AtX+/gnv9CFauqojJ6HTArC3nHsuakFfmjDH+V2J 9JyNVJr201DzD1k13pk7BHEXRtJqded0jC+EPRcUTeq1A8rXXsmZbxXlJ0mvBH+1dW/y 1UgxQf4p5GxgqA+uoSILKZHUDfGu749TjnKJZeLaVKVEgslmoSJGDns9vJDAdKiVVVF0 5CZjNIxnt06jU4u+qs4/zI9V1LcH3xrxsg70tBTbPZPYI0LQVg6bT7rH3Gisbofz5zoy lHsu+1vqxnt48fj+NQgeS1PEvvStpodTb38vCq94QKiuNYTJNSbkI9ibhsYrEyYxgq/l YJkQ==
Received: by 10.49.48.43 with SMTP id i11mr2285433qen.10.1350022133006; Thu, 11 Oct 2012 23:08:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.216.194 with HTTP; Thu, 11 Oct 2012 23:08:31 -0700 (PDT)
In-Reply-To: <50742574.6080200@ericsson.com>
References: <50742574.6080200@ericsson.com>
From: Justin Uberti 
Date: Thu, 11 Oct 2012 23:08:31 -0700
Message-ID: 
To: "Miguel A. Garcia" 
Content-Type: multipart/alternative; boundary=047d7b6d89c2ad40df04cbd6850b
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQn1hTEsf68cBWVKcdsh+qsw4DIFnl4y5KyJacJZmSOStqTDyOaJ9yZOX2tCN+txhwgBdTJ2sHglecUUb5cSx5cQ9zk3ZwopSz3OtnnES8qRjk/9LEAzYaFKKj02cS6/DMxHGCBPFRGjsJ+d+g5Z07SB3RI1WlCUm4U8PxSsjW2B5BskTT1RG5W6fpHF/2xM6ATUyYN4
Cc: Flemming Andreasen , mmusic 
Subject: Re: [MMUSIC] WG poll for consensus MSID draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 06:08:54 -0000

--047d7b6d89c2ad40df04cbd6850b
Content-Type: text/plain; charset=UTF-8

Frequent MMUSIC reader, occasional MMUSIC contributor.

MSID defines a way to associate capture sources (e.g. WebRTC
MediaStreamTracks) with RTP SSRCs, providing the glue needed to send
multiple simultaneous captures across a RTP session in an interoperable
way.

This functionality is critical to WebRTC, and I would like to see this
draft move forward.

--justin


On Tue, Oct 9, 2012 at 6:24 AM, Miguel A. Garcia <
Miguel.A.Garcia@ericsson.com> wrote:

> At the last IETF meeting we had a presentation of the following draft:
>
> http://datatracker.ietf.org/**doc/draft-alvestrand-mmusic-**msid/
>
> At that time, there was interest in solving the problem of cross session
> stream identification.
>
> We would like to poll the working group for consensus on adopting the
> above mentioned draft as a working group item, once we get an approved
> milestone.
>
> If you support this work or have problems with the adoption of this
> document as WG item, please indicate it by replying to this e-mail within
> the next 5 days.
>
> Flemming and Miguel (co-chairs)
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> ______________________________**_________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/**listinfo/mmusic
>

--047d7b6d89c2ad40df04cbd6850b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Frequent MMUSIC reader, occasional MMUSIC contributor.

M=
SID defines a way to associate capture sources (e.g. WebRTC MediaStreamTrac=
ks) with RTP SSRCs, providing the glue needed to send multiple simultaneous=
 captures across a RTP session in an interoperable way.=C2=A0




This functionality is critical to WebRTC, and I would l=
ike to see this draft move forward.

--justin
=



On Tue, Oct 9=
, 2012 at 6:24 AM, Miguel A. Garcia <Miguel.A.Garcia@ericsson.c=
om> wrote:



At the last IETF meeting we had a presentati=
on of the following draft:



http://datatracker.ietf.org/doc/draft-alvestrand-mm=
usic-msid/



At that time, there was interest in solving the problem of cross session st=
ream identification.



We would like to poll the working group for consensus on adopting the above=
 mentioned draft as a working group item, once we get an approved milestone=
.



If you support this work or have problems with the adoption of this documen=
t as WG item, please indicate it by replying to this e-mail within the next=
 5 days.



Flemming and Miguel (co-chairs)



-- 

Miguel A. Garcia

=
+34-91-339-3608

Ericsson Spain

_______________________________________________

mmusic mailing list

mmusic@ietf.org
=
https://www.ietf.org/mailman/listinfo/mmusic





--047d7b6d89c2ad40df04cbd6850b--

From Bert.Greevenbosch@huawei.com  Thu Oct 11 23:20:45 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5ED321F8499 for ; Thu, 11 Oct 2012 23:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level: 
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRxmY95w7CPE for ; Thu, 11 Oct 2012 23:20:45 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34421F8498 for ; Thu, 11 Oct 2012 23:20:44 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKN50251; Fri, 12 Oct 2012 06:20:42 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 12 Oct 2012 07:19:56 +0100
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 12 Oct 2012 07:20:18 +0100
Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Fri, 12 Oct 2012 14:20:09 +0800
From: Bert Greevenbosch 
To: "mmusic@ietf.org" 
Thread-Topic: 3D drafts and their relevancy
Thread-Index: Ac2oQZ/12N4kT72LTemzS7XUlCIKYw==
Date: Fri, 12 Oct 2012 06:20:08 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB6290DBC01@szxeml509-mbs>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.70.110.143]
Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB6290DBC01szxeml509mbs_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [MMUSIC] 3D drafts and their relevancy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 06:20:46 -0000

--_000_46A1DF3F04371240B504290A071B4DB6290DBC01szxeml509mbs_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello all,

During the Vancouver meeting, the 3D drafts were briefly discussed:

http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-parallax/
http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-3d-format/

(I can't find them on the MMUSIC page anymore. Can the link be re-inserted,=
 as they have not been expired yet?)

During the discussion, there were some concerns about the relevancy of the =
drafts, especially with the existence of MVC.

The frame packing formats have been adopted in HDMI 1.4a and DVB 3DTV stand=
ards, both of which are quite recent. Also depth maps are gaining more inte=
rest in the research community, as they provide a nice and concise way to s=
upply additional 3D information along with a 2D video stream.

Moreover, the drafts are not intended as an alternative to MVC. It is just =
about providing signalling for codecs that are already in existence today.

I feel it would be a pity to stop working on 3D in SDP/SIP now. I believe h=
aving SDP signalling would be quite helpful not just for one-directional us=
e cases, but especially also for 3D conversational use cases. The arrival o=
f the first 3D-glasses-free handhelds shows that comfortable 3D conversatio=
n can be achieved in the near future.

I would like to ask the group whether it believes it is beneficial to conti=
nue specification of 3D in SDP/SIP?

Thanks in advance for your opinions!

Best regards,
Bert

--_000_46A1DF3F04371240B504290A071B4DB6290DBC01szxeml509mbs_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello all,


 


During the Vancouver meeting, the 3D drafts were bri=
efly discussed:


 


http://datatracker.ietf.org/doc/draft-greev=
enbosch-mmusic-sdp-parallax/


http://datatracker.ietf.org/doc/draft-gree=
venbosch-mmusic-sdp-3d-format/


 


(I can't find them on the MMUSIC page anymore. Can t=
he link be re-inserted, as they have not been expired yet?)


 


During the discussion, there were some concerns abou=
t the relevancy of the drafts, especially with the existence of MVC.


 


The frame packing formats have been adopted in HDMI =
1.4a and DVB 3DTV standards, both of which are quite recent. Also depth map=
s are gaining more interest in the research community, as they provide a ni=
ce and concise way to supply additional
 3D information along with a 2D video stream.


 


Moreover, the drafts are not intended as an alternat=
ive to MVC. It is just about providing signalling for codecs that are alrea=
dy in existence today.


 


I feel it would be a pity to stop working on 3D in S=
DP/SIP now. I believe having SDP signalling would be quite helpful not just=
 for one-directional use cases, but especially also for 3D conversational u=
se cases. The arrival of the first
 3D-glasses-free handhelds shows that comfortable 3D conversation can be ac=
hieved in the near future.


 


I would like to ask the group whether it believes it=
 is beneficial to continue specification of 3D in SDP/SIP?


 


Thanks in advance for your opinions!


 


Best regards,


Bert






--_000_46A1DF3F04371240B504290A071B4DB6290DBC01szxeml509mbs_--

From juberti@google.com  Thu Oct 11 23:25:57 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C5421F84EC for ; Thu, 11 Oct 2012 23:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.837
X-Spam-Level: 
X-Spam-Status: No, score=-102.837 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ecNp8vGQ12a for ; Thu, 11 Oct 2012 23:25:57 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E78621F84EA for ; Thu, 11 Oct 2012 23:25:56 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so2320550qcg.31 for ; Thu, 11 Oct 2012 23:25:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=DtsxKiQVSEDPYq0B6ZKFhR8Hes5P2WP8cTv+0tmv8Y0=; b=WMNA8COxN78YWp2MNjzDk7iAmVBv5WO0qPw9sg8/4N1+dvXDF/Vuo5sEgrbeUz8RVk 8fiXNyRyZruCy13kjfDbaB8u6Xr9SP0bH0v/bn0BnMFvLDJo0KB2pNKDnPNC2oR8cz+f ODbVz2q9slOS35dnicMhKQT47qwfT20DwQARd5jZgm8kTWKu9QcM/7s+SEtgyJWk8vHV F1JTZZuk2hm0j0lrgeA20l8yTg9wm9VS87GHGHiTWFKhOAOhLRVcumoAjN6wgYeyDcG1 VMgKzFV67H7AFon3pykR3obKmWotBw9q/e0y4WK9F1AkbvnWT8f2tFCvp0u1BRcCl1xg l/lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=DtsxKiQVSEDPYq0B6ZKFhR8Hes5P2WP8cTv+0tmv8Y0=; b=cbc8tXyZ/W0586KyLkvDmHRJylP/kEnp02jir2DpBqBz8vi1u9BckICAcI+zcfmaKS H+x/PrfE2uNnTyPFT6XlhPkUWtgUK2lCipMUIlO4gwuN1zTI5ilrzrI8XiF0UlGXobat oo3JaDBPt2/biZiN5W4HRyYpyZ/ab2P9F5pIa1gFEwaRbx6zyAc7hK9lpllcjCHpqAkT Pqwh2e01gjvbWz+uRNfW8zTny4g8VxVnWPLepU1Htnd5NRyQoLksR9AMPwafglnEADep W4g2fb+Vnnpe9DqRpg/senqK2qssaoh097VHjX2e4L1nFb1XuFBGy0K1awzb5ldU2IWV VJkg==
Received: by 10.224.213.10 with SMTP id gu10mr5884471qab.10.1350023156436; Thu, 11 Oct 2012 23:25:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.216.194 with HTTP; Thu, 11 Oct 2012 23:25:36 -0700 (PDT)
From: Justin Uberti 
Date: Thu, 11 Oct 2012 23:25:36 -0700
Message-ID: 
To: "mmusic@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf300fae13ad8d1204cbd6c2b7
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkQbcoTioy8Ig/MrDKL+m1scJjQ+iL2/Dz+RoEvXzM+0sZboFDgFWQ5DqxUNkdDKxBKUlgbxgtlJBYd7HS490yBFXM96X+IPwMC4LX3Gu2GEDZygWt6r/bA0tEgvgsibL2CK+7EkQgiJ7gYs0FNKCUMZQhWCC2qlZC/DXzJZZc+dMwvPhlYqrM/sSnT403zqk4F9zdv
Subject: [MMUSIC] ICE tiebreaker - session-level or media-level?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 06:25:57 -0000

--20cf300fae13ad8d1204cbd6c2b7
Content-Type: text/plain; charset=UTF-8

Reviewing the handling of role conflicts, a question came up: in the event
different systems handle different media in a session, do they have to
share the same ICE tiebreaker?

Section 5.2 of RFC 5245 indicates that the ICE Agent chooses the
tiebreaker, indicating that this is a session-level value.

 To resolve this, each agent MUST select a random number, called
      the tie-breaker, uniformly distributed between 0 and (2**64) - 1
      (that is, a 64-bit positive integer).  This number is used in
      connectivity checks to detect and repair this case, as described
      in Section 7.1.2.2 .


Or am I misreading, and each m= line corresponds to its own ICE Agent,
with its own tiebreaker value?


Thanks,

--justin

--20cf300fae13ad8d1204cbd6c2b7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Reviewing the handling of role conflicts, a question came up: in the event =
different systems handle different media in a session, do they have to shar=
e the same ICE tiebreaker?

Section 5.2 of RFC 5245 indic=
ates that the ICE Agent chooses the tiebreaker, indicating that this is a s=
ession-level value.



 To resolve this, each agent MUST select a random numbe=
r, called
      the tie-breaker, uniformly distributed between 0 and (2**64) - 1
      (that is, a 64-bit positive integer).  This number is used in
      connectivity checks to detect and repair this case, as described
      in Sec=
tion 7.1.2.2.


Or am I misreading, and each m=3D line corresponds to its own=
 ICE Agent, with its own tiebreaker value?


Thanks,<=
/pre>


--justin


--20cf300fae13ad8d1204cbd6c2b7--

From thomas.stach@siemens-enterprise.com  Fri Oct 12 00:58:03 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED84621F851B for ; Fri, 12 Oct 2012 00:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level: 
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VzIN2dAsMZH for ; Fri, 12 Oct 2012 00:58:03 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CFA6C21F850D for ; Fri, 12 Oct 2012 00:58:02 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 8AD611EB8455; Fri, 12 Oct 2012 09:58:01 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 09:58:01 +0200
From: "Stach, Thomas" 
To: Harald Alvestrand 
Thread-Topic: AW: AW: How does mmt grouping work with multiple streams of the same type?
Thread-Index: AQHNp760LlzeyMAvekOpo0q27dYr2pe0Np8ngAAAnTA=
Date: Fri, 12 Oct 2012 07:58:01 +0000
Message-ID: 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>
In-Reply-To: <5076E2AB.2070507@alvestrand.no>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 07:58:04 -0000

inline

> -----Urspr=FCngliche Nachricht-----
> Von: Harald Alvestrand [mailto:harald@alvestrand.no]=20
> Gesendet: Donnerstag, 11. Oktober 2012 17:16
> An: Stach, Thomas
> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> Betreff: Re: AW: AW: How does mmt grouping work with multiple=20
> streams of the same type?
>=20
> On 10/11/2012 04:55 PM, Stach, Thomas wrote:
> > inline
> >
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: Harald Alvestrand [mailto:harald@alvestrand.no]
> >> Gesendet: Donnerstag, 11. Oktober 2012 16:45
> >> An: Stach, Thomas
> >> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> >> Betreff: Re: AW: How does mmt grouping work with multiple
> >> streams of the same type?
> >>
> >> On 10/11/2012 04:13 PM, Stach, Thomas wrote:
> >>> Harald,
> >>>
> >>> thanks for the reply.
> >>> It helps for my second question, but not for my main question.
> >>> How can the answerer recognize (from the m=3Danymedia line
> >> alone) that multiple video streams need to be set up in the
> >> same RTP session?
> >> If each video stream is signalled by the presence of=20
> SSRC-associated
> >> signalling for that video stream, you count the number of
> >> video streams signalled.
> > Could that be done by e.g. enhancing the new a=3Dmmtype with=20
> an ssrc element?
> > E.g.
> >
> >         a=3Dmmtype: 0 audio ssrc=3D1
> >         a=3Dmmtype: 8 audio ssrc=3D1
> >         a=3Dmmtype: 97 audio ssrc=3D2
> >         a=3Dmmtype: 31 video ssrc=3D3
> >         a=3Dmmtype: 32 video ssrc=3D4
> >
> > would mean 2 audio streams and 2 video streams, whereas
> >
> >         a=3Dmmtype: 0 audio ssrc=3D1
> >         a=3Dmmtype: 8 audio ssrc=3D1
> >         a=3Dmmtype: 97 audio ssrc=3D1
> >         a=3Dmmtype: 31 video ssrc=3D2
> >         a=3Dmmtype: 32 video ssrc=3D2
> >
> > means 1 audio and 1 video stream based on the number of=20
> different SSRCs?
>=20
> On the principle of "don't invent new stuff if you already=20
> have stuff",=20
> I think we should continue to use RFC 5576 for this purpose:
>=20
> a=3Dssrc:1 

I haven't thought about that, but yes it would work for as well.
For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it would loo=
k like this?=20

   a=3Drtpmap:0 PCMU/8000
   a=3Drtpmap:8 PCMA/8000
   a=3Drtpmap:97 iLBC/8000
   a=3Dmmtype: 0 audio=20
   a=3Dmmtype: 8 audio=20
   a=3Dmmtype: 97 audio
   a=3Dssrc:12345 fmtp:0=20
   a=3Dssrc:12345 fmtp:8=20
   a=3Dssrc:67890 fmtp:97=20


>=20
> The suggestion above wouldn't work for the case of two SSRCs=20
> both using the same payload type.
Well it would if you duplicated the a=3Dmmtype attribute with different ssr=
c elements in that case.
     a=3Dmmtype: 0 audio ssrc=3D1
     a=3Dmmtype: 0 audio ssrc=3D2
Would you do something else for a=3Dssrc?



Regards
Thomas


>=20
> >
> >>> Regards
> >>> Thomas
> >>>
> >>>> -----Urspr=FCngliche Nachricht-----
> >>>> Von: Harald Alvestrand [mailto:harald@alvestrand.no]
> >>>> Gesendet: Donnerstag, 11. Oktober 2012 15:41
> >>>> An: Stach, Thomas
> >>>> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> >>>> Betreff: Re: How does mmt grouping work with multiple streams
> >>>> of the same type?
> >>>>
> >>>> On 10/11/2012 03:12 PM, Stach, Thomas wrote:
> >>>>> Christer, Harald, Jonathan,
> >>>>>
> >>>>> I have the impression that the
> >>>> draft-holmberg-mmusic-sdp-mmt-negotiation is based on
> >>>> Jonathan's proposal
> >>>>> to have an explicit desrciption for the bundled streams as
> >>>> proposed in
> >>>>>=20
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
> >>>>>
> >>>>> Among other points the following is stated:
> >>>>> * The m=3Dbundle is a complete description of an entirely
> >>>> separate m-line; if it's used, the other m-lines in the group
> >>>> are rejected and the information they carry is ignored.
> >>>>> I think this a desirable property
> >>>>>
> >>>>> Now, consider a case were you have 4 streams, i.e. 4
> >>>> m-lines (e.g. 2 audio and 2 video).
> >>>>> How would that be mapped to the m=3Danymedia line?
> >>>>> How does mmt grouping work with multiple streams of the=20
> same type?
> >>>>>
> >>>>>    From the currently proposed syntax for the m=3Danymedia line
> >>>> I cannot deduce that multiple audio or video streams are offered.
> >>>>> I would have to look into the "legacy" m-lines to=20
> recognize this.
> >>>>> In case that e.g. the video stream use different codecs, I
> >>>> could also learn that only from the legacy m-lines.
> >>>>
> >>>> In the case where it's desirable to carry multiple video
> >>>> streams in one
> >>>> RTP session, and have different descriptions in SDP for
> >> the different
> >>>> video streams, there has to be some signalling that tells the
> >>>> recipient
> >>>> which description applies to which video stream.
> >>>>
> >>>> The video streams will have different SSRCSs. Therefore, the only
> >>>> reasonable answer in the MMT grouping case seems to be
> >>>> SSRC-associated
> >>>> signalling.
> >>>>
> >>>> In the other variants, it's actually unclear to me how the
> >>>> video streams
> >>>> described by the different m=3D lines would be detected by the
> >>>> recipients;
> >>>> I'd been assuming SSRC-associated signalling for other
> >>>> reasons, so only
> >>>> when this discussion resurfaced, I started thinking about
> >> this again,
> >>>> and discovered that I didn't have an answer.
> >>>>
> >>>> That is, in the description
> >>>>
> >>>> a=3Dgroup:bundle foo bar baz
> >>>> m=3Dvideo 4270
> >>>> a=3Dmid:foo
> >>>> a=3Dproperty-x:1
> >>>> m=3Dvideo
> >>>> a=3Dmid:bar
> >>>> a=3Dproperty-x:2
> >>>> m=3Dvideo
> >>>> a=3Dmid:baz
> >>>> a=3Dproperty-x:3
> >>>>
> >>>> one would expect a single RTP stream to be set up; when
> >> the recipient
> >>>> gets 3 video streams with SSRCS 234, 235 and 236, how does he
> >>>> know which
> >>>> stream should have which value for "property-x"?
> >>>> One can solve it with SSRC-associated signalling in this=20
> case too:
> >>>>
> >>>> a=3Dssrc:234 property-x:1
> >>>>
> >>>> but then you're back to doing SSRC-associated signalling, and
> >>>> if you're
> >>>> already doing that, we're not very different from the MMT
> >> description
> >>>> anyway.
> >>>>
> >>>> That's how I think of it at the moment, anyway - YMMV.
> >>>>
> >>>>
> >>>>
>=20
> =

From christer.holmberg@ericsson.com  Fri Oct 12 01:08:20 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23121F8527 for ; Fri, 12 Oct 2012 01:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.132
X-Spam-Level: 
X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.117,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqDGGJMCQJDF for ; Fri, 12 Oct 2012 01:08:19 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E93A21F8503 for ; Fri, 12 Oct 2012 01:08:18 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-91-5077cff19b62
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 87.D8.04547.1FFC7705; Fri, 12 Oct 2012 10:08:17 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 12 Oct 2012 10:08:17 +0200
From: Christer Holmberg 
To: Emil Ivov 
Date: Fri, 12 Oct 2012 10:08:15 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2n+DtxGjRhRK0WR4igXHZmBiwAFwAVQZtg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org>
In-Reply-To: <50773B73.6060508@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre7H8+UBBnc/iVms2TmBxWLq8scs DkweS5b8ZPL4/yYwgCmKyyYlNSezLLVI3y6BK+NPU1zBDe2KjndX2BoYHyt1MXJySAiYSNz9 t5gFwhaTuHBvPVsXIxeHkMApRom9N46xQjgLGSX+H2gAynBwsAlYSHT/0wZpEBGQl+huW8QE YjMLqEjsu3eDEcRmEVCVeHTgIRuILSygKHHr+CY2iHoliefPJ7FC2EYSS7tnMIPYvALhErcm HmOC2LWYWWLOjkawoZwCmhJv5z0CsxmBrvt+ag3UMnGJW0/mM0FcLSCxZM95ZghbVOLl43+s EPWiEnfa1zNC1OtILNj9iQ3C1pZYtvA11GJBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRWj cG5iZk56uZFealFmcnFxfp5eceomRmDkHNzyW3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAaNPhrftWePkBRZaq38Z7Zm/SOCBjbj6b9YjI8c0lOUWX8teG TajcmNAnHxe8LkLOY7Gta/k9ztKd19u1sqw43r+U3cS9zFJ/2YLlSbtZ5z0W2GWrHTf/QLXj Ot2258x/CpjEb4b8mHZyolP+WvNLPxzM5rp1vppy7vCUzfc0z3pGBMq1dNs+UWIpzkg01GIu Kk4EAOJyhSxqAgAA
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 08:08:20 -0000

Hi,

Q1: Remote endpoint support (SIP):=20
--------------------------------------------

>>>> Also, I guess I still haven't completely understood the backward=20
>>>> compatibility issue, but I guess I need to do some more reading.
>>>=20
>>> We describe these in Section 3 but the main problem is that a vanilla=20
>>> ICE agent that gets a first subset of candidates (that may also be=20
>>> empty) would declare failure prematurely.
>>=20
>> The text gives an example where the receiver (Bob) receives a=20
>> host-candidate-only offer, and start checks which fail.
>>=20
>> I think it's quite strange if Bob would reject the call at that point.=20
>> Because, no matter how many candidates the offer contains, there might=20
>> still be peer reflexive candidates created later,
>
> How does Bob know that there's going to be a "later" ? It's just a vanill=
a ICE agent that assumed it received a full set of candidates, it checked t=
hem all, all checks failed.

Bob knows that there will be STUN requests coming, and based on those addit=
ional candidates (peer reflexive) might be created.

> Now, we could rely on Bob not doing anything rash and waiting patiently f=
or reINVITEs from Alice in order to get more candidates ...

The peer reflexive candidates will not come in a re-INVITE, they will be cr=
eated based on the STUN requests.

Having said that, I agree that legacy ICE endpoints might not behave that w=
ay, and reject the call, but then we would simply do a fallback to legacy I=
CE.=20

> Besides there are other possible failures, like for example the case wher=
e I get your server reflexive candidates long before you get mine so we per=
form checks out of sync (the case that I also described in my other mail to=
 Martin).

I'll need to re-read that.

>>>>>>> we could do the same for BUNDLE, and we wouldn't have issues with=20
>>>>>>> re-using the same ports in multiple m- lines etc :)
>>>>>>=20
>>>>>> Well, we are not saying that they should not be addressed at all,=20
>>>>>> or even now. Just that maybe they shouldn't be addressed by this=20
>>>>>> specific document.
>>>>>=20
>>>>> Perhaps we shouldn't say anything about finding out in advance,=20
>>>>> then. At least not use SHOULD.
>>>>>=20
>>>>> We CAN describe what may happen if the remote peer does not support=20
>>>>> trickle ICE, but leave it to that.
>>>>=20
>>>> What we'd like to avoid is having trickle ICE offers to vanilla ICE=20
>>>> agents and then having them fail in a user-perceptible way.
>>>>=20
>>> Maybe we could modify the "SHOULD verify support" to "SHOULD verify=20
>>> support or provide a mechanism for transparent fallback to vanilla=20
>>> ICE"
>>=20
>> In my opinion, if one has to do something extra (e.g. send OPTIONS),=20
>> the whole idea of trickle-ICE goes away, because at the end of the day=20
>> you won't save any time in call establishment.
>
> The OPTIONS request does not need to be sent right before the call. It ca=
n be done once, upon bootstrap.

Yes, but in that case there is an even less chance that the OPTIONS and INV=
ITE requests will reach the same remote peer (in case of forking).

>> Now, if the browser is communicating with a ICE terminating gateway,=20
>> and if the browser performs SIP registration, then the gateway can=20
>> indicate trickle-ICE during registration.
>>=20
>> But, in the peer-to-peer case I don't know how it would work. It's not=20
>> even sure OPTIONS would reach the same remote peer as the INVITE...
>
> I agree. Not sure what to say other than, I agree that SIP does not have =
good mechanisms for XMPP like negotiation of entity caps but, personally, I=
 do believe that finding one would be helpful here.
>
> Maybe we can work on making sure that 3840 (or some other mechanism) woul=
d better allow for caps to be discovered in advance.
>
>At the very least, if we can't find a way to do this gracefully with SIP, =
we can RECOMMEND it whenever the protocol allows it and try to devise a fal=
l back strategy when it does not (e.g. with SIP).

There ARE ways to do it, but they all suck :)


Q3: Enough is enough:=20
---------------------------

>>>>>> I think it could be useful for the answerer to tell the offerer=20
>>>>>> that it doesn't want/need any more candidates.
>>>>>=20
>>>>> Yes, sounds useful. Do you have any specific use cases in mind?
>>>>=20
>>>> Well, I guess any case where the remote peer knows it has a public=20
>>> IP address (it will most likely be an ICE lite entity).
>>>=20
>>> Right, but in such cases the offerer would also know that a certain=20
>>> pair has succeeded so if they continue it might be with the purpose=20
>>> of finding a better RTT or a higher priority local candidate.
>>>=20
>>> I guess what I am trying to say is that a Binding Response is enough=20
>>> of an indication that trickling can stop. If it doesn't then maybe=20
>>> it's for a reason.
>>=20
>> Maybe it is enough... In any case I think it would be good to document=20
>> :)
>
> OK. Agreed.
>
>> Also, at least in cases where the remote peer only provide a host=20
>> candidate (because it has a public IP address), one should be smart=20
>> enough to figure out that there most likely will be no better=20
>> alternative.
>
> I am not sure I got this.

If the remote peer only provides a host candidate, and it works, I think th=
ere won't be any better alternatives.

Anyway, it's not that important, just some brainstorming from my side :)

Regards,

Christer



From harald@alvestrand.no  Fri Oct 12 01:44:40 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134CB21F8499 for ; Fri, 12 Oct 2012 01:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.791
X-Spam-Level: 
X-Spam-Status: No, score=-109.791 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwDHiFjbe2ls for ; Fri, 12 Oct 2012 01:44:39 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EDAE821F847D for ; Fri, 12 Oct 2012 01:44:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9DBD39E091; Fri, 12 Oct 2012 10:44:37 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlE6xcArb6rP; Fri, 12 Oct 2012 10:44:37 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:fc1c:ba7f:f912:f2d7] (unknown [IPv6:2001:470:de0a:27:fc1c:ba7f:f912:f2d7]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id BEAD139E062; Fri, 12 Oct 2012 10:44:36 +0200 (CEST)
Message-ID: <5077D873.20103@alvestrand.no>
Date: Fri, 12 Oct 2012 10:44:35 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Stach, Thomas" 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 08:44:40 -0000

On 10/12/2012 09:58 AM, Stach, Thomas wrote:
>> >I think we should continue to use RFC 5576 for this purpose:
>> >
>> >a=ssrc:1 
> I haven't thought about that, but yes it would work for as well.
> For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it would look like this?
>
>     a=rtpmap:0 PCMU/8000
>     a=rtpmap:8 PCMA/8000
>     a=rtpmap:97 iLBC/8000
>     a=mmtype: 0 audio
>     a=mmtype: 8 audio
>     a=mmtype: 97 audio
>     a=ssrc:12345 fmtp:0
>     a=ssrc:12345 fmtp:8
>     a=ssrc:67890 fmtp:97
Yes, except that as far as I can tell from RFC 5576, you can't use fmtp: 
without an actual parameter value: "This parameter MUST only be used for 
media
    types for which source-level format parameters have explicitly been
    specified". (section 6.3).

If you need to use a field that's always present, use CNAME.

Note(1): If you only use one payload type for all your audio, you have 
no need to signal which format they're using.

Note(2): In the above, you have ssrc 12345 using both PCMU/8000 and 
PCMA/8000. I don't know if it's intentional or not.

>> >
>> >The suggestion above wouldn't work for the case of two SSRCs
>> >both using the same payload type.
> Well it would if you duplicated the a=mmtype attribute with different ssrc elements in that case.
>       a=mmtype: 0 audio ssrc=1
>       a=mmtype: 0 audio ssrc=2
> Would you do something else for a=ssrc?

Well, a=ssrc *is* something else. The above mixes info about payload 
types and info about SSRCs; I think that's a bad design.



From harald@alvestrand.no  Fri Oct 12 02:34:38 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F9321F8543 for ; Fri, 12 Oct 2012 02:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level: 
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnbcAc3Uz5mO for ; Fri, 12 Oct 2012 02:34:38 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id ED5FE21F853F for ; Fri, 12 Oct 2012 02:34:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C233139E091 for ; Fri, 12 Oct 2012 11:34:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-343A2Jj0w8 for ; Fri, 12 Oct 2012 11:34:34 +0200 (CEST)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C5DC939E062 for ; Fri, 12 Oct 2012 11:34:34 +0200 (CEST)
Message-ID: <5077E42A.40306@alvestrand.no>
Date: Fri, 12 Oct 2012 11:34:34 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] MSID and mslabel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 09:34:38 -0000

On 10/11/2012 04:30 PM, Bernard Aboba wrote:
> Question:  Can someone comment on the difference between msid and the
> "mslabel" attribute?
I think "mslabel" was an early name for an attempt to do the same thing 
as msid, but never got a formal proposal attached to it.

Given that the word "label" often refers to human readable text, I 
prefer "id" for identifiers that must be unique and are not intended for 
human consumption.

(I may have missed something else called "mslabel", though).

>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
> Stefan Hakansson LK
> Sent: Thursday, October 11, 2012 7:13 AM
> To: mmusic@ietf.org
> Subject: [MMUSIC] WG poll for consensus MSID draft
>
> I'm not a MMUSIC regular, but active in rtcweb. I would like this draft to
> go forward as the info that msid provides is necessary for "gluing together"
> the JS API and the actual rtp streams.
>
> Stefan
>
>
> "At the last IETF meeting we had a presentation of the following draft:
>
> http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/
>
> At that time, there was interest in solving the problem of cross session
> stream identification.
>
>
> We would like to poll the working group for consensus on adopting the
> above mentioned draft as a working group item, once we get an approved
> milestone.
>
>
> If you support this work or have problems with the adoption of this
> document as WG item, please indicate it by replying to this e-mail
> within the next 5 days.
>
>
> Flemming and Miguel (co-chairs)
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain"
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From harald@alvestrand.no  Fri Oct 12 02:35:17 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E314121F8562 for ; Fri, 12 Oct 2012 02:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.149
X-Spam-Level: 
X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tijKtmYWWyyj for ; Fri, 12 Oct 2012 02:35:17 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6038B21F8567 for ; Fri, 12 Oct 2012 02:35:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 67ED339E091; Fri, 12 Oct 2012 11:35:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSsrTk5e1zLu; Fri, 12 Oct 2012 11:35:14 +0200 (CEST)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CD0E039E062; Fri, 12 Oct 2012 11:35:14 +0200 (CEST)
Message-ID: <5077E452.1020502@alvestrand.no>
Date: Fri, 12 Oct 2012 11:35:14 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Miguel A. Garcia" 
References: <50742574.6080200@ericsson.com>
In-Reply-To: <50742574.6080200@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Flemming Andreasen , mmusic 
Subject: Re: [MMUSIC] WG poll for consensus MSID draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 09:35:18 -0000

Unsurprisingly, the draft author would like to see the draft go forward.
I have not seen another complete proposal for doing what this draft does.

On 10/09/2012 03:24 PM, Miguel A. Garcia wrote:
> At the last IETF meeting we had a presentation of the following draft:
>
> http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/
>
> At that time, there was interest in solving the problem of cross 
> session stream identification.
>
> We would like to poll the working group for consensus on adopting the 
> above mentioned draft as a working group item, once we get an approved 
> milestone.
>
> If you support this work or have problems with the adoption of this 
> document as WG item, please indicate it by replying to this e-mail 
> within the next 5 days.
>
> Flemming and Miguel (co-chairs)
>


From thomas.stach@siemens-enterprise.com  Fri Oct 12 03:15:22 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8251121F856C for ; Fri, 12 Oct 2012 03:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-GBJGKnCy38 for ; Fri, 12 Oct 2012 03:15:21 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6D33221F8527 for ; Fri, 12 Oct 2012 03:15:21 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 86FD01EB84D8; Fri, 12 Oct 2012 12:15:20 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 12:15:20 +0200
From: "Stach, Thomas" 
To: Harald Alvestrand 
Thread-Topic: AW: AW: AW: How does mmt grouping work with multiple streams of the same type?
Thread-Index: AQHNqFXRBmp+pOZsF0CIj8CaYweqY5e1YuGQ
Date: Fri, 12 Oct 2012 10:15:19 +0000
Message-ID: 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>  <5077D873.20103@alvestrand.no>
In-Reply-To: <5077D873.20103@alvestrand.no>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 10:15:22 -0000

Harald Alvestrand wrote:
> On 10/12/2012 09:58 AM, Stach, Thomas wrote:
>>>> I think we should continue to use RFC 5576 for this purpose:
>>>>=20
>>>> a=3Dssrc:1 
>> I haven't thought about that, but yes it would work for as well.
>> For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it
>> would look like this?=20
>>=20
>>     a=3Drtpmap:0 PCMU/8000
>>     a=3Drtpmap:8 PCMA/8000
>>     a=3Drtpmap:97 iLBC/8000
>>     a=3Dmmtype: 0 audio
>>     a=3Dmmtype: 8 audio
>>     a=3Dmmtype: 97 audio
>>     a=3Dssrc:12345 fmtp:0
>>     a=3Dssrc:12345 fmtp:8
>>     a=3Dssrc:67890 fmtp:97
> Yes, except that as far as I can tell from RFC 5576, you
> can't use fmtp:
> without an actual parameter value: "This parameter MUST only
> be used for
> media
>     types for which source-level format parameters have
> explicitly been
>     specified". (section 6.3).
>=20
> If you need to use a field that's always present, use CNAME.
>=20
> Note(1): If you only use one payload type for all your audio,
> you have
> no need to signal which format they're using.
>=20
> Note(2): In the above, you have ssrc 12345 using both PCMU/8000 and
> PCMA/8000. I don't know if it's intentional or not.
>=20
Yes, this was intentional,=20
I used two different ssrc (12345, 67890) in order to indicate that I want t=
o establish two audio streams.=20
I used ssrc=3D12345 twice in order to give a hint that the first audio stre=
am should either use PCMU or PCMA (and ssrc=3D12345).
The second audio stream would use ssrc=3D67890 and iLBC.

However from your responses I'm not sure if we are on the same page with re=
spect to what I want to achieve.
Let me tray to clarify.

My understanding is that=20
- the m=3Danymedia gives a complete description of what is offered,
- if the answerer understands m=3Danymedia, it accepts the m=3Danymedia lin=
e and rejects all other m-lines
- if the answerer understands m=3Danymedia, it can ignore all other m-lines=
 in the SDP, it doesn't even have to look at them in order to build its ans=
wer.

If this is correct, consider an SDP offer with e.g. 4 m-lines (2 audio+2 vi=
deo)

       v=3D0
       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=3D
       c=3DIN IP4 host.atlanta.com
       t=3D0 0
       m=3Daudio 10000 RTP/AVP 0 8
       a=3Drtpmap:0 PCMU/8000
       a=3Drtpmap:8 PCMA/8000
       m=3Daudio 10002 RTP/AVP 97
       a=3Drtpmap:97 iLBC/8000
       m=3Dvideo 20000 RTP/AVP 31=20
       a=3Drtpmap:31 H261/90000
       m=3Dvideo 20002 RTP/AVP 32
       a=3Drtpmap:32 MPV/90000

How would the associated m=3Danymedia line look like in this case, such tha=
t the answerer can see=20
that 2 audio and 2 video streams are offered without having to look into th=
e other m-lines?

How would the answer look like?

Thanks
Thomas


>>>>=20
>>>> The suggestion above wouldn't work for the case of two SSRCs
>>>> both using the same payload type.
>> Well it would if you duplicated the a=3Dmmtype attribute with
> different ssrc elements in that case.
>>       a=3Dmmtype: 0 audio ssrc=3D1
>>       a=3Dmmtype: 0 audio ssrc=3D2
>> Would you do something else for a=3Dssrc?
>=20
> Well, a=3Dssrc *is* something else. The above mixes info about payload
> types and info about SSRCs; I think that's a bad design.


From christer.holmberg@ericsson.com  Fri Oct 12 03:41:33 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF36221F8567 for ; Fri, 12 Oct 2012 03:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.235
X-Spam-Level: 
X-Spam-Status: No, score=-5.235 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbyjxkaBsQN0 for ; Fri, 12 Oct 2012 03:41:33 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9399B21F855A for ; Fri, 12 Oct 2012 03:41:32 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-f7-5077f3db1da2
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3A.8A.11467.BD3F7705; Fri, 12 Oct 2012 12:41:31 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 12 Oct 2012 12:41:30 +0200
From: Christer Holmberg 
To: "Stach, Thomas" , Harald Alvestrand 
Date: Fri, 12 Oct 2012 12:41:28 +0200
Thread-Topic: AW: AW: AW: How does mmt grouping work with multiple streams of the same type?
Thread-Index: AQHNqFXRBmp+pOZsF0CIj8CaYweqY5e1YuGQgAASNEA=
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0B9@ESESSCMS0356.eemea.ericsson.se>
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>  <5077D873.20103@alvestrand.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvre7tz+UBBr0nFC2O9XWxWexffJ7Z YuryxywWu7bXOLB4XJlwhdVjyZKfTB43br9n9mh7doc9gCWKyyYlNSezLLVI3y6BK+PA0ROs BS1yFdtfd7E3MM4Q72Lk5JAQMJE4e+4GE4QtJnHh3nq2LkYuDiGBU4wSW07+ZQZJCAksZJTY flGni5GDg03AQqL7nzZIWEQgVeJRz2F2EJtZwFXixLqnYHNYBFQl2neuZAGxhQViJXa+XcAK UR8nseHCeyjbSqLr12VGEJtXIFxi7bLnUHvfMEvMudMAtpdTwF+idfYmMJsR6Ljvp9YwQSwT l7j1ZD7U0QISS/acZ4awRSVePv7HClEvKnGnfT0jRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJ ywRGsVlIxs5C0jILScssJC0LGFlWMQrnJmbmpJcb6qUWZSYXF+fn6RWnbmIERtjBLb91dzCe OidyiFGag0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbx7fafT5TpyAk/3FXI /GhVhdmc60cPsrB0OjOtUVhmpvul5OXs+LkBLRq/9t87lOyYJvx+Vxd/dH5j7P34QrcNKotk LNmW5P4Su8Fjr6H1/cB/hw22THPOTgpWzeY/Wtxv/+2ub/iNBQ+WBjq41ny146zgtRTecr9+ 0RRLpl+BCz9YBH07IKvEUpyRaKjFXFScCACF12TTfgIAAA==
Cc: Jonathan Lennox , mmusic WG 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 10:41:34 -0000

Hi,

Jumping in late - trying to catch up :)

>>>>> I think we should continue to use RFC 5576 for this purpose:
>>>>>=20
>>>>> a=3Dssrc:1 
>>> I haven't thought about that, but yes it would work for as well.
>>> For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it=20
>>> would look like this?
>>>=20
>>>     a=3Drtpmap:0 PCMU/8000
>>>     a=3Drtpmap:8 PCMA/8000
>>>     a=3Drtpmap:97 iLBC/8000
>>>     a=3Dmmtype: 0 audio
>>>     a=3Dmmtype: 8 audio
>>>     a=3Dmmtype: 97 audio
>>>     a=3Dssrc:12345 fmtp:0
>>>     a=3Dssrc:12345 fmtp:8
>>>     a=3Dssrc:67890 fmtp:97
>> Yes, except that as far as I can tell from RFC 5576, you can't use=20
>> fmtp:
>> without an actual parameter value: "This parameter MUST only be used=20
>> for media types for which source-level format parameters have explicitly=
=20
>> been specified". (section 6.3).
>>=20
>> If you need to use a field that's always present, use CNAME.
>>=20
>> Note(1): If you only use one payload type for all your audio, you have=20
>> no need to signal which format they're using.
>>=20
>> Note(2): In the above, you have ssrc 12345 using both PCMU/8000 and=20
>> PCMA/8000. I don't know if it's intentional or not.
>>=20
> Yes, this was intentional,
> I used two different ssrc (12345, 67890) in order to indicate that I want=
 to establish two audio streams.=20
>
> I used ssrc=3D12345 twice in order to give a hint that the first audio st=
ream should either use PCMU or PCMA (and ssrc=3D12345).
> The second audio stream would use ssrc=3D67890 and iLBC.

Even without BUNDLE, this is how you would do it if you offer multiple stre=
ams within a single m- line.

> However from your responses I'm not sure if we are on the same page with =
respect to what I want to achieve.
> Let me tray to clarify.
>
> My understanding is that
> - the m=3Danymedia gives a complete description of what is offered,
> - if the answerer understands m=3Danymedia, it accepts the m=3Danymedia l=
ine and rejects all other m-lines

Correct.

(All other m- lines associated with the MMT group, that is)

> - if the answerer understands m=3Danymedia, it can ignore all other m-lin=
es in the SDP, it doesn't even have to look at them in order to build its a=
nswer.

Correct.

(All other m- lines associated with the MMT group, that is)

> If this is correct, consider an SDP offer with e.g. 4 m-lines (2 audio+2 =
video)
>
>       v=3D0
>       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
>       s=3D
>       c=3DIN IP4 host.atlanta.com
>       t=3D0 0
>       m=3Daudio 10000 RTP/AVP 0 8
>       a=3Drtpmap:0 PCMU/8000
>       a=3Drtpmap:8 PCMA/8000
>       m=3Daudio 10002 RTP/AVP 97
>       a=3Drtpmap:97 iLBC/8000
>       m=3Dvideo 20000 RTP/AVP 31=20
>       a=3Drtpmap:31 H261/90000
>       m=3Dvideo 20002 RTP/AVP 32
>       a=3Drtpmap:32 MPV/90000
>
> How would the associated m=3Danymedia line look like in this case, such t=
hat the answerer can see that 2 audio and 2 video streams are offered witho=
ut having to look into the other m-lines?

Note that there are still some details (e.g. whether "RTP/AVP" is going to =
be used) that have to be sorted out, but something like this:

m=3Danytype 10000 RTP/AVP 0 8 97 31 32
a=3Dmmtype: 0 audio
a=3Dmmtype: 8 audio
a=3Dmmtype: 97 audio
a=3Dmmtype: 31 video
a=3Dmmtype: 32 video
a=3Drtpmap:0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:97 iLBC/8000
a=3Drtpmap:31 H261/90000
a=3Drtpmap:32 MPV/90000

Then, you will use the SSRC attribute to identify the streams. But, we do n=
eed to define how to associate SSRCs with media types and/or payload types.

In one of your e-mails, you suggested to extend the mmtype attribute. That'=
s for sure one possibility.

Regards,

Christer


From harald@alvestrand.no  Fri Oct 12 03:41:58 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBE121F8545 for ; Fri, 12 Oct 2012 03:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.463
X-Spam-Level: 
X-Spam-Status: No, score=-109.463 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nemCtHqfT4oq for ; Fri, 12 Oct 2012 03:41:57 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4498121F8575 for ; Fri, 12 Oct 2012 03:41:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45C3039E091; Fri, 12 Oct 2012 12:41:56 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBdGNOwcLvbS; Fri, 12 Oct 2012 12:41:55 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:fc1c:ba7f:f912:f2d7] (unknown [IPv6:2001:470:de0a:27:fc1c:ba7f:f912:f2d7]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 153EA39E062; Fri, 12 Oct 2012 12:41:55 +0200 (CEST)
Message-ID: <5077F3F2.7010805@alvestrand.no>
Date: Fri, 12 Oct 2012 12:41:54 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Stach, Thomas" 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>  <5077D873.20103@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jonathan Lennox , mmusic WG , Christer Holmberg 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 10:41:58 -0000

On 10/12/2012 12:15 PM, Stach, Thomas wrote:
> Harald Alvestrand wrote:
>> On 10/12/2012 09:58 AM, Stach, Thomas wrote:
>>>>> I think we should continue to use RFC 5576 for this purpose:
>>>>>
>>>>> a=ssrc:1 
>>> I haven't thought about that, but yes it would work for as well.
>>> For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it
>>> would look like this?
>>>
>>>      a=rtpmap:0 PCMU/8000
>>>      a=rtpmap:8 PCMA/8000
>>>      a=rtpmap:97 iLBC/8000
>>>      a=mmtype: 0 audio
>>>      a=mmtype: 8 audio
>>>      a=mmtype: 97 audio
>>>      a=ssrc:12345 fmtp:0
>>>      a=ssrc:12345 fmtp:8
>>>      a=ssrc:67890 fmtp:97
>> Yes, except that as far as I can tell from RFC 5576, you
>> can't use fmtp:
>> without an actual parameter value: "This parameter MUST only
>> be used for
>> media
>>      types for which source-level format parameters have
>> explicitly been
>>      specified". (section 6.3).
>>
>> If you need to use a field that's always present, use CNAME.
>>
>> Note(1): If you only use one payload type for all your audio,
>> you have
>> no need to signal which format they're using.
>>
>> Note(2): In the above, you have ssrc 12345 using both PCMU/8000 and
>> PCMA/8000. I don't know if it's intentional or not.
>>
> Yes, this was intentional,
> I used two different ssrc (12345, 67890) in order to indicate that I want to establish two audio streams.
> I used ssrc=12345 twice in order to give a hint that the first audio stream should either use PCMU or PCMA (and ssrc=12345).
> The second audio stream would use ssrc=67890 and iLBC.
>
> However from your responses I'm not sure if we are on the same page with respect to what I want to achieve.
> Let me tray to clarify.
>
> My understanding is that
> - the m=anymedia gives a complete description of what is offered,
> - if the answerer understands m=anymedia, it accepts the m=anymedia line and rejects all other m-lines
> - if the answerer understands m=anymedia, it can ignore all other m-lines in the SDP, it doesn't even have to look at them in order to build its answer.
>
> If this is correct, consider an SDP offer with e.g. 4 m-lines (2 audio+2 video)
>
>         v=0
>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=
>         c=IN IP4 host.atlanta.com
>         t=0 0
>         m=audio 10000 RTP/AVP 0 8
>         a=rtpmap:0 PCMU/8000
>         a=rtpmap:8 PCMA/8000
>         m=audio 10002 RTP/AVP 97
>         a=rtpmap:97 iLBC/8000
>         m=video 20000 RTP/AVP 31
>         a=rtpmap:31 H261/90000
>         m=video 20002 RTP/AVP 32
>         a=rtpmap:32 MPV/90000
>
> How would the associated m=anymedia line look like in this case, such that the answerer can see
> that 2 audio and 2 video streams are offered without having to look into the other m-lines?
This offer does not guarantee that there are only 2 audio and 2 video 
streams.
It makes it a fair assumption that there are at least 2 of each (unless 
some of the m-lines are intended to be used for receiveonly), but it is 
perfectly legal to send more than one audio stream in each RTP session 
under each M-line.

So I don't think the starting point you're starting from is correct; 
until draft-westerlund-mmusic-max-ssrc or something like it is accepted, 
you have no way to tell *now* how many streams you are going to get.


From harald@alvestrand.no  Fri Oct 12 03:43:49 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE4021F8468 for ; Fri, 12 Oct 2012 03:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.319
X-Spam-Level: 
X-Spam-Status: No, score=-110.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRyftuxuAu-Z for ; Fri, 12 Oct 2012 03:43:49 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CF71B21F8443 for ; Fri, 12 Oct 2012 03:43:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA90039E091; Fri, 12 Oct 2012 12:43:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC2ZewmxeqxX; Fri, 12 Oct 2012 12:43:47 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:fc1c:ba7f:f912:f2d7] (unknown [IPv6:2001:470:de0a:27:fc1c:ba7f:f912:f2d7]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1C30839E062; Fri, 12 Oct 2012 12:43:47 +0200 (CEST)
Message-ID: <5077F462.4070306@alvestrand.no>
Date: Fri, 12 Oct 2012 12:43:46 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>  <5077D873.20103@alvestrand.no>  <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0B9@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0B9@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jonathan Lennox , mmusic WG 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 10:43:49 -0000

On 10/12/2012 12:41 PM, Christer Holmberg wrote:
> Then, you will use the SSRC attribute to identify the streams. But, we 
> do need to define how to associate SSRCs with media types and/or 
> payload types. In one of your e-mails, you suggested to extend the 
> mmtype attribute. That's for sure one possibility. Regards, Christer 
If you need to know this before you start getting media, we need signalling.

Otherwise, we just look at the PT field and the SSRC field in the 
incoming packets.


From christer.holmberg@ericsson.com  Fri Oct 12 04:06:49 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB7121F855F for ; Fri, 12 Oct 2012 04:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.127
X-Spam-Level: 
X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=0.122,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NZcH0jHQQJJ for ; Fri, 12 Oct 2012 04:06:48 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E077421F857E for ; Fri, 12 Oct 2012 04:06:47 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-de-5077f9c67551
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AD.B4.04547.6C9F7705; Fri, 12 Oct 2012 13:06:46 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 12 Oct 2012 13:06:46 +0200
From: Christer Holmberg 
To: Harald Alvestrand 
Date: Fri, 12 Oct 2012 13:06:44 +0200
Thread-Topic: AW: AW: AW: How does mmt grouping work with multiple streams of the same type?
Thread-Index: Ac2oZnYt4eIueylWQgScJlv09tAWAQAAuN0A
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0FE@ESESSCMS0356.eemea.ericsson.se>
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>  <5077D873.20103@alvestrand.no>  <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0B9@ESESSCMS0356.eemea.ericsson.se> <5077F462.4070306@alvestrand.no>
In-Reply-To: <5077F462.4070306@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvre6xn+UBBidPKVkc6+tis9i/+Dyz xdTlj1ksdm2vcWDxuDLhCqvHkiU/mTxu3H7P7NH27A57AEsUl01Kak5mWWqRvl0CV8bsFY9Z CyazVcyevJqxgfEJSxcjJ4eEgIlEW9t1RghbTOLCvfVsXYxcHEICpxglrs18xAySEBJYyCjx 8kNdFyMHB5uAhUT3P22QsIiAjsTD/Q1MIDazQJ3EgfuLwMpZBFQlJiy+CRYXFoiV2Pl2AStE fZzEhgvvoWwjib0f5rKD2LwC4RL/Zs1ihth7l0Xi+I8fYAlOAV2JN0sugw1iBDru+6k1UMvE JW49mc8EcbSAxJI955khbFGJl4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58 wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgRF2cMtv1R2M d86JHGKU5mBREue13rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj4+0jb6T/MybUb92z Jbxp4YbWg46Tal3f5+s8DumYdO7ACXaxE5c1NK3PX5OTc0g17c7VubYt70SUilO4Wsi89VId yt/55BZv/rj5mEzT+jlHOYUWM9x8cqlFrnHaiqJpIR4zL7qfNmDretD5PcjBQ8WO2XyuZ2yk nbajbWyAxPplzO7zfzMpsRRnJBpqMRcVJwIAM+/zEX4CAAA=
Cc: Jonathan Lennox , mmusic WG 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 11:06:49 -0000

Hi,

>> Then, you will use the SSRC attribute to identify the streams. But, we=20
>> do need to define how to associate SSRCs with media types and/or=20
>> payload types. In one of your e-mails, you suggested to extend the=20
>> mmtype attribute. That's for sure one possibility.=20
>
> If you need to know this before you start getting media, we need signalli=
ng.
>
> Otherwise, we just look at the PT field and the SSRC field in the incomin=
g packets.

Correct.

I guess we can add it as an open issue whether one needs to be able to sign=
al it.

But, again, the possibility to associate PTs with SSRCs is not BUNDLE speci=
fic. You may want it also when you have multiple streams (same media type) =
associated with a single m- line.

Regards,

Christer


From emil@sip-communicator.org  Fri Oct 12 04:25:16 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6400121F8575 for ; Fri, 12 Oct 2012 04:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgMVazdmw7ad for ; Fri, 12 Oct 2012 04:25:15 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2174521F856D for ; Fri, 12 Oct 2012 04:25:14 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so481453wib.13 for ; Fri, 12 Oct 2012 04:25:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=FSbeJKz2UIs1SWMFc2UuQBZaR+HFfonmqOQyewK13dk=; b=WvhIkUs7GSQd9nZLPMiQIJkmYwpz2xAwhPVkYaM/lG8HDdpBeU+32fYqe3Csuhe/Hu cz+V/mLovcMLEmxcyKL1nS6ViTywJGIUmCbpv1MAvw/sf776LYdWwfCd6BFMng/HtSYQ lZJb+j78SateveySbqd24K0mqCfMIeQ3TlRMVgokX3DgcWoHByhmZ+kuvRmV+njfR1w/ r+pnQPT3HQZJOe1wDjBzBybU0oi8NGxK/d18WbCGrBbWs/50X+75yzfr+xm6E1Xt9vBv vJioghYRoDUWP/78pJAqdK2vXqeJ4scZvVZRzb3bAq57iq7jIuhvT1KbPD2OZ4q0EIgO dQlA==
Received: by 10.180.95.97 with SMTP id dj1mr5436624wib.3.1350041114190; Fri, 12 Oct 2012 04:25:14 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:8495:bad6:30a7:8ed9]) by mx.google.com with ESMTPS id hv8sm2913610wib.0.2012.10.12.04.25.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 04:25:13 -0700 (PDT)
Message-ID: <5077FE17.3010800@jitsi.org>
Date: Fri, 12 Oct 2012 13:25:11 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlZOqwLFgTMFUnMP04EWcFlR5XgH/G+Vz8eQjeAt+IgGl3kgeVKdoAAjMcsdJr9Idt11MZd
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 11:25:16 -0000

Hey Christer,

On 12.10.12, 10:08, Christer Holmberg wrote:
> Hi,
> 
> Q1: Remote endpoint support (SIP): 
> --------------------------------------------
> 
>>>>> Also, I guess I still haven't completely understood the
>>>>> backward compatibility issue, but I guess I need to do some
>>>>> more reading.
>>>> 
>>>> We describe these in Section 3 but the main problem is that a
>>>> vanilla ICE agent that gets a first subset of candidates (that
>>>> may also be empty) would declare failure prematurely.
>>> 
>>> The text gives an example where the receiver (Bob) receives a 
>>> host-candidate-only offer, and start checks which fail.
>>> 
>>> I think it's quite strange if Bob would reject the call at that
>>> point. Because, no matter how many candidates the offer contains,
>>> there might still be peer reflexive candidates created later,
>> 
>> How does Bob know that there's going to be a "later" ? It's just a
>> vanilla ICE agent that assumed it received a full set of
>> candidates, it checked them all, all checks failed.
> 
> Bob knows that there will be STUN requests coming, and based on those
> additional candidates (peer reflexive) might be created.

Chances are that no STUN requests will be arriving unless Bob is also
making simultaneous checks toward Alice's SR candidates, which he isn't
because he doesn't have them.

>> Now, we could rely on Bob not doing anything rash and waiting
>> patiently for reINVITEs from Alice in order to get more candidates
>> ...
> 
> The peer reflexive candidates will not come in a re-INVITE, they will
> be created based on the STUN requests.

That's kind of a corner case. Learning peer-reflexive candidates
implies that Bob can get Alice's conn checks which would only happen if
Bob's addresses are directly reachable from Alice (e.g. Bob has a public
address or a NAT with no endpoint dependent filtering). All in all, not
the most likely scenario.

> Having said that, I agree that legacy ICE endpoints might not behave
> that way, and reject the call, but then we would simply do a fallback
> to legacy ICE.

The problem is that in this case Bob might have been alerted of the call
and witnessed the failure, so a fallback to vanilla ICE would not be
particularly smooth.

>> Besides there are other possible failures, like for example the
>> case where I get your server reflexive candidates long before you
>> get mine so we perform checks out of sync (the case that I also
>> described in my other mail to Martin).
> 
> I'll need to re-read that.
> 
>>>>>>>> we could do the same for BUNDLE, and we wouldn't have
>>>>>>>> issues with re-using the same ports in multiple m-
>>>>>>>> lines etc :)
>>>>>>> 
>>>>>>> Well, we are not saying that they should not be addressed
>>>>>>> at all, or even now. Just that maybe they shouldn't be
>>>>>>> addressed by this specific document.
>>>>>> 
>>>>>> Perhaps we shouldn't say anything about finding out in
>>>>>> advance, then. At least not use SHOULD.
>>>>>> 
>>>>>> We CAN describe what may happen if the remote peer does not
>>>>>> support trickle ICE, but leave it to that.
>>>>> 
>>>>> What we'd like to avoid is having trickle ICE offers to
>>>>> vanilla ICE agents and then having them fail in a
>>>>> user-perceptible way.
>>>>> 
>>>> Maybe we could modify the "SHOULD verify support" to "SHOULD
>>>> verify support or provide a mechanism for transparent fallback
>>>> to vanilla ICE"
>>> 
>>> In my opinion, if one has to do something extra (e.g. send
>>> OPTIONS), the whole idea of trickle-ICE goes away, because at the
>>> end of the day you won't save any time in call establishment.
>> 
>> The OPTIONS request does not need to be sent right before the call.
>> It can be done once, upon bootstrap.
> 
> Yes, but in that case there is an even less chance that the OPTIONS
> and INVITE requests will reach the same remote peer (in case of
> forking).

True. Maybe adding gruu-s into the mix could help ... This would indeed
imply that the caller needs prior knowledge of the callee (e.g. adding
them to a contact list) but maybe we can have this and then another
solution for the first call/unknown callee case.

I am pretty much out of ideas for the time being anyway, so if you, or
anyone else, can think of something that would miraculously solve the
issue, I'd be very happy to hear it.

>>> Now, if the browser is communicating with a ICE terminating
>>> gateway, and if the browser performs SIP registration, then the
>>> gateway can indicate trickle-ICE during registration.
>>> 
>>> But, in the peer-to-peer case I don't know how it would work.
>>> It's not even sure OPTIONS would reach the same remote peer as
>>> the INVITE...
>> 
>> I agree. Not sure what to say other than, I agree that SIP does not
>> have good mechanisms for XMPP like negotiation of entity caps but,
>> personally, I do believe that finding one would be helpful here.
>> 
>> Maybe we can work on making sure that 3840 (or some other
>> mechanism) would better allow for caps to be discovered in
>> advance.
>> 
>> At the very least, if we can't find a way to do this gracefully
>> with SIP, we can RECOMMEND it whenever the protocol allows it and
>> try to devise a fall back strategy when it does not (e.g. with
>> SIP).
> 
> There ARE ways to do it, but they all suck :)

Is it realistic to expect that we can improve any of them to do the job?
Or add a new one?

> Q3: Enough is enough: ---------------------------
> 
>>>>>>> I think it could be useful for the answerer to tell the
>>>>>>> offerer that it doesn't want/need any more candidates.
>>>>>> 
>>>>>> Yes, sounds useful. Do you have any specific use cases in
>>>>>> mind?
>>>>> 
>>>>> Well, I guess any case where the remote peer knows it has a
>>>>> public
>>>> IP address (it will most likely be an ICE lite entity).
>>>> 
>>>> Right, but in such cases the offerer would also know that a
>>>> certain pair has succeeded so if they continue it might be with
>>>> the purpose of finding a better RTT or a higher priority local
>>>> candidate.
>>>> 
>>>> I guess what I am trying to say is that a Binding Response is
>>>> enough of an indication that trickling can stop. If it doesn't
>>>> then maybe it's for a reason.
>>> 
>>> Maybe it is enough... In any case I think it would be good to
>>> document :)
>> 
>> OK. Agreed.
>> 
>>> Also, at least in cases where the remote peer only provide a host
>>>  candidate (because it has a public IP address), one should be
>>> smart enough to figure out that there most likely will be no
>>> better alternative.
>> 
>> I am not sure I got this.
> 
> If the remote peer only provides a host candidate, and it works, I
> think there won't be any better alternatives.

I don't know about that. Well, what if the host candidate is actually an
IPv6 (or VPN) tunnel with poor latency and bandwidth and the SR
candidate works better? Or what if it's the address of an 802.11g/b
interface and the same machine has a NATed Ethernet connection with,
again, better bandwidth and latency?

All in all, making assumptions on the receiving end is always a risk. If
the host sending the candidates knows that they are its best/only
candidates, then it could indicated so by sending the end-of-candidates
message we describe in the draft.

Cheers,
Emil

> Anyway, it's not that important, just some brainstorming from my side
> :)
> 
> Regards,
> 
> Christer

From thomas.stach@siemens-enterprise.com  Fri Oct 12 05:01:48 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE24421F85A7 for ; Fri, 12 Oct 2012 05:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Level: 
X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GefuFzxz-OWN for ; Fri, 12 Oct 2012 05:01:47 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9421721F8582 for ; Fri, 12 Oct 2012 05:01:47 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id C93AF23F052D; Fri, 12 Oct 2012 14:01:45 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 14:01:45 +0200
From: "Stach, Thomas" 
To: Christer Holmberg , Harald Alvestrand 
Thread-Topic: AW: AW: AW: How does mmt grouping work with multiple streams of the same type?
Thread-Index: AQHNqFXRBmp+pOZsF0CIj8CaYweqY5e1YuGQgAASNECAABkDQA==
Date: Fri, 12 Oct 2012 12:01:44 +0000
Message-ID: 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>  <5077D873.20103@alvestrand.no>  <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0B9@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0B9@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox , mmusic WG 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 12:01:48 -0000

Christer Holmberg wrote:
> Hi,
>=20
> Jumping in late - trying to catch up :)
>=20
>>>>>> I think we should continue to use RFC 5576 for this purpose:
>>>>>>=20
>>>>>> a=3Dssrc:1 
>>>> I haven't thought about that, but yes it would work for as well.
>>>> For two audio streams (audio1 w/ PCMU or PCMA, audio2 w/ iLBC) it
>>>> would look like this?=20
>>>>=20
>>>>     a=3Drtpmap:0 PCMU/8000
>>>>     a=3Drtpmap:8 PCMA/8000
>>>>     a=3Drtpmap:97 iLBC/8000
>>>>     a=3Dmmtype: 0 audio
>>>>     a=3Dmmtype: 8 audio
>>>>     a=3Dmmtype: 97 audio
>>>>     a=3Dssrc:12345 fmtp:0
>>>>     a=3Dssrc:12345 fmtp:8
>>>>     a=3Dssrc:67890 fmtp:97
>>> Yes, except that as far as I can tell from RFC 5576, you can't use
>>> fmtp: without an actual parameter value: "This parameter MUST only
>>> be used for media types for which source-level format parameters
>>> have explicitly been specified". (section 6.3).
>>>=20
>>> If you need to use a field that's always present, use CNAME.
>>>=20
>>> Note(1): If you only use one payload type for all your audio, you
>>> have no need to signal which format they're using.
>>>=20
>>> Note(2): In the above, you have ssrc 12345 using both PCMU/8000 and
>>> PCMA/8000. I don't know if it's intentional or not.
>>>=20
>> Yes, this was intentional,
>> I used two different ssrc (12345, 67890) in order to
> indicate that I want to establish two audio streams.
>>=20
>> I used ssrc=3D12345 twice in order to give a hint that the
> first audio stream should either use PCMU or PCMA (and ssrc=3D12345).
>> The second audio stream would use ssrc=3D67890 and iLBC.
>=20
> Even without BUNDLE, this is how you would do it if you offer
> multiple streams within a single m- line.
>=20
>> However from your responses I'm not sure if we are on the
> same page with respect to what I want to achieve.
>> Let me tray to clarify.
>>=20
>> My understanding is that
>> - the m=3Danymedia gives a complete description of what is offered,
>> - if the answerer understands m=3Danymedia, it accepts the
> m=3Danymedia line and rejects all other m-lines
>=20
> Correct.
>=20
> (All other m- lines associated with the MMT group, that is)

Of course

>=20
>> - if the answerer understands m=3Danymedia, it can ignore all
> other m-lines in the SDP, it doesn't even have to look at
> them in order to build its answer.
>=20
> Correct.
>=20
> (All other m- lines associated with the MMT group, that is)
Yes, this is more precise again

>=20
>> If this is correct, consider an SDP offer with e.g. 4 m-lines (2
>> audio+2 video)=20
>>=20
>>       v=3D0
>>       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com       s=3D
>>       c=3DIN IP4 host.atlanta.com
>>       t=3D0 0
>>       m=3Daudio 10000 RTP/AVP 0 8
>>       a=3Drtpmap:0 PCMU/8000
>>       a=3Drtpmap:8 PCMA/8000
>>       m=3Daudio 10002 RTP/AVP 97
>>       a=3Drtpmap:97 iLBC/8000
>>       m=3Dvideo 20000 RTP/AVP 31
>>       a=3Drtpmap:31 H261/90000
>>       m=3Dvideo 20002 RTP/AVP 32
>>       a=3Drtpmap:32 MPV/90000
>>=20
>> How would the associated m=3Danymedia line look like in this
> case, such that the answerer can see that 2 audio and 2 video
> streams are offered without having to look into the other m-lines?
>=20
> Note that there are still some details (e.g. whether
> "RTP/AVP" is going to be used) that have to be sorted out,
> but something like this:
>=20
> m=3Danytype 10000 RTP/AVP 0 8 97 31 32
> a=3Dmmtype: 0 audio
> a=3Dmmtype: 8 audio
> a=3Dmmtype: 97 audio
> a=3Dmmtype: 31 video
> a=3Dmmtype: 32 video
> a=3Drtpmap:0 PCMU/8000
> a=3Drtpmap:8 PCMA/8000
> a=3Drtpmap:97 iLBC/8000
> a=3Drtpmap:31 H261/90000
> a=3Drtpmap:32 MPV/90000
>=20
Yes, something like this. But this m=3Danymedia line could also be based on=
:

SDP Offer (1 audio + 1 video)
       v=3D0
       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=3D
       c=3DIN IP4 host.atlanta.com
       t=3D0 0
       m=3Daudio 10000 RTP/AVP 0 8 97
       a=3Drtpmap:0 PCMU/8000
       a=3Drtpmap:8 PCMA/8000
       a=3Drtpmap:97 iLBC/8000
       m=3Dvideo 20000 RTP/AVP 31 32
       a=3Drtpmap:31 H261/90000
       a=3Drtpmap:32 MPV/90000

I think the a=3Danymedia line in the offer needs provide a means to dinstin=
guish this from the case above.


> Then, you will use the SSRC attribute to identify the
> streams. But, we do need to define how to associate SSRCs
> with media types and/or payload types.
>=20

Thanks,=20

once available I'll look into the updated draft on how you intend to solve =
that.

Regards
Thomas

> In one of your e-mails, you suggested to extend the mmtype
> attribute. That's for sure one possibility.
>=20
> Regards,
>=20
> Christer

From christer.holmberg@ericsson.com  Fri Oct 12 05:17:05 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4AC21F8530 for ; Fri, 12 Oct 2012 05:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.928
X-Spam-Level: 
X-Spam-Status: No, score=-4.928 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIpTkCLIUKDt for ; Fri, 12 Oct 2012 05:17:04 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6221F8516 for ; Fri, 12 Oct 2012 05:17:02 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-aa-50780a3d2982
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4C.78.11467.D3A08705; Fri, 12 Oct 2012 14:17:01 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 12 Oct 2012 14:17:01 +0200
From: Christer Holmberg 
To: "Stach, Thomas" , Harald Alvestrand 
Date: Fri, 12 Oct 2012 14:16:58 +0200
Thread-Topic: AW: AW: AW: How does mmt grouping work with multiple streams of the same type?
Thread-Index: AQHNqFXRBmp+pOZsF0CIj8CaYweqY5e1YuGQgAASNECAABkDQIAABiZQ
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF17E@ESESSCMS0356.eemea.ericsson.se>
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>  <5077D873.20103@alvestrand.no>  <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0B9@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvra4tV0WAwYqJVhbH+rrYLPYvPs9s MXX5YxaLXdtrHFg8rky4wuqxZMlPJo8bt98ze7Q9u8MewBLFZZOSmpNZllqkb5fAldFyo67g gXjFm78LWBsY24W6GDk5JARMJD5f/s8MYYtJXLi3nq2LkYtDSOAUo8TjT3vZIZyFjBLTrz1g 7WLk4GATsJDo/qcN0iAikCrxqOcwO4jNLOAqcWLdUyYQm0VAVeL38ddgtrBArMTOtwtYIerj JDZceA82RkTATeLFM2eQMK9AuETL5HlMEKv+s0g839LLBpLgFPCX6F2+E2wOI9Bx30+tYYLY JS5x68l8JoijBSSW7DkP9YCoxMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4WtmiMWCEidn PmGZwCg2C8nYWUhaZiFpmYWkZQEjyypG4dzEzJz0ckO91KLM5OLi/Dy94tRNjMD4Orjlt+4O xlPnRA4xSnOwKInzciXt9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAGHZMfEqAFMvtHV0H Jv/T9nVaq7TpmuXruUEfDY5Pti3wl+N6OPHucoXc2y1MMrtib/ysZ5153F3Xembp42u1C7a+ ETOUWLJ9dvobt/YnHU4v9auWdjm4TAj6sqc/0sanm7+hQHGm8Zv65R8OVJWnFq26FX/iSpLL /61+16TX8H4ouvC0derXw0osxRmJhlrMRcWJAPByg8R9AgAA
Cc: Jonathan Lennox , mmusic WG 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 12:17:05 -0000

Hi,

>>> If this is correct, consider an SDP offer with e.g. 4 m-lines (2
>>> audio+2 video)
>>>=20
>>>       v=3D0
>>>       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com       s=
=3D
>>>       c=3DIN IP4 host.atlanta.com
>>>       t=3D0 0
>>>       m=3Daudio 10000 RTP/AVP 0 8
>>>       a=3Drtpmap:0 PCMU/8000
>>>       a=3Drtpmap:8 PCMA/8000
>>>       m=3Daudio 10002 RTP/AVP 97
>>>       a=3Drtpmap:97 iLBC/8000
>>>       m=3Dvideo 20000 RTP/AVP 31
>>>       a=3Drtpmap:31 H261/90000
>>>       m=3Dvideo 20002 RTP/AVP 32
>>>       a=3Drtpmap:32 MPV/90000
>>>=20
>>> How would the associated m=3Danymedia line look like in this
>> case, such that the answerer can see that 2 audio and 2 video streams=20
>> are offered without having to look into the other m-lines?
>>=20
>> Note that there are still some details (e.g. whether "RTP/AVP" is=20
>> going to be used) that have to be sorted out, but something like this:
>>=20
>> m=3Danytype 10000 RTP/AVP 0 8 97 31 32
>> a=3Dmmtype: 0 audio
>> a=3Dmmtype: 8 audio
>> a=3Dmmtype: 97 audio
>> a=3Dmmtype: 31 video
>> a=3Dmmtype: 32 video
>> a=3Drtpmap:0 PCMU/8000
>> a=3Drtpmap:8 PCMA/8000
>> a=3Drtpmap:97 iLBC/8000
>> a=3Drtpmap:31 H261/90000
>> a=3Drtpmap:32 MPV/90000
>>=20
> Yes, something like this. But this m=3Danymedia line could also be based =
on:
>
> SDP Offer (1 audio + 1 video)
>       v=3D0
>       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com
>       s=3D
>       c=3DIN IP4 host.atlanta.com
>       t=3D0 0
>       m=3Daudio 10000 RTP/AVP 0 8 97
>       a=3Drtpmap:0 PCMU/8000
>       a=3Drtpmap:8 PCMA/8000
>       a=3Drtpmap:97 iLBC/8000
>       m=3Dvideo 20000 RTP/AVP 31 32
>       a=3Drtpmap:31 H261/90000
>       a=3Drtpmap:32 MPV/90000
>
> I think the a=3Danymedia line in the offer needs provide a means to dinst=
inguish this from the case above.

When I look at your two offer examples, I see the following differences:

1. The port numbers. That is obviously nothing you need to distinguish, as =
the same port will be used for everything when using m=3Danytype.

2. RTP sessions. Assuming that each m- line represents an RTP session, and =
you want to keep that within the m=3Danytype description, that is obviously=
 something that needs to be defined. However, the basic assumption in BUNDL=
E is that all multiplexed media belongs to the same RTP sessions, and you'l=
l need some other mechanism/extension (e.g. the SHIM mechanism) in order to=
 use multiple RTP sessions.

Assuming you will use the SSRC attribute to indicate the number of streams,=
 what else do you need to distinguish?

>> Then, you will use the SSRC attribute to identify the streams. But, we=20
>> do need to define how to associate SSRCs with media types and/or=20
>> payload types.
>>=20
>
> Thanks,=20
>
> once available I'll look into the updated draft on how you intend to solv=
e that.

You are very welcome to present ideas on how to solve it :)

Regards,

Christer


From thomas.stach@siemens-enterprise.com  Fri Oct 12 05:35:14 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2721F84F8 for ; Fri, 12 Oct 2012 05:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.249
X-Spam-Level: 
X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=0.750,  BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-6lIcww41yp for ; Fri, 12 Oct 2012 05:35:14 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7425D21F8498 for ; Fri, 12 Oct 2012 05:35:14 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 98BA223F050B; Fri, 12 Oct 2012 14:35:13 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 14:35:13 +0200
From: "Stach, Thomas" 
To: Christer Holmberg , Harald Alvestrand 
Thread-Topic: AW: AW: AW: How does mmt grouping work with multiple streams of the same type?
Thread-Index: AQHNqFXRBmp+pOZsF0CIj8CaYweqY5e1YuGQgAASNECAABkDQIAABiZQgAAGnJA=
Date: Fri, 12 Oct 2012 12:35:12 +0000
Message-ID: 
References:  <5076CC50.7000103@alvestrand.no>  <5076DB5F.5030205@alvestrand.no>  <5076E2AB.2070507@alvestrand.no>  <5077D873.20103@alvestrand.no>  <7F2072F1E0DE894DA4B517B93C6A0585340BDCF0B9@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A0585340BDCF17E@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF17E@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox , mmusic WG 
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the same type?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 12:35:15 -0000

>=20
> Assuming you will use the SSRC attribute to indicate the
> number of streams, what else do you need to distinguish?
With the additional a=3Dssrc attributes it will be sufficient.

Thanks
Thomas=

From christer.holmberg@ericsson.com  Fri Oct 12 05:55:48 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD72621F84F0 for ; Fri, 12 Oct 2012 05:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.118
X-Spam-Level: 
X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=0.131,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf1r-1WyB6Xo for ; Fri, 12 Oct 2012 05:55:47 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 309DC21F84CE for ; Fri, 12 Oct 2012 05:55:47 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-a5-5078134e3ef9
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 29.43.04547.E4318705; Fri, 12 Oct 2012 14:55:42 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 12 Oct 2012 14:55:42 +0200
From: Christer Holmberg 
To: Emil Ivov 
Date: Fri, 12 Oct 2012 14:55:39 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2obD/l5WjDlW9DR/SoPpuN4Wb0DQAAH+HA
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org>
In-Reply-To: <5077FE17.3010800@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvrW6gcEWAwe2v2hZrdk5gsZi6/DGL A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgyjj3gbeg2bZi1p4OtgbGawZdjJwcEgImEj/+ n2aHsMUkLtxbz9bFyMUhJHCKUeLHqelMEM5cRol1++8DZTg42AQsJLr/aYM0iAjIS3S3LWIC sZkFVCT23bvBCGKzCKhKvOzZzQZiCwsoStw6vokNol5J4vnzSawQtpHE0QOHwOK8AuESE1q2 QS2ewCIx8307C8guTgFNicbj/CA1jEDHfT+1BmqXuMStJ/OZII4WkFiy5zwzhC0q8fLxP1aI elGJO+3rGSHqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsopR ODcxMye93EgvtSgzubg4P0+vOHUTIzBuDm75rbqD8c45kUOM0hwsSuK81lv3+AsJpCeWpGan phakFsUXleakFh9iZOLglGpgVC2vU5Pa37GSIzlvtdw7TuVDT4x2HQu7/ubcUVf+HxUve3a+ 6ypYf2/PhvUsM1+ut5lswa0s/sOu/oalI3sp92XvX0lPb1S2ftFYJvBCWWrmhK7benEaP12V /07YZr50U8qe48lRj4SL7+QXKSm2lN7s7UlnyFm0hlXV69lUzyVTtjxMsX16UomlOCPRUIu5 qDgRAPMv1QFpAgAA
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 12:55:48 -0000

Hi,

Q1: Remote endpoint support (SIP):=20
--------------------------------------------
=20
>>>>>> Also, I guess I still haven't completely understood the backward=20
>>>>>> compatibility issue, but I guess I need to do some more reading.
>>>>>=20
>>>>> We describe these in Section 3 but the main problem is that a=20
>>>>> vanilla ICE agent that gets a first subset of candidates (that may=20
>>>>> also be empty) would declare failure prematurely.
>>>>=20
>>>> The text gives an example where the receiver (Bob) receives a=20
>>>> host-candidate-only offer, and start checks which fail.
>>>>=20
>>>> I think it's quite strange if Bob would reject the call at that=20
>>>> point. Because, no matter how many candidates the offer contains,=20
>>>> there might still be peer reflexive candidates created later,
>>>=20
>>> How does Bob know that there's going to be a "later" ? It's just a=20
>>> vanilla ICE agent that assumed it received a full set of candidates,=20
>>> it checked them all, all checks failed.
>>=20
>> Bob knows that there will be STUN requests coming, and based on those=20
>> additional candidates (peer reflexive) might be created.
>
> Chances are that no STUN requests will be arriving unless Bob is also mak=
ing simultaneous checks toward Alice's SR candidates, which he isn't becaus=
e he doesn't have them.

Since Alice supports trickle, we can specify that Alice shall not wait for =
Bob's checks :)

>>> Now, we could rely on Bob not doing anything rash and waiting=20
>>> patiently for reINVITEs from Alice in order to get more candidates=20
>>> ...
>>=20
>> The peer reflexive candidates will not come in a re-INVITE, they will=20
>> be created based on the STUN requests.
>
> That's kind of a corner case. Learning peer-reflexive candidates implies =
that Bob can get Alice's conn checks which would only happen
> if Bob's addresses are directly reachable from Alice (e.g. Bob has a publ=
ic address or a NAT with no endpoint dependent filtering).

I assume that Bob (since he doesn't support trickle) has provided ALL his a=
vailable candidates (server reflexive, relay etc) in the SDP answer.

(Just because Bob only got a host candidate in the offer, it doesn't mean h=
e will only return a host candidate in the answer.)


>> Having said that, I agree that legacy ICE endpoints might not behave=20
>> that way, and reject the call, but then we would simply do a fallback=20
>> to legacy ICE.
>
> The problem is that in this case Bob might have been alerted of the call =
and witnessed the failure, so a fallback to vanilla ICE would not be partic=
ularly smooth.

I think that's an implementation issue, whether Bob is alerted before a wor=
king ICE pair has been found.

>>>> In my opinion, if one has to do something extra (e.g. send OPTIONS),=20
>>>> the whole idea of trickle-ICE goes away, because at the end of the=20
>>>> day you won't save any time in call establishment.
>>>=20
>>> The OPTIONS request does not need to be sent right before the call.
>>> It can be done once, upon bootstrap.
>>=20
>> Yes, but in that case there is an even less chance that the OPTIONS=20
>> and INVITE requests will reach the same remote peer (in case of=20
>> forking).
>
> True. Maybe adding gruu-s into the mix could help ... This would indeed i=
mply that the caller needs prior knowledge of the=20
> callee (e.g. adding them to a contact list) but maybe we can have this an=
d then another solution for the first call/unknown callee case.
>
> I am pretty much out of ideas for the time being anyway, so if you, or an=
yone else, can think of something that would miraculously solve the issue, =
I'd be very happy to hear it.

I think we simply need to accept the fact that the offer may be rejected.

Based on the discussion above, I believe there are cases where things will =
work even if Bob doesn't support trickle, and in other case we'll just have=
 to send a new non-trickle offer.

Of course, people CAN use OPTIONS, or whatever mechanisms they want to figu=
re out before sending the offer, but I don't think we should have that as a=
 SHOULD.

>>>> Now, if the browser is communicating with a ICE terminating gateway,=20
>>>> and if the browser performs SIP registration, then the gateway can=20
>>>> indicate trickle-ICE during registration.
>>>>=20
>>>> But, in the peer-to-peer case I don't know how it would work.
>>>> It's not even sure OPTIONS would reach the same remote peer as the=20
>>>> INVITE...
>>>=20
>>> I agree. Not sure what to say other than, I agree that SIP does not=20
>>> have good mechanisms for XMPP like negotiation of entity caps but,=20
>>> personally, I do believe that finding one would be helpful here.
>>>=20
>>> Maybe we can work on making sure that 3840 (or some other
>>> mechanism) would better allow for caps to be discovered in advance.
>>>=20
>>> At the very least, if we can't find a way to do this gracefully with=20
>>> SIP, we can RECOMMEND it whenever the protocol allows it and try to=20
>>> devise a fall back strategy when it does not (e.g. with SIP).
>>=20
>> There ARE ways to do it, but they all suck :)
>
> Is it realistic to expect that we can improve any of them to do the job?
> Or add a new one?

This is not the first time we realize that it would be good to know what th=
e remote peer supports :)


Q3: Enough is enough:=20
---------------------------
=20
>>>>>>>> I think it could be useful for the answerer to tell the offerer=20
>>>>>>>> that it doesn't want/need any more candidates.
>>>>>>>=20
>>>>>>> Yes, sounds useful. Do you have any specific use cases in mind?
>>>>>>=20
>>>>>> Well, I guess any case where the remote peer knows it has a public
>>>>> IP address (it will most likely be an ICE lite entity).
>>>>>=20
>>>>> Right, but in such cases the offerer would also know that a
>>>>> certain pair has succeeded so if they continue it might be with
>>>>> the purpose of finding a better RTT or a higher priority local
>>>>> candidate.
>>>>>=20
>>>>> I guess what I am trying to say is that a Binding Response is
>>>>> enough of an indication that trickling can stop. If it doesn't
>>>>> then maybe it's for a reason.
>>>>=20
>>>> Maybe it is enough... In any case I think it would be good to
>>>> document :)
>>>=20
>>> OK. Agreed.
>>>=20
>>>> Also, at least in cases where the remote peer only provide a host
>>>>  candidate (because it has a public IP address), one should be
>>>> smart enough to figure out that there most likely will be no
>>>> better alternative.
>>>=20
>>> I am not sure I got this.
>>=20
>> If the remote peer only provides a host candidate, and it works, I
>> think there won't be any better alternatives.
>
> I don't know about that. Well, what if the host candidate is actually an
> IPv6 (or VPN) tunnel with poor latency and bandwidth and the SR
> candidate works better? Or what if it's the address of an 802.11g/b
> interface and the same machine has a NATed Ethernet connection with,
> again, better bandwidth and latency?
>
> All in all, making assumptions on the receiving end is always a risk. If
> the host sending the candidates knows that they are its best/only
> candidates, then it could indicated so by sending the end-of-candidates
> message we describe in the draft.

In case Bob has a public IP address, why does Alice need to send an offer w=
ith the additional candidates in the first place? Why not simply start usin=
g them, and Bob will process them as peer reflexive candidates?

(I can understand that signaling is needed in case per-candidate ufag/pwd v=
alues are used, but let's assume a case where the same values are used for =
all candidates.)

Regards,

Christer

From petithug@acm.org  Fri Oct 12 06:37:32 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B7D21F855F for ; Fri, 12 Oct 2012 06:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.431
X-Spam-Level: 
X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xO6eKjc8WbO for ; Fri, 12 Oct 2012 06:37:31 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9650021F854F for ; Fri, 12 Oct 2012 06:37:31 -0700 (PDT)
Received: from [IPv6:2601:9:4b80:32:9cd4:c894:b643:d270] (unknown [IPv6:2601:9:4b80:32:9cd4:c894:b643:d270]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3EEB0204A4; Fri, 12 Oct 2012 13:37:28 +0000 (UTC)
Message-ID: <50781D16.5050804@acm.org>
Date: Fri, 12 Oct 2012 06:37:26 -0700
From: Marc Petit-Huguenin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120922 Icedove/10.0.7
MIME-Version: 1.0
To: Justin Uberti 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICE tiebreaker - session-level or media-level?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 13:37:32 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/11/2012 11:25 PM, Justin Uberti wrote:
> Reviewing the handling of role conflicts, a question came up: in the event 
> different systems handle different media in a session, do they have to
> share the same ICE tiebreaker?
> 
> Section 5.2 of RFC 5245 indicates that the ICE Agent chooses the
> tiebreaker, indicating that this is a session-level value.
> 
> To resolve this, each agent MUST select a random number, called the
> tie-breaker, uniformly distributed between 0 and (2**64) - 1 (that is, a
> 64-bit positive integer).  This number is used in connectivity checks to
> detect and repair this case, as described in Section 7.1.2.2
> .
> 
> 
> Or am I misreading, and each m= line corresponds to its own ICE Agent, with
> its own tiebreaker value?
> 

Well, it is obvious that ICE was not designed with an Agent per m= line, see
draft-petithuguenin-mmusic-ice-attributes-level.  Work on rfc5245bis will
start after the Atlanta meeting, so this will be a good time to fix this.
Meanwhile, is there any interoperability problem when implementing an ICE
Agent per m= line?

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQeB0UAAoJECnERZXWan7EWIgP/RLC8qLCwh/kDn4qv5URBRuj
Lt8rVosig9UwsizNW/Quex6WwyepE1pM+eewINMK43grfLgYFMc1gcpxFn1RUj/i
sNzaVd5V3kz0s0DKLv7xsnf/bbt/teZPso2SW4yRGum/Z+tDOwA/mQTS4INZhUUe
6Dm5t0zW9K+Z0OIUjTVJKokzUcFy5DUGQHjWfibrOUkzgQ1ZK2fTtx2RQNCLIzFG
VkMwWXMzO60bDCTNGmYbZQWBLNpu2H4Dc0vqBtYydQPDCJh+ReLPJ3MWxzm6DhfG
76EbSfyUBDyJxfsklSJVrFmyCX2wW+YoLiUCt5yk07vJ1nYM3KhGTWvG4EJ4CR5F
lv/9KOKjEIGQCbH8dncChKvcXHRj0hl0yGzdvaDnvPv0RLjmLSHWAc4JyKXOU1/0
bSXYSAHfdpt79GTw2OQe4gM78GPrplTi6J3DfwN28qiKv7cG7CEXagizGTKJIXzU
q7r1YfyCNSimJjaqeJwBH5MGad+BEbmD6g8+HADh/BLJUgmrlC+oOETuPX893Ia3
djONWWFWNGhXIEj7fB5AmRa9ejXcF+RAUmK1pI2rdZQK616IzDYU0cWpc4uLlrJL
i8S7MPXM9ebFKydB6DcEa6B+MtZ/qwBrQxs7JD4P0ZEM0LpCqGVK62JAeHNt6ygy
2ZPwo64WxOHDRUisHgif
=6WhM
-----END PGP SIGNATURE-----

From emil@sip-communicator.org  Fri Oct 12 07:13:32 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688FE21F847C for ; Fri, 12 Oct 2012 07:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdpHt7p6x5vd for ; Fri, 12 Oct 2012 07:13:30 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4EAF21F8471 for ; Fri, 12 Oct 2012 07:13:29 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so1910425wey.31 for ; Fri, 12 Oct 2012 07:13:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=1WlDyM8uEhY5MY1SZV5tjMgjtt8cSrvDmRKfVfZk19U=; b=GTXVWxIVxRtJki8BBoj0p+AW3Mzs7LUIFBbYDVci/1QSq/1w9HaHda2OllHLaRUY2m q6evcyMldTvFHtByLH9EAfiAMpN7st40sVb5agm6D9StlvAzPNQaDOHqwFBxtxdxTJvT D+VY/jOr9aQmpO4wMKfA0CFD37jLkj6a5Ss1OmRd18Zqnzr5U4yDtPCJRN5HmOfg992A b49xJ1FqYLlLvM3V7HBrolsafDWsePFprIh5JcR2POQ5RwrUkeYn3UFTB4Aw2UC20dBD rPktmvc6INOBhrXqHG/AGIQ3MyOI52IIc0ktamkThDUEa1vK13smaHW9OnL4G2tke5kl jS6Q==
Received: by 10.180.100.101 with SMTP id ex5mr6442483wib.16.1350051209252; Fri, 12 Oct 2012 07:13:29 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:bd77:1144:898a:47b]) by mx.google.com with ESMTPS id ct3sm3394885wib.5.2012.10.12.07.13.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 07:13:28 -0700 (PDT)
Message-ID: <50782585.9070204@jitsi.org>
Date: Fri, 12 Oct 2012 16:13:25 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQn4UsIFZ4rEf8VwQX+PUcpvX71n6QP+swBNV4XX2pKtPPgzmpek00oSWdkKOli2BH6cL3pd
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 14:13:32 -0000

Hey Christer,

On 12.10.12, 14:55, Christer Holmberg wrote:
> Hi,
> 
> Q1: Remote endpoint support (SIP): 
> --------------------------------------------
> 
>>>>>>> Also, I guess I still haven't completely understood the
>>>>>>> backward compatibility issue, but I guess I need to do
>>>>>>> some more reading.
>>>>>> 
>>>>>> We describe these in Section 3 but the main problem is that
>>>>>> a vanilla ICE agent that gets a first subset of candidates
>>>>>> (that may also be empty) would declare failure
>>>>>> prematurely.
>>>>> 
>>>>> The text gives an example where the receiver (Bob) receives a
>>>>>  host-candidate-only offer, and start checks which fail.
>>>>> 
>>>>> I think it's quite strange if Bob would reject the call at
>>>>> that point. Because, no matter how many candidates the offer
>>>>> contains, there might still be peer reflexive candidates
>>>>> created later,
>>>> 
>>>> How does Bob know that there's going to be a "later" ? It's
>>>> just a vanilla ICE agent that assumed it received a full set of
>>>> candidates, it checked them all, all checks failed.
>>> 
>>> Bob knows that there will be STUN requests coming, and based on
>>> those additional candidates (peer reflexive) might be created.
>> 
>> Chances are that no STUN requests will be arriving unless Bob is
>> also making simultaneous checks toward Alice's SR candidates, which
>> he isn't because he doesn't have them.
> 
> Since Alice supports trickle, we can specify that Alice shall not
> wait for Bob's checks :)

It's Bob that I was worrying about. As soon as all his checks fail
(which can happen quite quickly if a similar host address also exists in
Bob's network and returns ICMP unreachable), all his check lists will be
in the failed state, and then its entire ICE processing will hence also
move to failed.

The whole thing may even fail before that. Bob would probably reject the
offer outright if it didn't contain any candidates. He may also do the
same if it only has IPv6 candidates while Bob is an IPv4 only host.

I am sure that one can also find other cases where lack of connectivity
can be precluded before actually running the checks and in all of them
it is entirely possible that Bob won't even send his candidates.

>>>> Now, we could rely on Bob not doing anything rash and waiting 
>>>> patiently for reINVITEs from Alice in order to get more
>>>> candidates ...
>>> 
>>> The peer reflexive candidates will not come in a re-INVITE, they
>>> will be created based on the STUN requests.
>> 
>> That's kind of a corner case. Learning peer-reflexive candidates
>> implies that Bob can get Alice's conn checks which would only
>> happen if Bob's addresses are directly reachable from Alice (e.g.
>> Bob has a public address or a NAT with no endpoint dependent
>> filtering).
> 
> I assume that Bob (since he doesn't support trickle) has provided ALL
> his available candidates (server reflexive, relay etc) in the SDP
> answer.
> 
> (Just because Bob only got a host candidate in the offer, it doesn't
> mean he will only return a host candidate in the answer.)

Yes of course, however I don't think this would help in the cases I
describe above. In all of them Bob can still prematurely fail the session.

And yes, 5245 does say that the controlling agent should terminate the
session when ICE processing fails, which may partially alleviate the
first case above although I am not sure all ICE implementations would
behave properly and accept new candidates once all their check lists
have moved into failed.

Even if they did, it still wouldn't help with the other two cases (i.e.
no candidates, or different address families) where lack of connectivity
can be determined without any checks at all.

>>> Having said that, I agree that legacy ICE endpoints might not
>>> behave that way, and reject the call, but then we would simply do
>>> a fallback to legacy ICE.
>> 
>> The problem is that in this case Bob might have been alerted of the
>> call and witnessed the failure, so a fallback to vanilla ICE would
>> not be particularly smooth.
> 
> I think that's an implementation issue, whether Bob is alerted before
> a working ICE pair has been found.

True. Still, 5245 allows for it and people have argued it has sometimes
been presented as a protection of privacy: I won't advertise any of my
user's addresses before I am sure my user actually wants to talk to the
caller. I believe one of the Jingle XEPs have a similar statement.

>>>>> In my opinion, if one has to do something extra (e.g. send
>>>>> OPTIONS), the whole idea of trickle-ICE goes away, because at
>>>>> the end of the day you won't save any time in call
>>>>> establishment.
>>>> 
>>>> The OPTIONS request does not need to be sent right before the
>>>> call. It can be done once, upon bootstrap.
>>> 
>>> Yes, but in that case there is an even less chance that the
>>> OPTIONS and INVITE requests will reach the same remote peer (in
>>> case of forking).
>> 
>> True. Maybe adding gruu-s into the mix could help ... This would
>> indeed imply that the caller needs prior knowledge of the callee
>> (e.g. adding them to a contact list) but maybe we can have this and
>> then another solution for the first call/unknown callee case.
>> 
>> I am pretty much out of ideas for the time being anyway, so if you,
>> or anyone else, can think of something that would miraculously
>> solve the issue, I'd be very happy to hear it.
> 
> I think we simply need to accept the fact that the offer may be
> rejected.

Personally, I am OK with this, especially as far as SIP is concerned
(given the deficiencies in the caps neg support). However if we go for
this it may be best to agree exactly how things should fail so that:

1 - time is not wasted
2 - reasons for the failure are easily related to non-support of trickle ICE
3 - failures happen in a predictable way
4 - users are not bothered with them

> Based on the discussion above, I believe there are cases where things
> will work even if Bob doesn't support trickle, and in other case
> we'll just have to send a new non-trickle offer.

Supporting non-trickle is definitely a MUST for whoever cares for
interop. I agree with this.

> Of course, people CAN use OPTIONS, or whatever mechanisms they want
> to figure out before sending the offer, but I don't think we should
> have that as a SHOULD.

OK, I can agree with making the "check support in advance" a MAY.
However defining a try and fallback procedure for usages (including SIP)
seems quite important to me.

>>>>> Now, if the browser is communicating with a ICE terminating
>>>>> gateway, and if the browser performs SIP registration, then
>>>>> the gateway can indicate trickle-ICE during registration.
>>>>> 
>>>>> But, in the peer-to-peer case I don't know how it would
>>>>> work. It's not even sure OPTIONS would reach the same remote
>>>>> peer as the INVITE...
>>>> 
>>>> I agree. Not sure what to say other than, I agree that SIP does
>>>> not have good mechanisms for XMPP like negotiation of entity
>>>> caps but, personally, I do believe that finding one would be
>>>> helpful here.
>>>> 
>>>> Maybe we can work on making sure that 3840 (or some other 
>>>> mechanism) would better allow for caps to be discovered in
>>>> advance.
>>>> 
>>>> At the very least, if we can't find a way to do this gracefully
>>>> with SIP, we can RECOMMEND it whenever the protocol allows it
>>>> and try to devise a fall back strategy when it does not (e.g.
>>>> with SIP).
>>> 
>>> There ARE ways to do it, but they all suck :)
>> 
>> Is it realistic to expect that we can improve any of them to do the
>> job? Or add a new one?
> 
> This is not the first time we realize that it would be good to know
> what the remote peer supports :)
> 
> 
> Q3: Enough is enough: ---------------------------
> 
>>>>>>>>> I think it could be useful for the answerer to tell
>>>>>>>>> the offerer that it doesn't want/need any more
>>>>>>>>> candidates.
>>>>>>>> 
>>>>>>>> Yes, sounds useful. Do you have any specific use cases
>>>>>>>> in mind?
>>>>>>> 
>>>>>>> Well, I guess any case where the remote peer knows it has
>>>>>>> a public
>>>>>> IP address (it will most likely be an ICE lite entity).
>>>>>> 
>>>>>> Right, but in such cases the offerer would also know that
>>>>>> a certain pair has succeeded so if they continue it might
>>>>>> be with the purpose of finding a better RTT or a higher
>>>>>> priority local candidate.
>>>>>> 
>>>>>> I guess what I am trying to say is that a Binding Response
>>>>>> is enough of an indication that trickling can stop. If it
>>>>>> doesn't then maybe it's for a reason.
>>>>> 
>>>>> Maybe it is enough... In any case I think it would be good
>>>>> to document :)
>>>> 
>>>> OK. Agreed.
>>>> 
>>>>> Also, at least in cases where the remote peer only provide a
>>>>> host candidate (because it has a public IP address), one
>>>>> should be smart enough to figure out that there most likely
>>>>> will be no better alternative.
>>>> 
>>>> I am not sure I got this.
>>> 
>>> If the remote peer only provides a host candidate, and it works,
>>> I think there won't be any better alternatives.
>> 
>> I don't know about that. Well, what if the host candidate is
>> actually an IPv6 (or VPN) tunnel with poor latency and bandwidth
>> and the SR candidate works better? Or what if it's the address of
>> an 802.11g/b interface and the same machine has a NATed Ethernet
>> connection with, again, better bandwidth and latency?
>> 
>> All in all, making assumptions on the receiving end is always a
>> risk. If the host sending the candidates knows that they are its
>> best/only candidates, then it could indicated so by sending the
>> end-of-candidates message we describe in the draft.
> 
> In case Bob has a public IP address, why does Alice need to send an
> offer with the additional candidates in the first place? Why not
> simply start using them, and Bob will process them as peer reflexive
> candidates?
> 
> (I can understand that signaling is needed in case per-candidate
> ufag/pwd values are used, but let's assume a case where the same
> values are used for all candidates.)

My point was that Bobs IP address being public:

* does not mean it is the best option: VPN, tunnelling, and multiple
interfaces can all generate public host IP addresses that are a lot less
preferable to server reflexive ones.
* does not even guarantee that it's reachable. Connectivity may be
administratively prohibited, routes can be down.


Cheers,
Emil

-- 
https://jitsi.org

From miguel.a.garcia@ericsson.com  Fri Oct 12 08:43:36 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375D121F866C for ; Fri, 12 Oct 2012 08:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Level: 
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mVnudsFGUcD for ; Fri, 12 Oct 2012 08:43:35 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 576D921F8668 for ; Fri, 12 Oct 2012 08:43:35 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-fc-50783aa60db9
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EF.D2.11467.6AA38705; Fri, 12 Oct 2012 17:43:34 +0200 (CEST)
Received: from [159.107.48.11] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012 17:43:33 +0200
Message-ID: <50783AA4.9040007@ericsson.com>
Date: Fri, 12 Oct 2012 17:43:32 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvre4yq4oAg6at/BbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgynj29wNTwWXWitOd/9kbGHexdDFyckgImEjs n3eMCcIWk7hwbz1bFyMXh5DAKUaJ+cfWsUA4qxklbnZ/ZwSp4hXQlmi/vQXMZhFQlfi7chtY N5uAuUTrxo3sXYwcHKICwRJdh8UgygUlTs58ArZMREBGYu+mzcwgNjPQmNl3ZjGBlAsLKEn8 +l8BEbaVuDDnOguELS+x/e0csHIhAU2JyTeXMk9g5J+FZOosJC2zkLQsYGRexSicm5iZk15u qJdalJlcXJyfp1ecuokRGHYHt/zW3cF46pzIIUZpDhYlcV6upP3+QgLpiSWp2ampBalF8UWl OanFhxiZODilGhjdzoXnu6sEKwu4GV6a9FybY8vOkD8ePsxMKwv89s9eesCbRTtglfGRZcGz boXkR1TeZjobyRbpeWWRYcvTD5WbEgzWKKc3da7csY+jYucSpZkpJrlpYe3XHJ4/NLncJy3A WKhy2Wnp62cm+6ZZX9bsOKg3le3PjeSnqk5GHD+9I32eGbtHT1BiKc5INNRiLipOBACxJgd7 CQIAAA==
Cc: Flemming Andreasen 
Subject: [MMUSIC] MMUSIC milestones updated
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 15:43:36 -0000

We have got our milestones updated. A few dates have been updated, and we 
got new milestones for:

- SDP extensions for duplicated streams
- SDP considerations for G.723 Annex A and G.729 Annex B
- current practices in hosted NAT traversal
- a revision of ICE

This is not the full picture yet, we are discussing with our ADs more 
changes to the milestones. But in order to allow a few drafts to be 
submitted as WG items (-00) before the Monday 15th deadline, we wanted to 
push this update.

We have also requested the Secretariat to remove all those milestones 
listed as "Done" in our charter page. They are really ancient milestones.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From internet-drafts@ietf.org  Fri Oct 12 08:44:50 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B1321F86EC; Fri, 12 Oct 2012 08:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.506
X-Spam-Level: 
X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZbRIlHOj2LO; Fri, 12 Oct 2012 08:44:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FF721F8699; Fri, 12 Oct 2012 08:44:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121012154449.17065.77484.idtracker@ietfa.amsl.com>
Date: Fri, 12 Oct 2012 08:44:49 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-duplication-grouping-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 15:44:51 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Duplication Grouping Semantics in the Session Descriptio=
n Protocol
	Author(s)       : Ali Begen
                          Yiqun Cai
                          Heidi Ou
	Filename        : draft-ietf-mmusic-duplication-grouping-00.txt
	Pages           : 10
	Date            : 2012-10-03

Abstract:
   Packet loss is undesirable for real-time multimedia sessions, but can
   occur due to congestion, or other unplanned network outages.  This is
   especially true for IP multicast networks, where packet loss patterns
   can vary greatly between receivers.  One technique that can be used
   to recover from packet loss without incurring unbounded delay for all
   the receivers is to duplicate the packets and send them in separate
   redundant streams.  This document defines the semantics for grouping
   redundant streams in the Session Description Protocol (SDP).  The
   semantics defined in this document are to be used with the SDP
   Grouping Framework [RFC5888].  SSRC-level (Synchronization Source)
   grouping semantics are also defined in this document for RTP streams
   using SSRC multiplexing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-grouping

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-duplication-grouping-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Fri Oct 12 08:45:32 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34BF21F8702; Fri, 12 Oct 2012 08:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.506
X-Spam-Level: 
X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v04ei1GlWUbE; Fri, 12 Oct 2012 08:45:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C02D21F86EF; Fri, 12 Oct 2012 08:45:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121012154532.7586.15817.idtracker@ietfa.amsl.com>
Date: Fri, 12 Oct 2012 08:45:32 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-delayed-duplication-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 15:45:32 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Delayed Duplication Attribute in the Session Description=
 Protocol
	Author(s)       : Ali Begen
                          Yiqun Cai
                          Heidi Ou
	Filename        : draft-ietf-mmusic-delayed-duplication-00.txt
	Pages           : 9
	Date            : 2012-10-03

Abstract:
   A straightforward approach to provide protection against packet
   losses due to network outages with a longest duration of T time units
   is to simply duplicate the original packets and send each copy
   separated in time by at least T time units.  This approach is
   commonly referred to as Time-shifted Redundancy, Temporal Redundancy
   or simply Delayed Duplication.  This document defines an attribute to
   indicate the presence of temporally redundant media streams and the
   duplication delay in the Session Description Protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-delayed-duplication-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From miguel.a.garcia@ericsson.com  Fri Oct 12 09:26:38 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590AA21F873C for ; Fri, 12 Oct 2012 09:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Level: 
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.007,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXleeWQIdTvz for ; Fri, 12 Oct 2012 09:26:37 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 31AE321F8739 for ; Fri, 12 Oct 2012 09:26:37 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-fd-507844bbb397
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DB.97.17130.BB448705; Fri, 12 Oct 2012 18:26:36 +0200 (CEST)
Received: from [159.107.48.11] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 12 Oct 2012 18:26:36 +0200
Message-ID: <507844BA.6020900@ericsson.com>
Date: Fri, 12 Oct 2012 18:26:34 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvre4el4oAg/n9jBbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyjizX6dgLkvF6f07GBsYVzF3MXJySAiYSPQf /cAEYYtJXLi3nq2LkYtDSOAUo8T8SzsZIZzVjBIzZ51nB6niFdCWuNlxiwXEZhFQlVh1dC8b iM0mYC7RunEjUA0Hh6hAsETXYTGIckGJkzOfgJWLCMhI7N20GWwxM9CY2XdmgS0WFlCRuDev gQUibitxYc51KFteYvvbOWD1QgKaEpNvLmWewMg/C8nYWUhaZiFpWcDIvIpRODcxMye93Fwv tSgzubg4P0+vOHUTIzDsDm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwGp1Lm1w1R66c/7Yor91+zYJfYe5eyTu/mfmGZs28+fT5q+srfnc3uey8Vv7A wFjn4G4Z2+3q1yKy9qfreFosnDlXavfN5pCff1j8eW9k1jEtMa2pv1UrI7Fmp8hT4TX3C/uL RVx9Nz/R+cRlGnki+7PLi8LVF6u/ny6Iu1dYmJDtxbrw8tHlSizFGYmGWsxFxYkAHGo2KAkC AAA=
Cc: Flemming Andreasen 
Subject: [MMUSIC] Agenda requests for IETF 85
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 16:26:38 -0000

MMUSIC is scheduled to meet for 2.5 hours on Tuesday November 5 at IETF 
85 in Atlanta, GA.

If you want to request a time slot to discuss a draft, please send an
e-mail to Flemming and myself.

As usually, we want to remind you that we should smartly use our
meeting time. In principle, the meeting time should be use to discuss
open issues. We give priority to drafts that gather attention and
discussion in the mailing list prior to the meeting.

-- Miguel and Flemming
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From martin.thomson@gmail.com  Fri Oct 12 09:55:17 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BD021F873C for ; Fri, 12 Oct 2012 09:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.846
X-Spam-Level: 
X-Spam-Status: No, score=-3.846 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efjqXUhlJ106 for ; Fri, 12 Oct 2012 09:55:16 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64C6221F871A for ; Fri, 12 Oct 2012 09:55:09 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so2450093lbo.31 for ; Fri, 12 Oct 2012 09:55:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=POjKUEaPukAxlE019xion2CrIf7lfLUCI/Bb+VxzPxs=; b=K752jcXHTlH8UHq3BbqvvUlPhYyLK5M2LNgWytdzEFptJFU1/hC/TLvIH3dCiAM6qD rOb1X7ZFM/bQhTd3Ygy+yvdgRl3caJzwgNBlPch/4i0iODBnj5vFpm0OzoffS10jDCs/ UwZxdn/36yrABv65WTD+vUcDG4b9CEagz+pXrK59DVeKNr0p4uet+hbpi5JHZbV5BzrC PXwqDunumyOcK41kLF4Aw8gGrF3E6x5qO0yM6p4+7BqZQcCZpNZCWPGpG4ghmvdAfrbn mslEQ7N3Qd1pUnxQ9nqFnd8MEOJPOO71sWzr48v3W+aeU8Cg0XbYNx/D/omFVu1AAHMi rqoQ==
MIME-Version: 1.0
Received: by 10.152.105.135 with SMTP id gm7mr4493042lab.22.1350060908217; Fri, 12 Oct 2012 09:55:08 -0700 (PDT)
Received: by 10.112.83.2 with HTTP; Fri, 12 Oct 2012 09:55:08 -0700 (PDT)
In-Reply-To: <50773B68.10707@jitsi.org>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org>  <5075FAC3.20709@jitsi.org>  <50773B68.10707@jitsi.org>
Date: Fri, 12 Oct 2012 09:55:08 -0700
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 16:55:17 -0000

Emil,

On 11 October 2012 14:34, Emil Ivov  wrote:
>> Actually, this part in Section 9 wasn't very clear.
>
> Sorry about that. We'll try to add clarifications before the 01 deadline.

Actually, I think that we've just uncovered a case of talking past
each other.  I was talking about the inter-component interactions and
you were talking about the interactions intra-component.

It's seems obvious to me now that there needs to be more certainty
about the interactions on both axes.

There are clearly interactions on the one component, but I'm not sure
that the conclusions that you have drawn are necessarily optimal.
When you make the choice to cancel an outstanding transaction, you
don't do anything other than increase the probability of success.  The
Binding requests from the lower priority pair have gone out and may
still succeed, assuming of course that both peers are opening
pinholes.

Cancelling the transaction at this point seems counterproductive.
Instead, adding the new pair to the check list such that a transaction
is created in response to the next ordinary check timer pop ensures
that checks proceed on the new pair as soon as is reasonable, while
allowing the lower priority pair to move to the Failed or Succeeded
state normally.

This may result in a lower priority pair reaching Succeeded before the
higher priority one, but that was an inevitable consequence of the
sequencing anyhow.

>> You can't send an offer sans candidates and expect it to work.
>
> Indeed not. I would expect it to fail for non-trickle agents (without
> alerting the remote user) which would then be my cue to fallback to
> vanilla ICE.

That's an interesting choice.  I tend to prefer don't-even-try
solutions to try-fail-and-fallback ones if at all possible.  They tend
to be more robust because your legacy peer doesn't get in a messed up
state due to the failure.

>> Note: we probably also need to note that a transaction can succeed for
>> a Frozen candidate pair (due to the fact that you can't take a STUN
>> packet back, so "cancelling" a transaction might still result in a
>> successful Binding response.  I don't know what you would do with
>> this, but I'd just move the pair to Succeeded.
>
> The case where a cancelled transaction ends up succeeding is indeed
> worth covering, but given how the concept is defined in 5245 then maybe
> at least part of the coverage should go in 5245bis?

5245 doesn't really have the concept of re-freezing a pair, does it?
(Again, this was related to my comments on inter-component checking,
it might not be relevant ultimately.)

Cheers,
Martin

From martin.thomson@gmail.com  Fri Oct 12 09:57:52 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48DB21F871C for ; Fri, 12 Oct 2012 09:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.841
X-Spam-Level: 
X-Spam-Status: No, score=-3.841 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nAxAXozpoiM for ; Fri, 12 Oct 2012 09:57:52 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0015021F871A for ; Fri, 12 Oct 2012 09:57:51 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so2451759lbo.31 for ; Fri, 12 Oct 2012 09:57:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=21LYODuy4cBNmJ7cYWM69OYQJ++eNd/fh41go3Y8A+g=; b=OVA9FC47atwoyE+FiShqOme1k+wq8mJPHf2S+bu6baeVTFwjGxkrsAllZtnO7lBTSb eo8acr2AJmuAGXiwoC++kDsAnU/md72GzwZTFzN/xMXIr9Nz27ajpw2pD6T3VNsmolBv ZKzlRgOSIZs8XJbenmbpqmDhLkf5gBtsWkwNOOEt/BsHXmskYSddodc1GmypJ0erxM+1 /Ypvk2REgsClQrD2xDxeUXxacF/YAvhW58TmsQMCVq+AVg7KIMHQmGFBSkV+FI7fWJOr A4qYRLmNpe9M+K+Z948NQIUjqVgzeUZzkGJF2kcjrLNyHi9jwhqS8DLHmSj81zjTGyZf MByg==
MIME-Version: 1.0
Received: by 10.112.28.169 with SMTP id c9mr919063lbh.59.1350061070987; Fri, 12 Oct 2012 09:57:50 -0700 (PDT)
Received: by 10.112.83.2 with HTTP; Fri, 12 Oct 2012 09:57:50 -0700 (PDT)
In-Reply-To: <50782585.9070204@jitsi.org>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se> <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se> <50782585.9070204@jitsi.org>
Date: Fri, 12 Oct 2012 09:57:50 -0700
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Cc: MMUSIC IETF WG , Christer Holmberg 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 16:57:52 -0000

On 12 October 2012 07:13, Emil Ivov  wrote:
>> (Just because Bob only got a host candidate in the offer, it doesn't
>> mean he will only return a host candidate in the answer.)
>
> Yes of course, however I don't think this would help in the cases I
> describe above. In all of them Bob can still prematurely fail the session.

Well, spending the time to gather some server reflexive candidates
will at least turn it into a race between Alice's server reflexive
candidates and Bob's arriving.  I'd put that race down as a dead heat,
probability-wise.

From christer.holmberg@ericsson.com  Fri Oct 12 11:04:26 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7B921F873B for ; Fri, 12 Oct 2012 11:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.119
X-Spam-Level: 
X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlIOHvfUrWkJ for ; Fri, 12 Oct 2012 11:04:25 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B7B0621F852E for ; Fri, 12 Oct 2012 11:04:03 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-27-50785b92cb12
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6D.3E.17130.29B58705; Fri, 12 Oct 2012 20:04:02 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 12 Oct 2012 20:04:02 +0200
From: Christer Holmberg 
To: Emil Ivov 
Date: Fri, 12 Oct 2012 20:04:01 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2og8EmYe1agrGnQLKee3puxBfKfAAHcngj
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA87@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>, <50782585.9070204@jitsi.org>
In-Reply-To: <50782585.9070204@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre6k6IoAgwvz1C3W7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlbHy4DPWgpm2FYde72dvYDxp0MXIySEhYCLR fHAyI4QtJnHh3nq2LkYuDiGBU4wSm6YuZYdwFjJKnF+9CqiKg4NNwEKi+582SIOIgLxEd9si JhCbWUBFYt+9G2AlLAKqEqeWhYCEhQUUJW4d38QGUa4k8fz5JFYI20ji37+VYHFegXCJX2cu sECs+s0i8e1CPztIglNAU+Lv/ktg8xmBjvt+ag3ULnGJW0/mM0EcLSCxZM95ZghbVOLl43+s EPWiEnfa1zNC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUV o3BuYmZOerm5XmpRZnJxcX6eXnHqJkZg5Bzc8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYNwXe094d8Q5lUlNH/brpf0uKzk4W7hsQu/FZYuTrQ78mZ9W +2XL41YRX/EMWYlsv84ONcMVyj+K9859vPP9cqlzri63r265O4vTM+N/Wlra/usVbsrvm3a+ O7LMdt8v8XlhbQkGXr4L+jpSA/Y8VjvuIKg7sePx/yCT5B92jvzqZ50n72bccEiJpTgj0VCL uag4EQCI4t/ragIAAA==
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 18:04:26 -0000

Hi,

Q1: Remote endpoint support (SIP):
-------------------------------------

>>>>>>>> Also, I guess I still haven't completely understood the
>>>>>>>> backward compatibility issue, but I guess I need to do
>>>>>>>> some more reading.
>>>>>>>
>>>>>>> We describe these in Section 3 but the main problem is that
>>>>>>> a vanilla ICE agent that gets a first subset of candidates
>>>>>>> (that may also be empty) would declare failure
>>>>>>> prematurely.
>>>>>>
>>>>>> The text gives an example where the receiver (Bob) receives a
>>>>>>  host-candidate-only offer, and start checks which fail.
>>>>>>
>>>>>> I think it's quite strange if Bob would reject the call at
>>>>>> that point. Because, no matter how many candidates the offer
>>>>>> contains, there might still be peer reflexive candidates
>>>>>> created later,
>>>>>
>>>>> How does Bob know that there's going to be a "later" ? It's
>>>>> just a vanilla ICE agent that assumed it received a full set of
>>>>> candidates, it checked them all, all checks failed.
>>>>
>>>> Bob knows that there will be STUN requests coming, and based on
>>>> those additional candidates (peer reflexive) might be created.
>>>
>>> Chances are that no STUN requests will be arriving unless Bob is
>>> also making simultaneous checks toward Alice's SR candidates, which
>>> he isn't because he doesn't have them.
>>
>> Since Alice supports trickle, we can specify that Alice shall not
>> wait for Bob's checks :)
>
> It's Bob that I was worrying about. As soon as all his checks fail
> (which can happen quite quickly if a similar host address also exists in
> Bob's network and returns ICMP unreachable), all his check lists will be
> in the failed state, and then its entire ICE processing will hence also
> move to failed.

Correct.

But, my point is that Bob might get additional candidates (peer reflexive o=
nes) once he gets the STUN checks from Alice, so if he is smart he will wai=
t for those before he declares failure :)

But, again, I agree that Bob may not do that, and will declare failure as s=
oon as the host candidate present in the offer fails.

> The whole thing may even fail before that. Bob would probably reject the
> offer outright if it didn't contain any candidates. He may also do the
> same if it only has IPv6 candidates while Bob is an IPv4 only host.
>
> I am sure that one can also find other cases where lack of connectivity
> can be precluded before actually running the checks and in all of them
> it is entirely possible that Bob won't even send his candidates.

I don't disagree. Without doubt there will be cases where Bob will reject t=
he offer "too early" :)

> And yes, 5245 does say that the controlling agent should terminate the
> session when ICE processing fails, which may partially alleviate the
> first case above although I am not sure all ICE implementations would
> behave properly and accept new candidates once all their check lists
> have moved into failed.

My dream and vision is that they don't move to fail until they have receive=
d a STUN check, in case it will create additional candidates :)

> Even if they did, it still wouldn't help with the other two cases (i.e.
> no candidates, or different address families) where lack of connectivity
> can be determined without any checks at all.

Sure.

(Of course, if Alice is dual stack, she can provide both IPv4 and v6 host c=
andidates in the offer)


>>>> Having said that, I agree that legacy ICE endpoints might not
>>>> behave that way, and reject the call, but then we would simply do
>>>> a fallback to legacy ICE.
>>>
>>> The problem is that in this case Bob might have been alerted of the
>>> call and witnessed the failure, so a fallback to vanilla ICE would
>>> not be particularly smooth.
>>
>> I think that's an implementation issue, whether Bob is alerted before
>> a working ICE pair has been found.
>
> True. Still, 5245 allows for it and people have argued it has sometimes
> been presented as a protection of privacy: I won't advertise any of my
> user's addresses before I am sure my user actually wants to talk to the
> caller. I believe one of the Jingle XEPs have a similar statement.

It may happen, yes. But, even if the user is alerted, keep in mind that Ali=
ce may
also terminate the call establishment.


>>>>>> In my opinion, if one has to do something extra (e.g. send
>>>>>> OPTIONS), the whole idea of trickle-ICE goes away, because at
>>>>>> the end of the day you won't save any time in call
>>>>>> establishment.
>>>>>
>>>>> The OPTIONS request does not need to be sent right before the
>>>>> call. It can be done once, upon bootstrap.
>>>>
>>>> Yes, but in that case there is an even less chance that the
>>>> OPTIONS and INVITE requests will reach the same remote peer (in
>>>> case of forking).
>>>
>>> True. Maybe adding gruu-s into the mix could help ... This would
>>> indeed imply that the caller needs prior knowledge of the callee
>>> (e.g. adding them to a contact list) but maybe we can have this and
>>> then another solution for the first call/unknown callee case.
>>>
>>> I am pretty much out of ideas for the time being anyway, so if you,
>>> or anyone else, can think of something that would miraculously
>>> solve the issue, I'd be very happy to hear it.
>>
>> I think we simply need to accept the fact that the offer may be
>> rejected.
>
> Personally, I am OK with this, especially as far as SIP is concerned
> (given the deficiencies in the caps neg support). However if we go for
> this it may be best to agree exactly how things should fail so that:
>
> 1 - time is not wasted
> 2 - reasons for the failure are easily related to non-support of trickle =
ICE
> 3 - failures happen in a predictable way
> 4 - users are not bothered with them

I agree we should have text about it.

And, I have no problem to give examples on how all this can be avoided. It'=
s the "SHOULD use them" that is my main issue :)

>> Of course, people CAN use OPTIONS, or whatever mechanisms they want
>> to figure out before sending the offer, but I don't think we should
>> have that as a SHOULD.
>
> OK, I can agree with making the "check support in advance" a MAY.
> However defining a try and fallback procedure for usages (including SIP)
> seems quite important to me.

I agree.

Q3: Enough is enough:=20
----------------------

>>> All in all, making assumptions on the receiving end is always a
>>> risk. If the host sending the candidates knows that they are its
>>> best/only candidates, then it could indicated so by sending the
>>> end-of-candidates message we describe in the draft.
>>
>> In case Bob has a public IP address, why does Alice need to send an
>> offer with the additional candidates in the first place? Why not
>> simply start using them, and Bob will process them as peer reflexive
>> candidates?
>>
>> (I can understand that signaling is needed in case per-candidate
>> ufag/pwd values are used, but let's assume a case where the same
>> values are used for all candidates.)
>
> My point was that Bobs IP address being public:
>
> * does not mean it is the best option: VPN, tunnelling, and multiple
> interfaces can all generate public host IP addresses that are a lot less
> preferable to server reflexive ones.
> * does not even guarantee that it's reachable. Connectivity may be
> administratively prohibited, routes can be down.

Alice CAN continue to gather candidates, in case there are better ones. My =
question was why she needs to signal them to Bob in a new offer, instead of=
 simply start sending STUN checks associated with the candidates? Bob will =
then process them as peer reflexive candidates.

Regards,

Christer=

From emil@sip-communicator.org  Fri Oct 12 11:16:47 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC621F87BD for ; Fri, 12 Oct 2012 11:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPqcQrGSCKEF for ; Fri, 12 Oct 2012 11:16:47 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0AA421F87BA for ; Fri, 12 Oct 2012 11:16:46 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so2048831wey.31 for ; Fri, 12 Oct 2012 11:16:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=rWR4MpcvoqU7Z4ct1KDx+R9C9etNskEpXkWIDgpJuYo=; b=Z+37lAPubYUGxTjnKKfp5e09H2VL8SxcRnNcWXkKjPsbjgOwW0ePXA6HPEPesyc6kp 3TCmPbmIX9uHwiGHlXzWtVtWi8smkF+k5b1hEztltoPJt0pvWJXeUtP1QNopIiNaPz5N 3spNPHsMoTjdbEEG3FSQs08hhvTe496+W3RA8D4aUclh9+BRU7jcEKKVk0eWi1uKqPDH PISp36IWLMPGHEY7/PO9G3f8YneThimWZYAlTF7Vap9rlReIhxAZVBcMSzImKLlDbvyT OnBj8N4oxlJFWSTPhe7hyOCkZB6kx4RLW5zFijR9xaoWZbRQbrxvMzIA3+YSdGWol4mH nHwA==
Received: by 10.180.87.42 with SMTP id u10mr7908689wiz.0.1350065805796; Fri, 12 Oct 2012 11:16:45 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:5c2a:e2a8:a4af:298b]) by mx.google.com with ESMTPS id w8sm4368904wif.4.2012.10.12.11.16.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 11:16:45 -0700 (PDT)
Message-ID: <50785E8A.7080903@jitsi.org>
Date: Fri, 12 Oct 2012 20:16:42 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>, <50782585.9070204@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA87@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA87@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkwKWLe5Ws3yMOtJw/VXx1nNEZoyH3hCsKOiNi066S2YEtGTn0/prU5IGj0P4iz7xrdM+qL
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 18:16:47 -0000

Hey Christer,

(one minor comment)

On 12.10.12, 20:04, Christer Holmberg wrote:
>>>> All in all, making assumptions on the receiving end is always a
>>>> risk. If the host sending the candidates knows that they are its
>>>> best/only candidates, then it could indicated so by sending the
>>>> end-of-candidates message we describe in the draft.
>>>
>>> In case Bob has a public IP address, why does Alice need to send an
>>> offer with the additional candidates in the first place? Why not
>>> simply start using them, and Bob will process them as peer reflexive
>>> candidates?
>>>
>>> (I can understand that signaling is needed in case per-candidate
>>> ufag/pwd values are used, but let's assume a case where the same
>>> values are used for all candidates.)
>>
>> My point was that Bobs IP address being public:
>>
>> * does not mean it is the best option: VPN, tunnelling, and multiple
>> interfaces can all generate public host IP addresses that are a lot less
>> preferable to server reflexive ones.
>> * does not even guarantee that it's reachable. Connectivity may be
>> administratively prohibited, routes can be down.
> 
> Alice CAN continue to gather candidates, in case there are better
> ones. My question was why she needs to signal them to Bob in a new
> offer, instead of simply start sending STUN checks associated with the
> candidates? Bob will then process them as peer reflexive candidates.

She can do that of course. And she should. That's what trickling is
about after all. But those checks may fail for the reasons above (second
bullet) or simply because Bob has a firewall with endpoint-dependent
filtering so it won't let Alice's packets come in unless Bob also starts
sending packets to her.

Does this make sense?

Emil

-- 
https://jitsi.org

From christer.holmberg@ericsson.com  Fri Oct 12 11:22:36 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7B21F8694 for ; Fri, 12 Oct 2012 11:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.12
X-Spam-Level: 
X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.129,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+gtLx+38kqJ for ; Fri, 12 Oct 2012 11:22:35 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EFDDD21F866E for ; Fri, 12 Oct 2012 11:22:34 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-1e-50785fe95339
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 63.FD.11467.9EF58705; Fri, 12 Oct 2012 20:22:34 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 12 Oct 2012 20:22:33 +0200
From: Christer Holmberg 
To: Emil Ivov 
Date: Fri, 12 Oct 2012 20:20:41 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2opb1XXCkWtyD5R0mmISa+dDNnWgAAIxyn
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA88@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>, <50782585.9070204@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA87@ESESSCMS0356.eemea.ericsson.se>, <50785E8A.7080903@jitsi.org>
In-Reply-To: <50785E8A.7080903@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre6r+IoAg/2zWS3W7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlbHpYB9TwTz+ire/N7I0ME7j6WLk5JAQMJGY t2kuC4QtJnHh3nq2LkYuDiGBU4wSr469gXIWMkp8fdDM3MXIwcEmYCHR/U8bpEFEQF6iu20R E4jNLKAise/eDUYQm0VAVWLT+7PMILawgKLEreOb2CDqlSSeP5/ECmEbSXy+/AqshlcgXOLf p3VgRwgJPGOVaLitC7KKU0BTYs9qDZAwI9Bt30+tgVolLnHryXwmiJsFJJbsOc8MYYtKvHz8 jxWiXlTiTvt6Roh6HYkFuz+xQdjaEssWvoZaKyhxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKs YhTOTczMSS831EstykwuLs7P0ytO3cQIjJuDW37r7mA8dU7kEKM0B4uSOC9X0n5/IYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYxTZn/6vu6+9vfr6s4fclXONzezJndkXdi54B3zn4vWfkuu Tg4o5Pq38dMF7XUiDbXta5vv1jr9CfSe8MLSSOVK0y2JFXudb1nqtOo37S6MXbz23uJfD163 ezln6t19raYs/TrSl6v0iNG63Q+jpsfuMKthYJqa0Djhf8cvidIPivtmuwk6hugpsRRnJBpq MRcVJwIAjJ0YtWkCAAA=
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 18:22:36 -0000

Hi,

>>>>> All in all, making assumptions on the receiving end is always a
>>>>> risk. If the host sending the candidates knows that they are its
>>>>> best/only candidates, then it could indicated so by sending the
>>>>> end-of-candidates message we describe in the draft.
>>>>
>>>> In case Bob has a public IP address, why does Alice need to send an
>>>> offer with the additional candidates in the first place? Why not
>>>> simply start using them, and Bob will process them as peer reflexive
>>>> candidates?
>>>>
>>>> (I can understand that signaling is needed in case per-candidate
>>>> ufag/pwd values are used, but let's assume a case where the same
>>>> values are used for all candidates.)
>>>
>>> My point was that Bobs IP address being public:
>>>
>>> * does not mean it is the best option: VPN, tunnelling, and multiple
>>> interfaces can all generate public host IP addresses that are a lot les=
s
>>> preferable to server reflexive ones.
>>> * does not even guarantee that it's reachable. Connectivity may be
>>> administratively prohibited, routes can be down.
>>
>> Alice CAN continue to gather candidates, in case there are better
>> ones. My question was why she needs to signal them to Bob in a new
>> offer, instead of simply start sending STUN checks associated with the
>> candidates? Bob will then process them as peer reflexive candidates.
>
> She can do that of course. And she should. That's what trickling is
> about after all. But those checks may fail for the reasons above (second
> bullet) or simply because Bob has a firewall with endpoint-dependent
> filtering so it won't let Alice's packets come in unless Bob also starts
> sending packets to her.
>
> Does this make sense?

Note that in my use-case Bob has a public IP address, and is an ICE lite en=
tity, so Bob won't send any STUN requests to Alice - only reply to those re=
ceived from Alice.

Regards,

Christer=

From emil@sip-communicator.org  Fri Oct 12 11:55:43 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF17C21F86D6 for ; Fri, 12 Oct 2012 11:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SfGN5UjDGnz for ; Fri, 12 Oct 2012 11:55:43 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEE5E21F867A for ; Fri, 12 Oct 2012 11:55:42 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so2067667wey.31 for ; Fri, 12 Oct 2012 11:55:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=SkNCou0e3lk3MYBe7yVcA/+yp/8rcy/Wg9Jc1eL1b20=; b=V4s/qq68kU7mb1cX/GpoXVn9Qhak+UwRzb1+JHEc+MXgBgnps8lAZG1zsmlARteQou 9Tgn5O9qxmu4v6A62gsNutFsq3xEixjUgWdtil0ITvXXcRQQJSW8+s2+ueyaxrTyCfGd 6dzg9r9G3T7aFJnf31kC6gFk6ee9xEGCLKF7hwZaha9GjZjuUqd8ReJ9Q3a8HVkdzbuH esQE0B0PSwPSl+RzvPd/wVtxKIf2ZcZYwCnEk1HnB4jMLzecG229F2JEB+aAREkpUcFY lCwDWhXWoNAlrWNogh8OyfQGomHU2VM8L45+zeXv8eX+XGBAm13Kx0JYsYLPEX1s/bHS jbHA==
Received: by 10.216.204.130 with SMTP id h2mr3009070weo.202.1350068141992; Fri, 12 Oct 2012 11:55:41 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:5c2a:e2a8:a4af:298b]) by mx.google.com with ESMTPS id dm3sm5157353wib.3.2012.10.12.11.55.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 11:55:41 -0700 (PDT)
Message-ID: <507867AB.70404@jitsi.org>
Date: Fri, 12 Oct 2012 20:55:39 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>, <50782585.9070204@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA87@ESESSCMS0356.eemea.ericsson.se>, <50785E8A.7080903@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA88@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA88@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmvGM7b8ZpjAzLZpPynTJdiv9B5HgwS/OATHgLUpL41uM33s/1FUvFfRonxlSto5ryyKt/F
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 18:55:44 -0000

Hey Christer,

On 12.10.12, 20:20, Christer Holmberg wrote:
> Hi,
> 
>>>>>> All in all, making assumptions on the receiving end is
>>>>>> always a risk. If the host sending the candidates knows
>>>>>> that they are its best/only candidates, then it could
>>>>>> indicated so by sending the end-of-candidates message we
>>>>>> describe in the draft.
>>>>> 
>>>>> In case Bob has a public IP address, why does Alice need to
>>>>> send an offer with the additional candidates in the first
>>>>> place? Why not simply start using them, and Bob will process
>>>>> them as peer reflexive candidates?
>>>>> 
>>>>> (I can understand that signaling is needed in case
>>>>> per-candidate ufag/pwd values are used, but let's assume a
>>>>> case where the same values are used for all candidates.)
>>>> 
>>>> My point was that Bobs IP address being public:
>>>> 
>>>> * does not mean it is the best option: VPN, tunnelling, and
>>>> multiple interfaces can all generate public host IP addresses
>>>> that are a lot less preferable to server reflexive ones. * does
>>>> not even guarantee that it's reachable. Connectivity may be 
>>>> administratively prohibited, routes can be down.
>>> 
>>> Alice CAN continue to gather candidates, in case there are
>>> better ones. My question was why she needs to signal them to Bob
>>> in a new offer, instead of simply start sending STUN checks
>>> associated with the candidates? Bob will then process them as
>>> peer reflexive candidates.
>> 
>> She can do that of course. And she should. That's what trickling
>> is about after all. But those checks may fail for the reasons above
>> (second bullet) or simply because Bob has a firewall with
>> endpoint-dependent filtering so it won't let Alice's packets come
>> in unless Bob also starts sending packets to her.
>> 
>> Does this make sense?
> 
> Note that in my use-case Bob has a public IP address, and is an ICE
> lite entity, so Bob won't send any STUN requests to Alice - only
> reply to those received from Alice.

Oh, I had missed the "Lite" part. Sorry about that.

So, yes, right now I can't think of a good reason why Alice would
continue trickling after a successful check in this case.

Emil





-- 
https://jitsi.org

From emil@sip-communicator.org  Fri Oct 12 12:00:47 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56D221F8750 for ; Fri, 12 Oct 2012 12:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtam38OLFrBS for ; Fri, 12 Oct 2012 12:00:46 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1514E21F8879 for ; Fri, 12 Oct 2012 12:00:35 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1737608wgb.13 for ; Fri, 12 Oct 2012 12:00:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=s7CYsNwbte84yZt65zYcEm/rINyAgkB8X7/waPAX9NI=; b=UtM/dwU0IoA1srTfIRZSi9ShIVMWG9Ep23DgSPe7VWLGSdw7qr1RLXFUHsTHcP8JEg xHN42fYmOGF2jrNlmUPvCB2P6csu2fKofGuHUzNX1OMw6zTKVOjqZ+Ch+9xGkoTsbdBA MFfQR7+BeCiYDISzfDQr0KDpxKwJYCANsAlX9OIKps5/ntFb3MARKreNw+0A80bOIaAO YIMmU1U3WO2TubJewEF1OHLF5QZY2TTxVtkFxBwo9167UbhO/L88RiSLb0HC5KeP4N7z wDxrkcRLcLGkkkng92oKnWrSDix0sy/2h5G7UIglO0/VFLfpv1ZfJK8x36F6nNAqBk+M PlQg==
Received: by 10.216.207.93 with SMTP id m71mr2844797weo.201.1350068435181; Fri, 12 Oct 2012 12:00:35 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:5c2a:e2a8:a4af:298b]) by mx.google.com with ESMTPS id p4sm5188888wix.0.2012.10.12.12.00.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 12:00:33 -0700 (PDT)
Message-ID: <507868D0.8010804@jitsi.org>
Date: Fri, 12 Oct 2012 21:00:32 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Lishitao 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnOHArBEtbXGudF1j7QCNkxsxQJjiHejS41gJMEghtCapK03TlcbjGlqOGqxuZXunLIkNWM
Cc: MMUSIC IETF WG , Christer Holmberg 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 19:00:47 -0000

Hey Shitao,

On 12.10.12, 04:43, Lishitao wrote:
> Hi Emil
> 
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
>> Of Emil Ivov
>> Sent: Friday, October 12, 2012 5:35 AM
>> To: Christer Holmberg
>> Cc: MMUSIC IETF WG
>> Subject: Re: [MMUSIC] Trickle ICE
>>
>> Hey Christer,
>>
>> On 11.10.12, 21:23, Christer Holmberg wrote:
>>>
>>> Hi,
>>>
>>> Q1: Remote endpoint support (SIP):
>>> ----------------------------------
>>>
>>>>>>> You say that, before the first offer is sent, one SHOULD
>>>>>>> determine whether the remote endpoint supports trickle ICE.
>>>>>>>
>>>>>>> For SIP, you give RFC 3840 as an example. I am not sure how
>>>>>>> that will work. Yes, you can use 3840 to request that the
>>>>>>> offer is sent to an entity which supports trickle ICE (for
>>>>>>> that, btw, you will also need to define an option tag, or
>>>>>>> something similar),
>>>>>>
>>>>>> Right, but we were hoping this would happen in a separate spec
>>>>>> that details use of trickle ICE with SIP.
>>>>>>
>>>>>>> but you cannot use it to determine whether the remote
>>>>>>> endpoint supports trickle ICE. In addition, you typically use
>>>>>>> 3840 at the same time when you send the initial offer.
>>>>>>>
>>>>>>> Of course, you could use SIP OPTIONS.
>>>>>>
>>>>>> Yes, that was the idea. The way 3840 describes it in Section
>>>>>> 8.
>>>>>>
>>>>>>> But, there are a number of issues related to that, and I
>>>>>>> don't think we want to define a mechanism which relies on the
>>>>>>> usage of OPTIONS.
>>>>>>>
>>>>>>> And, if we simply say that it's "outside the scope of the
>>>>>>> document",
>>>>>>
>>>>>> I was just about to say that ;).
>>>>>>
>>>>>> But, seriously, determining and negotiating caps happens very
>>>>>> differently in different signalling protocols, so it doesn't
>>>>>> seem reasonable to try and find answers for all of them in the
>>>>>> generic trickle ICE spec.
>>>>>>
>>>>>> XMPP for example, has this part covered pretty well. If we
>>>>>> determine that 3840 does not provide a way of doing the same
>>>>>> then we can find another way for SIP.
>>>>>>
>>>>>> Eric had this idea, where a trickle ICE agent would simply fire
>>>>>> a first offer that only other trickle ICE agents would accept
>>>>>> and that any other SIP endpoint would answer with an error.
>>>>>> This would be enough of a check and if it fails the caller can
>>>>>> fall back to vanilla ICE.
>>>>>
>>>>> Sure, but that is not checking for trickle support before sending
>>>>> the trickle offer :)
>>>>
>>>> Yes, the wording may need to be reviewed if we go for this.
>>>>
>>>>> Also, I guess I still haven't completely understood the backward
>>>>> compatibility issue, but I guess I need to do some more reading.
>>>>
>>>> We describe these in Section 3 but the main problem is that a
>>>> vanilla ICE agent that gets a first subset of candidates (that may
>>>> also be empty) would declare failure prematurely.
>>>
>>> The text gives an example where the receiver (Bob) receives a
>>> host-candidate-only offer, and start checks which fail.
>>>
>>> I think it's quite strange if Bob would reject the call at that
>>> point. Because, no matter how many candidates the offer contains,
>>> there might still be peer reflexive candidates created later,
>>
>> How does Bob know that there's going to be a "later" ? It's just a
>> vanilla ICE agent that assumed it received a full set of candidates, it
>> checked them all, all checks failed.
>>
>> Now, we could rely on Bob not doing anything rash and waiting patiently
>> for reINVITEs from Alice in order to get more candidates ... but that
>> might be about as risky as relying on empty INVITEs to be handled
>> properly by everyone or on OPTIONS to be transmitted end-to-end.
>>
>> Besides there are other possible failures, like for example the case
>> where I get your server reflexive candidates long before you get mine so
>> we perform checks out of sync (the case that I also described in my
>> other mail to Martin).
>>
>>> once
>>> the offerer (Alice) starts sending the STUN binding requests. So, one
>>> would think that Bob at least would wait for those.
>>>
>>>>>> Another option would be for trickle ICE agents to send empty
>>>>>> INVITEs that somehow indicate they will be trickling but
>>>>>> contain no actual offer. The offer that the remote side then
>>>>>> adds in an OK response (or a provisional one) would clearly
>>>>>> indicate whether they support vanilla, trickle, or no ICE at
>>>>>> all, so the trickle agent would be able to answer accordingly
>>>>>> with the ACK.
>>>>>
>>>>> I don't think we want to rely on empty INVITEs either, because
>>>>> there are a number of issues related to that.
>>>>
>>>> Well, it might be worth investigating exactly what they are. The
>>>> same applies to using OPTIONS and 3840.
>>>
>>> Well, to start with, empty INVITEs will work very badly with legacy.
>>
>> You mean, because legacy devices don't properly implement 3261 in that
>> regard?
>>
>> That might actually be a good thing. An error response at this point
>> would be a good indication that there's no trickle ICE support at the
>> remote side.
> 
> In this way , as christer described, it won't save any time in call establishment. 

I believe Christer was referring to the case where an extra RTT right
before trickle ICE negotiation.

In this case however we are talking about an extra RTT that happens
before a vanilla ICE session and that is not in anyway blocking
candidate harvesting, so I don't see how it would be a problem.

That said, I already agreed that relying on empty INVITEs has other
disadvantages (same as empty INVITEs outside the context of ICE).

>>> In addition, there migth be other functions which do not work with
>>> empty INVITEs.
>>
>> OK, I agree. It's a clumsy solution at best. It would be impossible for
>> SIP user agents to translate a user request to start an audio,
>> audio/video or some other media session (which is the typical rant you
>> get for handling empty INVITEs). It was just a thought :)
>>
>>> And, I am not sure how it would work with JSEP.
>>
>> You mean, in cases of gatewaying SIP to WebRTC? I suppose it could just
>> be translated to some custom signalling that actually does capability
>> negotiation and then triggers a remote INVITE ... OK I know, it's a stretch.
>>>
>>>
>>>>>>>> we could do the same for BUNDLE, and we wouldn't have
>>>>>>>> issues with re-using the same ports in multiple m- lines
>>>>>>>> etc :)
>>>>>>>
>>>>>>> Well, we are not saying that they should not be addressed at
>>>>>>> all, or even now. Just that maybe they shouldn't be addressed
>>>>>>> by this specific document.
>>>>>>
>>>>>> Perhaps we shouldn't say anything about finding out in advance,
>>>>>> then. At least not use SHOULD.
>>>>>>
>>>>>> We CAN describe what may happen if the remote peer does not
>>>>>> support trickle ICE, but leave it to that.
>>>>>
>>>>> What we'd like to avoid is having trickle ICE offers to vanilla
>>>>> ICE agents and then having them fail in a user-perceptible way.
>>>>>
>>>> Maybe we could modify the "SHOULD verify support" to "SHOULD verify
>>>> support or provide a mechanism for transparent fallback to vanilla
>>>> ICE"
>>>
>>> In my opinion, if one has to do something extra (e.g. send OPTIONS),
>>> the whole idea of trickle-ICE goes away, because at the end of the
>>> day you won't save any time in call establishment.
>>
>> The OPTIONS request does not need to be sent right before the call. It
>> can be done once, upon bootstrap.
> 
> If the callee has already in your contact list, of course you can do that, but if you 
> call a strange number at the first time, the OPTION request should be sent right 
> before the call.

Yes, good point!

Emil
> 
> 
> /Shitao
> 
>>> Now, if the browser is communicating with a ICE terminating gateway,
>>> and if the browser performs SIP registration, then the gateway can
>>> indicate trickle-ICE during registration.
>>>
>>> But, in the peer-to-peer case I don't know how it would work. It's
>>> not even sure OPTIONS would reach the same remote peer as the
>>> INVITE...
>>
>> I agree. Not sure what to say other than, I agree that SIP does not have
>> good mechanisms for XMPP like negotiation of entity caps but,
>> personally, I do believe that finding one would be helpful here.
>>
>> Maybe we can work on making sure that 3840 (or some other mechanism)
>> would better allow for caps to be discovered in advance.
>>
>> At the very least, if we can't find a way to do this gracefully with
>> SIP, we can RECOMMEND it whenever the protocol allows it and try to
>> devise a fall back strategy when it does not (e.g. with SIP).
>>
>>> Q2: Offer/Answer Alignment: ---------------------------
>>>
>>>>>>> I assume the offers and answer are sent according to the
>>>>>>> rules in RFC 3264.
>>>>>>>
>>>>>>> If so, when you talk about offers and/or answers "being sent
>>>>>>> at any point", I think it needs to be clear that it's within
>>>>>>> the rules of 3264.
>>>>>>
>>>>>> Good point! I think the text is indeed a bit unclear in that
>>>>>> regard and we might be making some non-stated assumptions about
>>>>>> the relation between 3264 Offer/Answer, the actual call
>>>>>> answering, and the connectivity checks phase. We'll fix this.
>>>>>
>>>>> Thanx! :)
>>>
>>>
>>> Q3: Enough is enough: ---------------------
>>>
>>>>>>> I think it could be useful for the answerer to tell the
>>>>>>> offerer that it doesn't want/need any more candidates.
>>>>>>
>>>>>> Yes, sounds useful. Do you have any specific use cases in
>>>>>> mind?
>>>>>
>>>>> Well, I guess any case where the remote peer knows it has a
>>>>> public IP address (it will most likely be an ICE lite entity).
>>>>
>>>> Right, but in such cases the offerer would also know that a certain
>>>> pair has succeeded so if they continue it might be with the purpose
>>>> of finding a better RTT or a higher priority local candidate.
>>>>
>>>> I guess what I am trying to say is that a Binding Response is
>>>> enough of an indication that trickling can stop. If it doesn't then
>>>> maybe it's for a reason.
>>>
>>> Maybe it is enough... In any case I think it would be good to
>>> document :)
>>
>> OK. Agreed.
>>
>>> Also, at least in cases where the remote peer only provide a host
>>> candidate (because it has a public IP address), one should be smart
>>> enough to figure out that there most likely will be no better
>>> alternative.
>>
>> I am not sure I got this.
>>
>> Cheers,
>> Emil
>>>
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org

From martin.thomson@gmail.com  Fri Oct 12 13:14:31 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3652C21F87D6 for ; Fri, 12 Oct 2012 13:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyKfECMfloN1 for ; Fri, 12 Oct 2012 13:14:30 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05E8F21F87D5 for ; Fri, 12 Oct 2012 13:14:29 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1769500wgb.13 for ; Fri, 12 Oct 2012 13:14:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eE2RX2JX82XSP2lShtF1c+yJE/F2H317vbx3JPNCrGM=; b=F1UbpnxfjcVp4Em7dXWT76YbUqU88wI0KHaucAaJZYbc8VP3THJcPSS0f8yX/y5zw7 OEaXzjTJlhweD54SrKBRU+440zufNsgRpoHwzqaT/VcTa+m71B92gGdndeyLOcjsUpqJ Q1qFsguuLQ8QHRWQ9Ul0BpU0S6xeF/zJFDlg59V8G1ea/k+wsl5d0dbMBRddqwbc+s+z OryFQ08RZOLusJ2tp1rdvKAOW4Ep8vhgT6klJDV7CcZ5Hvryf/ePanEoWhiNzI64Fd2X vFTjvBE+4uIwGtWmMIhl6fHJtSaw+wwBxMzIUEGthmwZXgOiaQRjtvq0cA2Dccqn6z7+ mMrw==
MIME-Version: 1.0
Received: by 10.181.13.208 with SMTP id fa16mr8349295wid.11.1350072869226; Fri, 12 Oct 2012 13:14:29 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Fri, 12 Oct 2012 13:14:29 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 12 Oct 2012 13:14:29 -0700
Message-ID: 
From: Martin Thomson 
To: Justin Uberti 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] ICE tiebreaker - session-level or media-level?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 20:14:31 -0000

On 11 October 2012 23:25, Justin Uberti  wrote:
> Reviewing the handling of role conflicts, a question came up: in the event
> different systems handle different media in a session, do they have to share
> the same ICE tiebreaker?

My reading was the same.  There is an expectation of a single agent
that handles the entire session.

I presume that you are concerned about deployments where audio and
video is routed to separate mixers.  My guess was that ICE lite would
have been assumed for the mixer, in which case the tie breaker becomes
moot.

I imagine that any attempt to "fix" this would require new work.  The
decision to operate multiple agents would have to be negotiated so
that both sides properly synchronize their connectivity checking.

From martin.thomson@gmail.com  Fri Oct 12 14:59:38 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEBC21F8712 for ; Fri, 12 Oct 2012 14:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.907
X-Spam-Level: 
X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnxaTAXFt+IW for ; Fri, 12 Oct 2012 14:59:37 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 837FD21F86E0 for ; Fri, 12 Oct 2012 14:59:37 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hm2so245926wib.1 for ; Fri, 12 Oct 2012 14:59:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NjKX2N5q8un9vHpemoanVGejDv+46lFw9oxv9IcHJrI=; b=KVOLdU4g3EoDTkWrYpmLqR4Hz1XNSs5zDxWXNYtpkNbcYYbvW4DIqFFcpCPicu/uRj CudAP9BaAsDgmXKGsgbAPGsYdyEkbfE6sCcjzFkT+l5IA8o+wYoccvzoV6PAXDWjAsvH zp/eMLpSD5Iv53FoFmUFlxeDMSoYnsqroATWJ1fKYqoz4KN7ZfioltUPfEh0ILi4SrJ6 5d5gWmcGX0H5SHAjZynpzlksXk3UzGQff21zJGNTy+D4eDfNTMaX1ha/Nwthz8pn2KIL IHM8K1JNWG6r90cboiX7/plokZpRujkWWWnXhubBsJtIsyJfZAQEvKFDOulfIsJB6Xfb lmVA==
MIME-Version: 1.0
Received: by 10.180.100.97 with SMTP id ex1mr8717555wib.17.1350079176645; Fri, 12 Oct 2012 14:59:36 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Fri, 12 Oct 2012 14:59:36 -0700 (PDT)
Date: Fri, 12 Oct 2012 14:59:36 -0700
Message-ID: 
From: Martin Thomson 
To: "mmusic@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Subject: [MMUSIC] The floodgates are open
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 21:59:38 -0000

The consent that ICE provides is strictly Boolean.

There is no way to distinguish between consent to receive 4kbps audio
and 5Mbps video.  This creates an exposure for services and endpoints
that support receipt of media, in particular contact centres and other
services that are necessarily open to incoming sessions by default.

This working group has an analogous problem.  The consent to entertain
modifications to ICE did not stipulate any constraints on volume.
Looking to exploit that shortcoming, Bernard and I have submitted a
draft that addresses the protocol shortcoming:

http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00

From olivier.crete@collabora.com  Fri Oct 12 15:15:19 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DA221F86E3 for ; Fri, 12 Oct 2012 15:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhLh5+3qN6DG for ; Fri, 12 Oct 2012 15:15:18 -0700 (PDT)
Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.135.160]) by ietfa.amsl.com (Postfix) with ESMTP id 55F4121F86AA for ; Fri, 12 Oct 2012 15:15:18 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tester) with ESMTPSA id CE96F600B5D
Message-ID: <1350080115.2197.3.camel@TesterTop4>
From: Olivier =?ISO-8859-1?Q?Cr=EAte?= 
To: mmusic@ietf.org
Date: Fri, 12 Oct 2012 18:15:15 -0400
In-Reply-To: 
References: 
Organization: Collabora
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";  boundary="=-ra9vdk16Ybx69vnOwRC+"
X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17) 
Mime-Version: 1.0
Subject: Re: [MMUSIC] The floodgates are open
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 22:15:19 -0000

--=-ra9vdk16Ybx69vnOwRC+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-10-12 at 14:59 -0700, Martin Thomson wrote:
> The consent that ICE provides is strictly Boolean.
>=20
> There is no way to distinguish between consent to receive 4kbps audio
> and 5Mbps video.  This creates an exposure for services and endpoints
> that support receipt of media, in particular contact centres and other
> services that are necessarily open to incoming sessions by default.
>=20
> This working group has an analogous problem.  The consent to entertain
> modifications to ICE did not stipulate any constraints on volume.
> Looking to exploit that shortcoming, Bernard and I have submitted a
> draft that addresses the protocol shortcoming:
>=20
> http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00

I really think you're trying to put this in the wrong layer. SDP already
has b=3D lines. And WebRTC should also include a congestion control
mechanism which you can probably also use to control/share bandwidth
more dynamically.

--=20
Olivier Cr=C3=AAte
olivier.crete@collabora.com

--=-ra9vdk16Ybx69vnOwRC+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEABECAAYFAlB4lnMACgkQHTiOWk7Zors9uwCfYNtPtzqYosefrqI10BnLU9Dp
LNkAniwBJNy9o4y4OADCvb+rWgtB1h6A
=2I5o
-----END PGP SIGNATURE-----

--=-ra9vdk16Ybx69vnOwRC+--


From emil@sip-communicator.org  Fri Oct 12 15:16:20 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1981821F8712 for ; Fri, 12 Oct 2012 15:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 563wOgRDuPkZ for ; Fri, 12 Oct 2012 15:16:19 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A699A21F86E3 for ; Fri, 12 Oct 2012 15:16:18 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so236254wib.13 for ; Fri, 12 Oct 2012 15:16:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=LFeom1HLORhhZ/fBuGvFrTudrptg7grZ4n2VxNwfcVU=; b=O9oHBK8LnxgQvhLNLdoKjdVt70bIm9diF8P2Dfp1+ByHlrJnPIf7qnJwKHPsCO3EGq wku5L6Zgpfum9uhhor2aTawbazRLd31bo2Y2R6b/SUqw60gDqhYp/73tHpaR0q2MOH/s BulKu6vro8irrfttHki7G0KKHJhE2NTqB/2loLu8hui9+9T8dvmgZhbWLOVq3Ayru8dA MhnT9NqEB3LBYjp2qoOqi+yvktyan6lK7UXixG5HBlqhuTsQ+8gOkxIB+yWH5ola9NTt 7jnp5/23nR/kwBjTmHys/sA124yMzlig6B3tfMz6whHRbyIG2vGHLlJJ9ohfELKCpWX3 OWDA==
Received: by 10.180.105.168 with SMTP id gn8mr8802895wib.10.1350080177873; Fri, 12 Oct 2012 15:16:17 -0700 (PDT)
Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id b7sm5349273wiz.3.2012.10.12.15.16.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 15:16:16 -0700 (PDT)
Message-ID: <507896B0.50806@jitsi.org>
Date: Sat, 13 Oct 2012 00:16:16 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Thomson 
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org>  <5075FAC3.20709@jitsi.org>  <50773B68.10707@jitsi.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmygNyipTd5MRCgN+XEla33Taf6uSeLG2JvkvEamLXFRRuD9hAorjJvWTCBIISzl8WU3Siv
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 22:16:20 -0000

Hey Martin,

On 12.10.12, 18:55, Martin Thomson wrote:
> Emil,
> 
> On 11 October 2012 14:34, Emil Ivov  wrote:
>>> Actually, this part in Section 9 wasn't very clear.
>>
>> Sorry about that. We'll try to add clarifications before the 01 deadline.
> 
> Actually, I think that we've just uncovered a case of talking past
> each other.  I was talking about the inter-component interactions and
> you were talking about the interactions intra-component.

Do you mean inter/intra-checklist?

> It's seems obvious to me now that there needs to be more certainty
> about the interactions on both axes.

I do believe we mention both of those but there are probably a number of
things still missing. We'll be reviewing the text in the following days
but if you can describe specific scenarios that you believe are not
currently covered, this would be very helpful.

> There are clearly interactions on the one component, but I'm not sure
> that the conclusions that you have drawn are necessarily optimal.

Completely possible.

> When you make the choice to cancel an outstanding transaction, you
> don't do anything other than increase the probability of success.  The
> Binding requests from the lower priority pair have gone out and may
> still succeed, assuming of course that both peers are opening
> pinholes.

Well, the reason we cancel and then restart transactions is exactly
because both peers have most probably not opened pinholes.

I do however agree that in certain situations transactions may be
cancelled when they were just about to succeed, but I also think this
would be fairly easy to cover: as you suggested yourself - we just need
to declare the check successful.

> Cancelling the transaction at this point seems counterproductive.
> Instead, adding the new pair to the check list such that a transaction
> is created in response to the next ordinary check timer pop ensures
> that checks proceed on the new pair as soon as is reasonable

I agree and I also believe that this is exactly what the text says right
now.

>, while
> allowing the lower priority pair to move to the Failed or Succeeded
> state normally.
> 
> This may result in a lower priority pair reaching Succeeded before the
> higher priority one, but that was an inevitable consequence of the
> sequencing anyhow.

I agree and I think that if a check succeeds while it is being
cancelled, we don't necessarily need to insist on the higher priority,
redundant pair succeeding. I suppose in we can maybe keep them this way
(that is, the lower prio as successful and the higher prio as failed).

However if it doesn't and the transaction is properly cancelled then we
may just as well reschedule it for the higher prio pair.
> 
>>> You can't send an offer sans candidates and expect it to work.
>>
>> Indeed not. I would expect it to fail for non-trickle agents (without
>> alerting the remote user) which would then be my cue to fallback to
>> vanilla ICE.
> 
> That's an interesting choice.  I tend to prefer don't-even-try
> solutions to try-fail-and-fallback ones if at all possible.  They tend
> to be more robust because your legacy peer doesn't get in a messed up
> state due to the failure.

It's funny how I find my self on exactly the opposite sides of the same
argument in two concurrent threads :).

Yes, check-before-trying is definitely better, which is why we currently
have it as a SHOULD in the draft. The sentence that you are commenting
on was just an example of an alternative way of doing the same thing for
protocols that don't have decent Caps negotiation, like SIP.

My conversation with Christer was about me desperately insisting that
there might be a way to do this with SIP, and him persuading me that
there isn't and that we should keep this in mind when designing base
trickle.

I still think that using things like XMPP disco info and entity
capabilities is best when available.

>>> Note: we probably also need to note that a transaction can succeed for
>>> a Frozen candidate pair (due to the fact that you can't take a STUN
>>> packet back, so "cancelling" a transaction might still result in a
>>> successful Binding response.  I don't know what you would do with
>>> this, but I'd just move the pair to Succeeded.
>>
>> The case where a cancelled transaction ends up succeeding is indeed
>> worth covering, but given how the concept is defined in 5245 then maybe
>> at least part of the coverage should go in 5245bis?
> 
> 5245 doesn't really have the concept of re-freezing a pair, does it?

No, and neither do we. 5245 defines the concept of cancelling a
transaction however and it doesn't cover the case where it succeeds
while being cancelled. It might be worth doing it.

Cheers,
Emil





-- 
https://jitsi.org

From martin.thomson@gmail.com  Fri Oct 12 16:18:43 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC521F858E for ; Fri, 12 Oct 2012 16:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.751
X-Spam-Level: 
X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4mEmMAUlDtJ for ; Fri, 12 Oct 2012 16:18:42 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D70A21F8573 for ; Fri, 12 Oct 2012 16:18:42 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hq12so29671wib.13 for ; Fri, 12 Oct 2012 16:18:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bDmPixiA4s+MpNUpZdqGrKaZR0KM6l4g8bSGEo1DhJg=; b=mINPHtECJCR9skaWHf/pF3E6nCCAVGej+UAfEvVbOsh9XGGAZkyfMQBQDn43DF8zGo 9Vb2qOLOGRCnsV2W5OnV1xW3EENoV83Gy2aOvqU6EzUr4F8gCi2L3kNer1epM2X2yqYx rPPRUgNpCM98mNn5tysiIjf6NwrvKTmEMS6Ic9bJST23gjHAByNR7/uGvmYW2JweVd2D O6HtV6oTXd97GJ9jukEqFIBwutoCpZDqjAG2GqmEzmcua7vIXsU5P1ndQXuNfBbl1gH8 ON1VmxN1+8LuqfWD8D5wINjbmkCOOy2jf5+sKqOBe5Kj0S7Oj/WSzY/yWmAAoM96gGQt yAqA==
MIME-Version: 1.0
Received: by 10.216.141.16 with SMTP id f16mr3724218wej.130.1350083921313; Fri, 12 Oct 2012 16:18:41 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Fri, 12 Oct 2012 16:18:41 -0700 (PDT)
In-Reply-To: <1350080115.2197.3.camel@TesterTop4>
References:  <1350080115.2197.3.camel@TesterTop4>
Date: Fri, 12 Oct 2012 16:18:41 -0700
Message-ID: 
From: Martin Thomson 
To: =?UTF-8?Q?Olivier_Cr=C3=AAte?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] The floodgates are open
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 23:18:43 -0000

On 12 October 2012 15:15, Olivier Cr=C3=AAte  =
wrote:
> I really think you're trying to put this in the wrong layer. SDP already
> has b=3D lines.

b=3D lines are under the direct control of a web-based attacker, the
exact person we trust least in this scenario.

> And WebRTC should also include a congestion control
> mechanism which you can probably also use to control/share bandwidth
> more dynamically.

That would be nice, in theory.  After the RMCAT BoF and reading all
the papers from the IAB workshop on the subject, I did not come away
with a warm fuzzy feeling.  There are methods that are proven to work
for some definition of "work" but all of these assume that the
receiver is at a minimum willing to receive the packets that are being
sent.

From martin.thomson@gmail.com  Fri Oct 12 16:23:58 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFCD21F86A8 for ; Fri, 12 Oct 2012 16:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.532
X-Spam-Level: 
X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7OVuss4AXJ6 for ; Fri, 12 Oct 2012 16:23:58 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9247021F86A4 for ; Fri, 12 Oct 2012 16:23:56 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1838545wgb.13 for ; Fri, 12 Oct 2012 16:23:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7PDU4t7Hxo9mU5yIiKHY+cXwE9GO4cpTZm9UPC1JCl4=; b=iXpBhN03kwZUpxuh2+8wFSYEJRrSe85hpxDJD3kpTH+nD3gc7N2Kl7mepgBupw4rBt oiLUilPeVIJqVWY25pDgp8sYuPoPWjQVPuQvpUtwamrPtCU3SPTwDyd+rCjTphDdKOL+ DIqQliam276rRqUTNq0FJG6EZ/0EqU2RUfV+Jz8JGzMmFJEjPR8quq7mDvo0te90baBF gITF36EteVuyptIvIi4uv/9ditQmFCqw+j4rvLndP/IP5eelTdo3wys92Q7yTjI4GMNt giZafV4heWH7okl01FqD6GJCMUfh5LOdQXW9A/8MnD1KKZWFTtygR1MBXYbBOrFvINEP HLaw==
MIME-Version: 1.0
Received: by 10.180.93.33 with SMTP id cr1mr9081831wib.8.1350084235594; Fri, 12 Oct 2012 16:23:55 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Fri, 12 Oct 2012 16:23:55 -0700 (PDT)
In-Reply-To: <507896B0.50806@jitsi.org>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org>  <5075FAC3.20709@jitsi.org>  <50773B68.10707@jitsi.org>  <507896B0.50806@jitsi.org>
Date: Fri, 12 Oct 2012 16:23:55 -0700
Message-ID: 
From: Martin Thomson 
To: Emil Ivov 
Content-Type: text/plain; charset=UTF-8
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 23:23:58 -0000

Hey,

Only really one thing to say.  The rest can await the meeting (where
I'm going to be in another room), or a revised draft.

On 12 October 2012 15:16, Emil Ivov  wrote:
> Yes, check-before-trying is definitely better, which is why we currently
> have it as a SHOULD in the draft. The sentence that you are commenting
> on was just an example of an alternative way of doing the same thing for
> protocols that don't have decent Caps negotiation, like SIP.

If you say SHOULD for any particular thing, then it MUST be possible.
In order for something to be possible, you have to define a mechanism.
 My current preference is for this draft to not declare the mechanism
out of scope.  Obviously, we have a little way to go on that front, at
least with SIP.

--Martin

From ted.ietf@gmail.com  Fri Oct 12 16:25:56 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20F521F86DF for ; Fri, 12 Oct 2012 16:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.512
X-Spam-Level: 
X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGMR5CFUuJ+a for ; Fri, 12 Oct 2012 16:25:56 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 638D521F86D0 for ; Fri, 12 Oct 2012 16:25:56 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so3984173vbb.31 for ; Fri, 12 Oct 2012 16:25:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QFbILGa4ThOc78T+zAdDYELJF07NwEVfzBxgvyEnATk=; b=TlMPWti+8zkU/OzNraWdOtvr1jC8uMxv6DMT3gRRLtPuxJUh2xP6G/WmWGb+YOEcf6 ubOTD1wTVHrG/jUtHQaa310DUb4pwyeM8Q6gonzTsO2iYWNx06Ey/Q+bMBOkgSQik0j2 fVZMz/gY5kV6pLUxWieFhrEj9TdbKpEAAssIru0YQwhFDyGbi314SwiWfNNfCaZZ2lvT 657BMhjIPYbTCSxK59IXANs0FeIqLWoQbvwBV7IaBNJ460qr57cWjtERJKr2rlW6XYV6 uqTWS4v/rNacAzh012mEfirfUWHnP0HoFWkZPq+uLKjxnvFVRIXNfoO2H+EYj0oOv3l4 zbJQ==
MIME-Version: 1.0
Received: by 10.220.238.148 with SMTP id ks20mr3361534vcb.5.1350084355738; Fri, 12 Oct 2012 16:25:55 -0700 (PDT)
Received: by 10.58.245.39 with HTTP; Fri, 12 Oct 2012 16:25:55 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 12 Oct 2012 16:25:55 -0700
Message-ID: 
From: Ted Hardie 
To: Martin Thomson 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] The floodgates are open
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Oct 2012 23:25:57 -0000

So, possibly I am completely misunderstanding the state of play here,
but I thought that we had come to the understanding that ICE gave you
a boolean consent *for the length of the consent freshness*  (and that
we could (n theory, at least alter the length of the consent freshness
to handle the risk of voice-hammer style attacks).  In other words,
that boolean exposes you to risk only for the time of the consent
freshness, not for all time, and this mitigated the risk sufficiently.

What have I missed?

Ted

On Fri, Oct 12, 2012 at 2:59 PM, Martin Thomson
 wrote:
> The consent that ICE provides is strictly Boolean.
>
> There is no way to distinguish between consent to receive 4kbps audio
> and 5Mbps video.  This creates an exposure for services and endpoints
> that support receipt of media, in particular contact centres and other
> services that are necessarily open to incoming sessions by default.
>
> This working group has an analogous problem.  The consent to entertain
> modifications to ICE did not stipulate any constraints on volume.
> Looking to exploit that shortcoming, Bernard and I have submitted a
> draft that addresses the protocol shortcoming:
>
> http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From bernard_aboba@hotmail.com  Fri Oct 12 17:43:42 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3953B21F84F1 for ; Fri, 12 Oct 2012 17:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.901
X-Spam-Level: 
X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ8uBWO+bxO2 for ; Fri, 12 Oct 2012 17:43:41 -0700 (PDT)
Received: from blu0-omc4-s26.blu0.hotmail.com (blu0-omc4-s26.blu0.hotmail.com [65.55.111.165]) by ietfa.amsl.com (Postfix) with ESMTP id 91CBA21F84D4 for ; Fri, 12 Oct 2012 17:43:41 -0700 (PDT)
Received: from BLU402-EAS111 ([65.55.111.135]) by blu0-omc4-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Oct 2012 17:43:40 -0700
X-Originating-IP: [72.11.69.66]
X-EIP: [pBJr4Nv92mSSMD3dl9Q7TGSkJlwo0ZK2]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References:  
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: 
Date: Fri, 12 Oct 2012 17:44:25 -0700
To: Ted Hardie 
X-OriginalArrivalTime: 13 Oct 2012 00:43:40.0858 (UTC) FILETIME=[CA4731A0:01CDA8DB]
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] The floodgates are open
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 00:43:42 -0000

A receiver can stop responding to STUN binding requests. However, this will t=
ake a while to take effect and it is all or nothing.  With a sender-based co=
ngestion control scheme there may not be a way for the receiver to indicate a=
 limit, and even in a receiver-based scheme TMMBR messages aren't acknowledg=
ed.

On Oct 12, 2012, at 16:25, "Ted Hardie"  wrote:

> So, possibly I am completely misunderstanding the state of play here,
> but I thought that we had come to the understanding that ICE gave you
> a boolean consent *for the length of the consent freshness*  (and that
> we could (n theory, at least alter the length of the consent freshness
> to handle the risk of voice-hammer style attacks).  In other words,
> that boolean exposes you to risk only for the time of the consent
> freshness, not for all time, and this mitigated the risk sufficiently.
>=20
> What have I missed?
>=20
> Ted
>=20
> On Fri, Oct 12, 2012 at 2:59 PM, Martin Thomson
>  wrote:
>> The consent that ICE provides is strictly Boolean.
>>=20
>> There is no way to distinguish between consent to receive 4kbps audio
>> and 5Mbps video.  This creates an exposure for services and endpoints
>> that support receipt of media, in particular contact centres and other
>> services that are necessarily open to incoming sessions by default.
>>=20
>> This working group has an analogous problem.  The consent to entertain
>> modifications to ICE did not stipulate any constraints on volume.
>> Looking to exploit that shortcoming, Bernard and I have submitted a
>> draft that addresses the protocol shortcoming:
>>=20
>> http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From bernard_aboba@hotmail.com  Fri Oct 12 18:50:01 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F3F21F86C8 for ; Fri, 12 Oct 2012 18:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.368
X-Spam-Level: 
X-Spam-Status: No, score=-101.368 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdzB49ApHhq1 for ; Fri, 12 Oct 2012 18:50:01 -0700 (PDT)
Received: from blu0-omc3-s26.blu0.hotmail.com (blu0-omc3-s26.blu0.hotmail.com [65.55.116.101]) by ietfa.amsl.com (Postfix) with ESMTP id D83A621F86C7 for ; Fri, 12 Oct 2012 18:50:00 -0700 (PDT)
Received: from BLU401-EAS379 ([65.55.116.74]) by blu0-omc3-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Oct 2012 18:50:00 -0700
X-Originating-IP: [72.11.69.66]
X-EIP: [aBEy26i0qxU4V4peCONcZ2/x/ZPx/fJ9]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>
From: Bernard Aboba 
MIME-Version: 1.0 (1.0)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>
Date: Fri, 12 Oct 2012 18:50:44 -0700
To: Christer Holmberg 
X-OriginalArrivalTime: 13 Oct 2012 01:50:00.0173 (UTC) FILETIME=[0E2279D0:01CDA8E5]
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 01:50:01 -0000

On Oct 10, 2012, at 11:18, "Christer Holmberg"  wrote:

Q1: Remote endpoint support (SIP):
> --------------------------------------------
>=20
> You say that, before the first offer is sent, one SHOULD determine whether=
 the remote endpoint supports trickle ICE.=20
>=20
> For SIP, you give RFC 3840 as an example. I am not sure how that will work=
. Yes, you can use 3840 to request that the offer is sent to an entity which=
 supports trickle ICE (for that, btw, you will also need to define an option=
 tag, or something similar), but you cannot use it to determine whether the r=
emote endpoint supports trickle ICE. In addition, you typically use 3840 at t=
he same time when you send the initial offer.
> Of course, you could use SIP OPTIONS. But, there are a number of issues re=
lated to that, and I don't think we want to define a mechanism which relies o=
n the usage of OPTIONS.

I think the idea originated from the RFC 5768 use of sip.ice, such as in a R=
equire header in an INVITE request, Contact header in a REGISTER request or O=
PTIONS response. Some of the scenarios mentioned there include gateway scena=
rios in Section 3.1.=

From miguel.a.garcia@ericsson.com  Sat Oct 13 00:48:49 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839BE21F8643 for ; Sat, 13 Oct 2012 00:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.243
X-Spam-Level: 
X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHbNxyzr4aXs for ; Sat, 13 Oct 2012 00:48:49 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7621F8619 for ; Sat, 13 Oct 2012 00:48:48 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-78-50791cdfd87c
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 28.12.11467.FDC19705; Sat, 13 Oct 2012 09:48:47 +0200 (CEST)
Received: from [159.107.48.11] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sat, 13 Oct 2012 09:48:46 +0200
Message-ID: <50791CDC.7030104@ericsson.com>
Date: Sat, 13 Oct 2012 09:48:44 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Bernard Aboba 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3Vve+TGWAwY7HUhb7l1xmtpi6/DGL A5PH454zbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr43XKAtWAhX0XTlWWMDYxHuLsYOTkkBEwk dv1vY4KwxSQu3FvPBmILCZxilHh2MaKLkQvIXs0oMfXDXbAEr4C2xPzmVhYQm0VAVWLPkZ+M IDabgLlE68aN7F2MHByiAsESXYfFIMoFJU7OfMICEhYR0JX422UEEmYWEJa4cP442FphATWJ DbcbmCDWWkn0/3wNNpFTwFri4cSlzBD1thIX5lxngbDlJba/ncMMUa8pMfnmUuYJjIKzkGyb haRlFpKWBYzMqxiFcxMzc9LLDfVSizKTi4vz8/SKUzcxAsP04JbfujsYT50TOcQozcGiJM7L lbTfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMjz93dpzhdPts9+ffr1lcf7s3tSuZLAvYy Joe80G2Z6bdI1SjAwtJmZ8Pk3r5JfPKzzVqUb7364Xe2kbWv8vKTa92aPu8VvW+7Hry/65ha fNIn5vTGV/2FTHdml0dknLhxuHjZK91ZNyK8jY9OFv6bc6BSl+Wq3PLpnL9evV8623zdItnL 3t7JSizFGYmGWsxFxYkAmneBeSECAAA=
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] MSID and mslabel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 07:48:49 -0000

Bernard,

I cannot identify the "mslabel" attribute. Do you know where it is specified?

Perhaps you refer to the "label" attribute (RFC 4574).

/Miguel


On 11/10/2012 16:30, Bernard Aboba wrote:
> Question:  Can someone comment on the difference between msid and the
> "mslabel" attribute?
>
> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
> Stefan Hakansson LK
> Sent: Thursday, October 11, 2012 7:13 AM
> To: mmusic@ietf.org
> Subject: [MMUSIC] WG poll for consensus MSID draft
>
> I'm not a MMUSIC regular, but active in rtcweb. I would like this draft to
> go forward as the info that msid provides is necessary for "gluing together"
> the JS API and the actual rtp streams.
>
> Stefan
>
>
> "At the last IETF meeting we had a presentation of the following draft:
>
> http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/
>
> At that time, there was interest in solving the problem of cross session
> stream identification.
>
>
> We would like to poll the working group for consensus on adopting the
> above mentioned draft as a working group item, once we get an approved
> milestone.
>
>
> If you support this work or have problems with the adoption of this
> document as WG item, please indicate it by replying to this e-mail
> within the next 5 days.
>
>
> Flemming and Miguel (co-chairs)
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain"
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From christer.holmberg@ericsson.com  Sat Oct 13 01:35:16 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8A921F8440 for ; Sat, 13 Oct 2012 01:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.123
X-Spam-Level: 
X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNsngggaD9Wf for ; Sat, 13 Oct 2012 01:35:15 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1401E21F8437 for ; Sat, 13 Oct 2012 01:35:08 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-ed-507927bbdf77
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7A.99.04547.BB729705; Sat, 13 Oct 2012 10:35:07 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 13 Oct 2012 10:35:07 +0200
From: Christer Holmberg 
To: Emil Ivov 
Date: Sat, 13 Oct 2012 10:35:06 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2oqy3NEMBva2wxTNWWv0TH6qhh8QAcZd7E
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8D@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>, <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, <5075FB20.6070408@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA74@ESESSCMS0356.eemea.ericsson.se> <5076B8E4.6050307@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BE3F450@ESESSCMS0356.eemea.ericsson.se> <50773B73.6060508@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCEF78@ESESSCMS0356.eemea.ericsson.se> <5077FE17.3010800@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BDCF1D9@ESESSCMS0356.eemea.ericsson.se>, <50782585.9070204@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA87@ESESSCMS0356.eemea.ericsson.se>, <50785E8A.7080903@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA88@ESESSCMS0356.eemea.ericsson.se>, <507867AB.70404@jitsi.org>
In-Reply-To: <507867AB.70404@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre5u9coAg90tShZrdk5gsZi6/DGL A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgytjzZR1bwTb+ipvbJzM3MM7h6WLk5JAQMJF4 fmw2I4QtJnHh3nq2LkYuDiGBU4wSfRvboZyFjBJ3X90Dcjg42AQsJLr/aYM0iAjIS3S3LWIC sZkFVCT23bsBNohFQFXi4oNJ7CC2sICixK3jm9gg6pUknj+fxAphG0k8n/8VrJ5XIFziz4o+ Vohd59kkjj4/zgKS4BRQl2joeAA2iBHouu+n1kAtE5e49WQ+E8TVAhJL9pxnhrBFJV4+/scK US8qcad9PSNEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYx CucmZuaklxvppRZlJhcX5+fpFaduYgTGzsEtv1V3MN45J3KIUZqDRUmc13rrHn8hgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjJv1nWZzJIkE62yRO3HJJGHK64h/q5SeHlcV2+56Nt2R4xbv hYL/hzLaPX51/hI/H+smxM/vsWPFi6zJVkZt5/nXXkjayV2zzqIr829W4knDKrd4tpj6u7Iv Nh2fuvqdvXn+nYT/F2O//OYKMkpIXb7/b1lAXaO9g2Tar/c9txtXXPlZM//TUyWW4oxEQy3m ouJEAIa8fJFrAgAA
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 08:35:16 -0000

Hi,

>>>>> My point was that Bobs IP address being public:
>>>>>
>>>>> * does not mean it is the best option: VPN, tunnelling, and
>>>>> multiple interfaces can all generate public host IP addresses
>>>>> that are a lot less preferable to server reflexive ones. * does
>>>>> not even guarantee that it's reachable. Connectivity may be
>>>>> administratively prohibited, routes can be down.
>>>>
>>>> Alice CAN continue to gather candidates, in case there are
>>>> better ones. My question was why she needs to signal them to Bob
>>>> in a new offer, instead of simply start sending STUN checks
>>>> associated with the candidates? Bob will then process them as
>>>> peer reflexive candidates.
>>>
>>> She can do that of course. And she should. That's what trickling
>>> is about after all. But those checks may fail for the reasons above
>>> (second bullet) or simply because Bob has a firewall with
>>> endpoint-dependent filtering so it won't let Alice's packets come
>>> in unless Bob also starts sending packets to her.
>>>
>>> Does this make sense?
>>
>> Note that in my use-case Bob has a public IP address, and is an ICE
>> lite entity, so Bob won't send any STUN requests to Alice - only
>> reply to those received from Alice.
>
> Oh, I had missed the "Lite" part. Sorry about that.

I may not have made it very clear that I was talking about a "lite" entity,=
 which only provides a host candidate (no matter whether it supports trickl=
e or not)

> So, yes, right now I can't think of a good reason why Alice would continu=
e trickling after a successful check in this case.

Well, Alice can continue to collect local candidates. But, when she has the=
m, she doesn't need to send them to Bob in a new offer - she can simply sta=
rt using them.

The advantage is that it reduces the need for additional O/A transactions o=
n the wire, which is good, so I think it would be good to document it :)

Regards,

Christer=

From christer.holmberg@ericsson.com  Sat Oct 13 01:51:18 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C7D21F84F1 for ; Sat, 13 Oct 2012 01:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.824
X-Spam-Level: 
X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuQ5gBRyy-62 for ; Sat, 13 Oct 2012 01:51:17 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3E42E21F84AE for ; Sat, 13 Oct 2012 01:51:17 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-af-50792b82217c
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EE.47.17130.28B29705; Sat, 13 Oct 2012 10:51:14 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Sat, 13 Oct 2012 10:51:14 +0200
From: Christer Holmberg 
To: Bernard Aboba 
Date: Sat, 13 Oct 2012 10:48:40 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2o5Q/RAOkJ55O0TpaitQ/uJId22AAOnrt6
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8F@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrW6TdmWAwa3pFhb7l1xmtlizcwKL xdTlj1kcmD0e95xh81iy5CeTx/83gQHMUVw2Kak5mWWpRfp2CVwZH3Z9ZStYzl3Re+QbSwNj M2cXIweHhICJxJ//Dl2MnECmmMSFe+vZuhi5OIQETjFKnJy+EcpZyCjx6es7JpAGNgELie5/ 2iCmiICuxN8uIxCTWcBR4ttlRpAxLAKqEot/f2cCsYUFFCVuHd/EBmKLCChJPH8+iRXCNpL4 fuskWA2vQLhE94MXjBCb7jNK7Fg9G2wQp4CtxLSDB8BsRqDbvp9aA9bALCAucevJfCaImwUk luw5zwxhi0q8fPyPFaJeVOJO+3pGiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2F pGUWkpZZSFoWMLKsYhTOTczMSS8310stykwuLs7P0ytO3cQIjKSDW34b7GDcdF/sEKM0B4uS OK+e6n5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwuJhY6kXMzb5VPOmf4VGRrvOkMMQ1Z xUWHmEyTM8K8J8ld27T6ZP6s76ovVSfv2Xg7/eUPA5mjGYypsZ8/+J1b2zVH1KWRsZT/b7sh p1Tf2u5nKXN9Zi3avE/FkSMiY2q9aPMeyw3B3qJKYVN2hybcfH10ddrNlyE2DwLkl+/sqApk E9V4W6zEUpyRaKjFXFScCAAx96uhcgIAAA==
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 08:51:18 -0000

Hi,

Q1: Remote endpoint support (SIP):
-------------------------------------

>> You say that, before the first offer is sent, one SHOULD determine wheth=
er the remote endpoint supports trickle ICE.
>>
>> For SIP, you give RFC 3840 as an example. I am not sure how that will wo=
rk. Yes, you can use 3840 to request that the
>> offer is sent to an entity which supports trickle ICE (for that, btw, yo=
u will also need to define an option tag, or something=20
>> similar), but you cannot use it to determine whether the remote endpoint=
 supports trickle ICE. In addition, you typically=20
>> use 3840 at the same time when you send the initial offer.
>> Of course, you could use SIP OPTIONS. But, there are a number of issues =
related to that, and I don't think we want to=20
>> define a mechanism which relies on the usage of OPTIONS.
>
> I think the idea originated from the RFC 5768 use of sip.ice, such as in =
a Require header in an INVITE request, Contact header=20
> in a REGISTER request or OPTIONS response. Some of the scenarios mentione=
d there include gateway scenarios in Section 3.1.

Sure. SIP allows you to indicate support of features during registration, i=
t allows you to require support of features from the remote=20
peer when you send the INVITE, and it allows you to request that the INVITE=
 is routed towards a remote peer entity that supports
certain features.

Regards,

Christer=

From oej@edvina.net  Sat Oct 13 02:05:08 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF821F8534 for ; Sat, 13 Oct 2012 02:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDiYucTU7SuO for ; Sat, 13 Oct 2012 02:05:08 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 1659021F8510 for ; Sat, 13 Oct 2012 02:05:08 -0700 (PDT)
Received: from [192.168.40.19] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 51954754A8A7; Sat, 13 Oct 2012 09:05:07 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" 
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8F@ESESSCMS0356.eemea.ericsson.se>
Date: Sat, 13 Oct 2012 11:05:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EEA0674-8791-4A7B-AF07-086584E2A18E@edvina.net>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>,  <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8F@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg 
X-Mailer: Apple Mail (2.1499)
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 09:05:09 -0000

13 okt 2012 kl. 10:48 skrev Christer Holmberg =
:

> Hi,
>=20
> Q1: Remote endpoint support (SIP):
> -------------------------------------
>=20
>>> You say that, before the first offer is sent, one SHOULD determine =
whether the remote endpoint supports trickle ICE.
>>>=20
>>> For SIP, you give RFC 3840 as an example. I am not sure how that =
will work. Yes, you can use 3840 to request that the
>>> offer is sent to an entity which supports trickle ICE (for that, =
btw, you will also need to define an option tag, or something=20
>>> similar), but you cannot use it to determine whether the remote =
endpoint supports trickle ICE. In addition, you typically=20
>>> use 3840 at the same time when you send the initial offer.
>>> Of course, you could use SIP OPTIONS. But, there are a number of =
issues related to that, and I don't think we want to=20
>>> define a mechanism which relies on the usage of OPTIONS.
>>=20
>> I think the idea originated from the RFC 5768 use of sip.ice, such as =
in a Require header in an INVITE request, Contact header=20
>> in a REGISTER request or OPTIONS response. Some of the scenarios =
mentioned there include gateway scenarios in Section 3.1.
>=20
> Sure. SIP allows you to indicate support of features during =
registration, it allows you to require support of features from the =
remote=20
> peer when you send the INVITE, and it allows you to request that the =
INVITE is routed towards a remote peer entity that supports
> certain features.
>=20
Using that would require a failure, then a backoff to something that =
interoperates.

Using some sort of multipart/alternative attachment would be faster - =
but I am afraid that a lot of applications doesn't support it,=20
even though it's been a requirement in SIP since day one.

/O


From christer.holmberg@ericsson.com  Sat Oct 13 02:55:29 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAC121F8513 for ; Sat, 13 Oct 2012 02:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.824
X-Spam-Level: 
X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHBSLYOsScCs for ; Sat, 13 Oct 2012 02:55:28 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B8C5221F8514 for ; Sat, 13 Oct 2012 02:55:27 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-ab-50793a8ec68d
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D3.AA.17130.E8A39705; Sat, 13 Oct 2012 11:55:26 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Sat, 13 Oct 2012 11:55:26 +0200
From: Christer Holmberg 
To: "Olle E. Johansson" 
Date: Sat, 13 Oct 2012 11:51:24 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2pIdg5eqRDfzgBQ5OXcqaq8E3ICQABnZHP
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA91@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com> <5075864F.3030700@jitsi.org> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>,  <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8F@ESESSCMS0356.eemea.ericsson.se>, <3EEA0674-8791-4A7B-AF07-086584E2A18E@edvina.net>
In-Reply-To: <3EEA0674-8791-4A7B-AF07-086584E2A18E@edvina.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW6fVWWAweGz5hb7l1xmtpi6/DGL xcvVh5gdmD2mrV3J6vG45wybx5IlP5kCmKO4bFJSczLLUov07RK4Mh7sv8dcsFOoYtKxU4wN jA/4uhg5OSQETCRefV7EAmGLSVy4t56ti5GLQ0jgFKPE2Q39zBDOQkaJJWs2A2U4ONgELCS6 /2mDNIgIaEhc+HKFDcRmFgiU+L7iCzuIzSKgKjHl/AdWEFtYQFHi1vFNbBD1ShLPn09ihbCN JLp6FjKC2LwC4RKfXj1hgtj1iEniyqbFYIM4Bewk2j68ALMZga77fmoNE8QycYlbT+YzQVwt ILFkz3lmCFtU4uXjf6wQ9aISd9rXM0LU60gs2P0J6lBtiWULXzNDLBaUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjEK5yZm5qSXm+ulFmUmFxfn5+kVp25iBEbUwS2/DXYwbrovdohRmoNF SZxXT3W/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGrV6f3e6/fPPBv9iOQ3dTyoQa7o1a T+2jJme/MTnPv2FinVkoY4VGKJvoqzfy91Y8ktmSHnlv/7u21j9Siw6vz/FkVTs+7Vsi65nV cRI56XqiJ16EsenPemegfvjFG6kNova6xj4y/dYs8jE/T/A6ba28fvCx41zpaWe0siyzXquZ zjtYffiaEktxRqKhFnNRcSIAwySeB3YCAAA=
Cc: MMUSIC IETF WG 
Subject: Re: [MMUSIC] Trickle ICE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Oct 2012 09:55:29 -0000

Hi,

Q1: Remote endpoint support (SIP):
-------------------------------------

>>>> You say that, before the first offer is sent, one SHOULD determine whe=
ther the remote endpoint supports trickle ICE.
>>>>
>>>> For SIP, you give RFC 3840 as an example. I am not sure how that will =
work. Yes, you can use 3840 to request that the
>>>> offer is sent to an entity which supports trickle ICE (for that, btw, =
you will also need to define an option tag, or something
>>>> similar), but you cannot use it to determine whether the remote endpoi=
nt supports trickle ICE. In addition, you typically
>>>> use 3840 at the same time when you send the initial offer.
>>>> Of course, you could use SIP OPTIONS. But, there are a number of issue=
s related to that, and I don't think we want to
>>>> define a mechanism which relies on the usage of OPTIONS.
>>>
>>> I think the idea originated from the RFC 5768 use of sip.ice, such as i=
n a Require header in an INVITE request, Contact header
>>> in a REGISTER request or OPTIONS response. Some of the scenarios mentio=
ned there include gateway scenarios in Section 3.1.
>>
>> Sure. SIP allows you to indicate support of features during registration=
, it allows you to require support of features from the remote
>> peer when you send the INVITE, and it allows you to request that the INV=
ITE is routed towards a remote peer entity that supports
>> certain features.
>>
> Using that would require a failure, then a backoff to something that inte=
roperates.

Exactly.

> Using some sort of multipart/alternative attachment would be faster - but=
 I am afraid that a lot of applications doesn't support it,
> even though it's been a requirement in SIP since day one.

Not sure how multipart would help. The idea of trickle is that, when you se=
nd the offer, you only have the host candidates, so you can't send one "tri=
ckle" offer, and an alternative "non-trickle" offer, because you don't have=
 any additional candidates to put into the non-trickle offer :)

Of course, the alternative could be without candidates all together, but th=
en we would have to assume that the remote legacy peer still includes candi=
dates in the answer, and start listening for STUN checks from the offerer. =
I think that would be a very unlikely scenario :)

Regards,

Christer=

From harald@alvestrand.no  Mon Oct 15 04:33:04 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9311E809B for ; Mon, 15 Oct 2012 04:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.336
X-Spam-Level: 
X-Spam-Status: No, score=-110.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GD-Xl0d76aC for ; Mon, 15 Oct 2012 04:33:03 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BE75011E809A for ; Mon, 15 Oct 2012 04:33:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 499C239E149 for ; Mon, 15 Oct 2012 13:33:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09rxBRojt8IM for ; Mon, 15 Oct 2012 13:32:59 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D45FD39E127 for ; Mon, 15 Oct 2012 13:32:58 +0200 (CEST)
Message-ID: <507BF46A.7040400@alvestrand.no>
Date: Mon, 15 Oct 2012 13:32:58 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References:   
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090607070500010607000906"
Subject: Re: [MMUSIC] The floodgates are open
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 11:33:04 -0000

This is a multi-part message in MIME format.
--------------090607070500010607000906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/13/2012 02:44 AM, Bernard Aboba wrote:
> A receiver can stop responding to STUN binding requests. However, this will take a while to take effect and it is all or nothing.  With a sender-based congestion control scheme there may not be a way for the receiver to indicate a limit, and even in a receiver-based scheme TMMBR messages aren't acknowledged.
For TMMBR, that's wrong - TMMBR messages are supposed to result in a 
TMMBN being sent, even if the TMMBN shows a bandwidth that is not 
affected by the TMMBR.

RFC 5104 section 4.2.2.2:

    A TMMBN message SHALL be scheduled for transmission after the
    reception of a TMMBR message with an FCI entry identifying this media
    sender.  Only a single TMMBN SHALL be sent, even if more than one
    TMMBR message is received between the scheduling of the transmission
    and the actual transmission of the TMMBN message.  The TMMBN message
    indicates the bounding tuples and their owners at the time of
    transmitting the message.

But I'm not sure it matters in the scenario we're discussing.
Remember that the theory for voice hammer is that we're dealing with an adversary's Javascript running
in the sender's browser, but we're NOT dealing with a compromised browser (or the attacker could just send the
packets without bothering with any of this permission stuff).

If it's needed, it does show a requirement that we might want to carry through to RMCAT (that the recipient
will want to get an ack that the sender has agreed to abide by a certain bandwidth limit).

>
> On Oct 12, 2012, at 16:25, "Ted Hardie"  wrote:
>
>> So, possibly I am completely misunderstanding the state of play here,
>> but I thought that we had come to the understanding that ICE gave you
>> a boolean consent *for the length of the consent freshness*  (and that
>> we could (n theory, at least alter the length of the consent freshness
>> to handle the risk of voice-hammer style attacks).  In other words,
>> that boolean exposes you to risk only for the time of the consent
>> freshness, not for all time, and this mitigated the risk sufficiently.
>>
>> What have I missed?
>>
>> Ted
>>
>> On Fri, Oct 12, 2012 at 2:59 PM, Martin Thomson
>>  wrote:
>>> The consent that ICE provides is strictly Boolean.
>>>
>>> There is no way to distinguish between consent to receive 4kbps audio
>>> and 5Mbps video.  This creates an exposure for services and endpoints
>>> that support receipt of media, in particular contact centres and other
>>> services that are necessarily open to incoming sessions by default.
>>>
>>> This working group has an analogous problem.  The consent to entertain
>>> modifications to ICE did not stipulate any constraints on volume.
>>> Looking to exploit that shortcoming, Bernard and I have submitted a
>>> draft that addresses the protocol shortcoming:
>>>
>>> http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--------------090607070500010607000906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/13/2012 02:44 AM, Bernard Aboba
      wrote:

    

    

      
A receiver can stop responding to STUN binding requests. However, this will take a while to take effect and it is all or nothing.  With a sender-based congestion control scheme there may not be a way for the receiver to indicate a limit, and even in a receiver-based scheme TMMBR messages aren't acknowledged.

    

    For TMMBR, that's wrong - TMMBR messages are supposed to result in a
    TMMBN being sent, even if the TMMBN shows a bandwidth that is not
    affected by the TMMBR.

    

    RFC 5104 section 4.2.2.2:

    

    
    
   A TMMBN message SHALL be scheduled for transmission after the
   reception of a TMMBR message with an FCI entry identifying this media
   sender.  Only a single TMMBN SHALL be sent, even if more than one
   TMMBR message is received between the scheduling of the transmission
   and the actual transmission of the TMMBN message.  The TMMBN message
   indicates the bounding tuples and their owners at the time of
   transmitting the message.

But I'm not sure it matters in the scenario we're discussing.
Remember that the theory for voice hammer is that we're dealing with an adversary's Javascript running
in the sender's browser, but we're NOT dealing with a compromised browser (or the attacker could just send the
packets without bothering with any of this permission stuff).

If it's needed, it does show a requirement that we might want to carry through to RMCAT (that the recipient
will want to get an ack that the sender has agreed to abide by a certain bandwidth limit).



    

      

On Oct 12, 2012, at 16:25, "Ted Hardie" <ted.ietf@gmail.com> wrote:



      

        
So, possibly I am completely misunderstanding the state of play here,
but I thought that we had come to the understanding that ICE gave you
a boolean consent *for the length of the consent freshness*  (and that
we could (n theory, at least alter the length of the consent freshness
to handle the risk of voice-hammer style attacks).  In other words,
that boolean exposes you to risk only for the time of the consent
freshness, not for all time, and this mitigated the risk sufficiently.

What have I missed?

Ted

On Fri, Oct 12, 2012 at 2:59 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:


        

          
The consent that ICE provides is strictly Boolean.

There is no way to distinguish between consent to receive 4kbps audio
and 5Mbps video.  This creates an exposure for services and endpoints
that support receipt of media, in particular contact centres and other
services that are necessarily open to incoming sessions by default.

This working group has an analogous problem.  The consent to entertain
modifications to ICE did not stipulate any constraints on volume.
Looking to exploit that shortcoming, Bernard and I have submitted a
draft that addresses the protocol shortcoming:

http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


        

        
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


      

      
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


    

    

  


--------------090607070500010607000906--

From internet-drafts@ietf.org  Mon Oct 15 05:12:21 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B94911E80A2; Mon, 15 Oct 2012 05:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3t5W0ACGYBp; Mon, 15 Oct 2012 05:12:20 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C970D11E808A; Mon, 15 Oct 2012 05:12:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121015121220.26750.82153.idtracker@ietfa.amsl.com>
Date: Mon, 15 Oct 2012 05:12:20 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g273-g729-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 12:12:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Offer/Answer Considerations for G.723 Annex A and G.729 =
Annex B
	Author(s)       : Muthu Arul Mozhi Perumal
                          Parthasarathi Ravindran
	Filename        : draft-ietf-mmusic-sdp-g273-g729-00.txt
	Pages           : 8
	Date            : 2012-10-14

Abstract:
   [RFC4856] describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the SDP offer and
   answer.  This document provides the offer/answer considerations for
   these parameters and updates [RFC4856].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g273-g729

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g273-g729-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From harald@alvestrand.no  Mon Oct 15 07:04:43 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA721F86EF for ; Mon, 15 Oct 2012 07:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.351
X-Spam-Level: 
X-Spam-Status: No, score=-110.351 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXaraqcnIfur for ; Mon, 15 Oct 2012 07:04:42 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C025521F8525 for ; Mon, 15 Oct 2012 07:04:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0812239E16A for ; Mon, 15 Oct 2012 16:04:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6NK1N0cR7Cv for ; Mon, 15 Oct 2012 16:04:39 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E292739E149 for ; Mon, 15 Oct 2012 16:04:38 +0200 (CEST)
Message-ID: <507C17F6.4070001@alvestrand.no>
Date: Mon, 15 Oct 2012 16:04:38 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic 
References: <20121015140339.24866.39463.idtracker@ietfa.amsl.com>
In-Reply-To: <20121015140339.24866.39463.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20121015140339.24866.39463.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------030507040305070503070406"
Subject: [MMUSIC] Fwd: New Version Notification for draft-alvestrand-mmusic-msid-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 14:04:43 -0000

This is a multi-part message in MIME format.
--------------030507040305070503070406
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I have updated the draft with some feedback from the discussion on the list.
There are no (intentional) changes to the actual technology of the 
mechanism.
Hopefully it is a little clearer  now.

              Harald


-------- Original Message --------
Subject: 	New Version Notification for draft-alvestrand-mmusic-msid-01.txt
Date: 	Mon, 15 Oct 2012 07:03:39 -0700
From: 	internet-drafts@ietf.org
To: 	harald@alvestrand.no



A new version of I-D, draft-alvestrand-mmusic-msid-01.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-alvestrand-mmusic-msid
Revision:	 01
Title:		 Cross Session Stream Identification in the Session Description Protocol
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-msid-01.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-mmusic-msid-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-alvestrand-mmusic-msid-01

Abstract:
    This document specifies a grouping mechanism for RTP media streams
    that can be used to specify relations between media streams within
    different RTP sessions.

    This mechanism is used to signal the association between the RTP
    concept of SSRC and the WebRTC concept of "media stream" / "media
    stream track" using SDP signalling.

    This document is an input document for discussion.  It should be
    discussed in the MMUSIC WG list, mmusic@ietf.org.


                                                                                   


The IETF Secretariat





--------------030507040305070503070406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    I have updated the draft with some feedback from the discussion on
    the list.

    There are no (intentional) changes to the actual technology of the
    mechanism.

    Hopefully it is a little clearer  now.

    

                 Harald

    


      

      -------- Original Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-alvestrand-mmusic-msid-01.txt
          

          

            Date: 
            Mon, 15 Oct 2012 07:03:39 -0700
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            harald@alvestrand.no
          

        
      

      

      

      
A new version of I-D, draft-alvestrand-mmusic-msid-01.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-alvestrand-mmusic-msid
Revision:	 01
Title:		 Cross Session Stream Identification in the Session Description Protocol
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-msid-01.txt
Status:          http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid
Htmlized:        http://tools.ietf.org/html/draft-alvestrand-mmusic-msid-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-alvestrand-mmusic-msid-01

Abstract:
   This document specifies a grouping mechanism for RTP media streams
   that can be used to specify relations between media streams within
   different RTP sessions.

   This mechanism is used to signal the association between the RTP
   concept of SSRC and the WebRTC concept of "media stream" / "media
   stream track" using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the MMUSIC WG list, mmusic@ietf.org.


                                                                                  


The IETF Secretariat



      

      

    

    

  


--------------030507040305070503070406--

From martin.thomson@gmail.com  Mon Oct 15 09:25:56 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4387B21F86C7 for ; Mon, 15 Oct 2012 09:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level: 
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNVnVjnqTRQw for ; Mon, 15 Oct 2012 09:25:55 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84A9021F86C3 for ; Mon, 15 Oct 2012 09:25:55 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so4005445lam.31 for ; Mon, 15 Oct 2012 09:25:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rFyfEd4X5yzAKyi+14Juu/LHWJWHITGOOSTokySUYj4=; b=WGDAJjXrGwBLsxUEbHW3HIo7+Eh5H8s0BRihD98jnBA/UCBHt7SOoeX0IIYa+20d7K teQ8dUDauvdLE//J9tc0gJCosTUptYehVeTa/AkCyacpuD6ZSxx5x7P9BP73/4gLayFQ 0fZF9UhtPypEidnC/QTEKXqjqhmJaxZXt9rKcZOx1QYbH0n8hRTBeniMhSsZIOemNEqI p74toDTWMrq6kOoRAL6p29NyQU0ekLcS+IePM71RDnCeLQX7e051N+23RcD0+RLHVpD7 ToChHoGcAhsu91sEjhrNmfZAuXXwa9UJ5Rq/DXf7DYk4eI6Eieowq1J+cfM5dcNsJZiA tptA==
MIME-Version: 1.0
Received: by 10.112.14.161 with SMTP id q1mr4423919lbc.123.1350318354474; Mon, 15 Oct 2012 09:25:54 -0700 (PDT)
Received: by 10.112.83.2 with HTTP; Mon, 15 Oct 2012 09:25:54 -0700 (PDT)
In-Reply-To: <507BF46A.7040400@alvestrand.no>
References:    <507BF46A.7040400@alvestrand.no>
Date: Mon, 15 Oct 2012 09:25:54 -0700
Message-ID: 
From: Martin Thomson 
To: Harald Alvestrand 
Content-Type: text/plain; charset=UTF-8
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] The floodgates are open
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 16:25:56 -0000

On 15 October 2012 04:32, Harald Alvestrand  wrote:
> For TMMBR, that's wrong - TMMBR messages are supposed to result in a TMMBN
> being sent, even if the TMMBN shows a bandwidth that is not affected by the
> TMMBR.

I'm glad that the TMMBR issue was raised.  I considered putting it in
the draft, but decided to keep my layers discrete.

An attacker does not need significant bandwidth in order to have the
RTCP sent to them.  Doubly true if they make it appear as though there
are lots of receivers in the RTP session.

(You might consider this further support for moving to DTLS-SRTP.)

> If it's needed, it does show a requirement that we might want to carry through to
> RMCAT (that the recipient will want to get an ack that the sender has agreed to
> abide by a certain bandwidth limit).

This specific issue was one raised in EKR's submission to the IAB
workshop.  It's a good requirement.  I don't know how realistic it is,
but it's definitely an important thing to try to address.

From martin.thomson@gmail.com  Mon Oct 15 09:33:58 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C216E21F867E for ; Mon, 15 Oct 2012 09:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.883
X-Spam-Level: 
X-Spam-Status: No, score=-3.883 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1m3+ACl57We for ; Mon, 15 Oct 2012 09:33:57 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66BB021F8666 for ; Mon, 15 Oct 2012 09:33:57 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so4012383lam.31 for ; Mon, 15 Oct 2012 09:33:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PBQ7V5Is/L+74Zfn3NsyLU/noLnIpAnGAAJhU0CWBMc=; b=w9F54Jocjyu+xN9zNtHCAGIVvnPQyTj3sBN3+GNqgI4KVMkKUo7+H+ae3fEwvIF2CO ohn8efgHm05pQHKATK3useQ6uWwh2jEmiQ9x0oMfFSrs1GV5DObPBIvNLdAlWBOGFwBU bQB+wVWjlYK2LdEvyldfixdJJ2JhYFc2s0rYrCPa9QuhygRDIdABPCnaavmSzhJc7aZV Hg/VKb+dSbYOFmTZ6XDjDUG/S2VyVJVqr8lb7efUDWcFJnVdLTr3wBhgo8z1lz3o2OXA JOWIP2injRjNOeeayLPUe3iyPWiYLL2rJ5QC6uLv8AiBhVYeoa+oVrGLeHOpV6WbXw+F +BoA==
MIME-Version: 1.0
Received: by 10.152.48.102 with SMTP id k6mr10306835lan.12.1350318834263; Mon, 15 Oct 2012 09:33:54 -0700 (PDT)
Received: by 10.112.83.2 with HTTP; Mon, 15 Oct 2012 09:33:54 -0700 (PDT)
In-Reply-To: 
References:   
Date: Mon, 15 Oct 2012 09:33:54 -0700
Message-ID: 
From: Martin Thomson 
To: Bernard Aboba 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] The floodgates are open
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 16:33:58 -0000

> On Oct 12, 2012, at 16:25, "Ted Hardie"  wrote:
>> What have I missed?
On 12 October 2012 17:44, Bernard Aboba  wrote:
> A receiver can stop responding to STUN binding requests. However, this will take a while to take effect and it is all or nothing.

With the current timing recommendations, the time between initial
consent and expiration of that consent is greater than 30 seconds
(consent expiration + ICE timers is approximately 35 seconds).  That
may be sufficient time to carry out an attack.

From internet-drafts@ietf.org  Mon Oct 15 13:41:00 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845D321F8A2F; Mon, 15 Oct 2012 13:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level: 
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZUWx9W6eCNi; Mon, 15 Oct 2012 13:41:00 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFA221F8A30; Mon, 15 Oct 2012 13:41:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121015204100.17198.68600.idtracker@ietfa.amsl.com>
Date: Mon, 15 Oct 2012 13:41:00 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 20:41:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Miscellanoues Capabilities Negotiation in the Session De=
scription Protocol (SDP)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
                          Robert R. Gilman
	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-02.txt
	Pages           : 19
	Date            : 2012-10-15

Abstract:
   SDP has been extended with a capability negotiation mechanism
   framework that allows the endpoints to negotiate transport protocols
   and attributes.  This framework has been extended with a media
   capabilities negotiation mechanism that allows endpoints to negotiate
   additional media-related capabilities.  This negotiation is embedded
   into the widely-used SDP offer/answer procedures.

   This memo extends the SDP capability negotiation framework to allow
   endpoints to negotiate three additional SDP capabilities.  In
   particular, this memo provides a mechanism to negotiate bandwidth
   ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line for
   each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps=
-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From miguel.a.garcia@ericsson.com  Mon Oct 15 13:46:26 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14221F89A2 for ; Mon, 15 Oct 2012 13:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.243
X-Spam-Level: 
X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wa22a-49QPP4 for ; Mon, 15 Oct 2012 13:46:25 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CD19721F899D for ; Mon, 15 Oct 2012 13:46:24 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-32-507c761fe1c0
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D2.8C.04547.F167C705; Mon, 15 Oct 2012 22:46:23 +0200 (CEST)
Received: from [159.107.51.88] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Oct 2012 22:46:22 +0200
Message-ID: <507C761D.1090804@ericsson.com>
Date: Mon, 15 Oct 2012 22:46:21 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <20121015204100.17198.68600.idtracker@ietfa.amsl.com>
In-Reply-To: <20121015204100.17198.68600.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvra58WU2Awd/dwhb/bn1itpi6/DGL xblPd1kcmD0mP57D6LFkyU8mj7u3LjEFMEdx2aSk5mSWpRbp2yVwZTy5fJu54LxwxfH5Jxgb GLfwdzFyckgImEgsPP+FBcIWk7hwbz1bFyMXh5DAKUaJBXP3sYMkhARWM0o83+8EYvMKaEus 2PWHGcRmEVCVuDr3ERuIzSZgLtG6cSNQPQeHqECwRNdhMYhyQYmTM5+AzRcREJaY8fYvWDmz QLTEricrweLCAoES+648YgRpFRJwlFh4rQQkzCngJHH6zwVWiHJbiQtzrrNA2PIS29/OYYa4 TFNi8s2lzBMYBWch2TYLScssJC0LGJlXMQrnJmbmpJcb6aUWZSYXF+fn6RWnbmIEhu7BLb9V dzDeOSdyiFGag0VJnNd66x5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwySmLR265F/dhS Lvr8UW+kcaiosFzEmnPHH3rGW8fFiwsvthH2cLGu53ixyrnSjen4iox7rUJMmmJi7uy+Fzdw nL6pejf7Zhi33emr+7oPVPRv1pDw0Fc9eujlicKeu9l6jGtmJCxxtfq6u5FpoU8C+46oI7fr D35Q/PMox/Tbz91v5k8V/6HEUpyRaKjFXFScCABCWDIQKwIAAA==
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 20:46:26 -0000

This version of the draft fixes an error detected by Flemming during the 
WGLC. The draft was missing the "["+"]" prefix in the "conn-config-list" 
(connection data parameter in 'lcfg' and 'pcfg' attributes) to indicate 
mandatory extensions.

So, the "["+"]" prefix has been added as well as an explanatory text in 
this connection data parameter.

The author believe the draft is now ready

/Miguel

On 15/10/2012 22:41, 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           : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP)
> 	Author(s)       : Miguel A. Garcia-Martin
>                            Simo Veikkolainen
>                            Robert R. Gilman
> 	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-02.txt
> 	Pages           : 19
> 	Date            : 2012-10-15
>
> Abstract:
>     SDP has been extended with a capability negotiation mechanism
>     framework that allows the endpoints to negotiate transport protocols
>     and attributes.  This framework has been extended with a media
>     capabilities negotiation mechanism that allows endpoints to negotiate
>     additional media-related capabilities.  This negotiation is embedded
>     into the widely-used SDP offer/answer procedures.
>
>     This memo extends the SDP capability negotiation framework to allow
>     endpoints to negotiate three additional SDP capabilities.  In
>     particular, this memo provides a mechanism to negotiate bandwidth
>     ('b=' line), connection data ('c=' line), and titles ('i=' line for
>     each session or media).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-caps-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From pkyzivat@alum.mit.edu  Mon Oct 15 14:10:42 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A673321F8A1D for ; Mon, 15 Oct 2012 14:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFv5ReKCQOTv for ; Mon, 15 Oct 2012 14:10:42 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A70ED21F89FF for ; Mon, 15 Oct 2012 14:10:41 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id BTWr1k04M1ap0As53ZAmPH; Mon, 15 Oct 2012 21:10:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id BZ6G1k0043ZTu2S3iZ6GXn; Mon, 15 Oct 2012 21:06:16 +0000
Message-ID: <507C7AA4.1010405@alum.mit.edu>
Date: Mon, 15 Oct 2012 17:05:40 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: IETF MMUSIC WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] Comments on draft-alvestrand-mmusic-msid-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Oct 2012 21:10:42 -0000

Harald,

I looked this over, and have a few observations:

Section 2, 1st paragraph

OLD:

    This document extends the Source-Specific Media Attributes framework
    [RFC5576] by adding a new "msid" attribute that can be used with the
    "a=ssrc" SDP attribute.  This new attribute allows endpoints to
    associate RTP media streams that are carried in different RTP
    sessions, as well as allowing application-specific information to the
    association.

The above suggests the mechanism is only for associating media streams 
in *different* sessions. But they can also be in the *same* session. So 
I would suggest:

NEW:

    This document extends the Source-Specific Media Attributes framework
    [RFC5576] by adding a new "msid" attribute that can be used with the
    "a=ssrc" SDP attribute.  This new attribute allows endpoints to
    associate RTP media streams that are carried in the same or
    different RTP sessions, as well as allowing application-specific
    information to the association.

Syntax:

      ; "attribute" is defined in RFC 4566.
      ; This attribute should be used with the ssrc-attr from RFC 5576.
      attribute =/ msid-attr
      msid-attr = "msid:" identifier [ " " appdata ]
      identifier = 1*64 ("0".."9" / "a".."z" / "-")
      appdata = 1*64 ("0".."9" / "a".."z" / "-")

Do you *really* want to allow identifiers like "-----", "---abc--" and 
"0---0--0-0"??? If these seem silly and error prone then the syntax 
could be made more restrictive.

If you *do* want to be this flexible, why not go further, and use 
 as defined in 4566 for both  and ?

Since it is recommended to generate the identifier via a random number 
generator, then why not define a representation that is a common 
encoding of an integer, such as hex or base64? The examples are 
obviously not generated this way. So maybe RECOMMENDED is too strong for 
use of random numbers. (It was offered as a possibility, but not 
recommended, in the prior version. Why the change?)

Section 3 - Msid-Semantic:

    The ABNF of msid-semantic is:

      attribute =/ msid-semantic-attr
      msid-semantic-attr = "msid-semantic:" " " identifier token
      token = 

Above appears broken - there is no separator between identifier and 
token. Presumably you meant:

      attribute =/ msid-semantic-attr
      msid-semantic-attr = "msid-semantic:" " " identifier " " token
      token = 

Also, the text isn't clear on the relationship between
a=msid-semantic:
a=ssrc-group:
a=group:

Are these all just *analogous* but independent mechanisms for grouping? 
Or is it intended that these can be used together to group things of all 
these types together?

RFC 5576 makes it clear that ssrc-group and group are analogous but 
independent with independent registries.

I find in the iana considerations section that msid-semantic is reusing 
the "Semantics for the "ssrc-group" SDP Attribute" registry, and 
registers "WMS" in that registry. So apparently one can use WMS with 
a=ssrc-group. That suggests it is intended that can be used together.

BUT, ssrc-group is a media level attribute. That implies that the 
namespace for ssrc-group tokens is independent for each media section in 
the SDP. But msid-semantic is session-wide. Using it would couple the 
namespaces of different media sections.

I don't know the answer here, but it at least needs clarification and 
may require some changes.

Section 4:

This section feels like it belongs in a separate draft. If it were 
non-normative then it might be ok as an example. But it is normative. 
The following clearly is:

    When an SDP description is updated, a specific msid continues to
    refer to the same media stream; an msid value MUST NOT be reused for
    another media stream within a PeerConnection's lifetime.

It isn't clear if that is intended only for WebRTC media streams. 
Hopefully so, since it is in a section scoped that way, and might not be 
desirable for all uses.

Even for this use that limitation is problematic. Anything that requires 
the generation of new SDP in a session to be aware of all the historical 
SDP in that session is problematic. It is easy to get situations 
(transfer, federation) where contributors to the SDP come and go without 
knowledge of history prior to their joining.

(This is already a problem in SDP with the requirement that a payload 
number can never be reused for a different codec within an RTP session. 
It is my impression that this is often violated, usually without problem.)

	Thanks,
	Paul

From rmohanr@cisco.com  Tue Oct 16 01:56:22 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A9B21F88AB for ; Tue, 16 Oct 2012 01:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFCunxbfGZcE for ; Tue, 16 Oct 2012 01:56:18 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA6321F8688 for ; Tue, 16 Oct 2012 01:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1722; q=dns/txt; s=iport; t=1350377778; x=1351587378; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=BmqkYmGv2pct4e/DecN9g6qhBG16Lty1VItLfbBWH2Q=; b=X5lk9Gf6zJYPxckB//RyPbj7SoByuVESxtwr06A3vJAXsQhXYg7uczZi PBFATWDtuXIua73wtIyq8/YaNUV6Msv+k2N5Y0OpKUqjPbR24on43UEnI 3S/Pdx8RFffZYccWAVVeAj/+12dXEhQpHmLwx26RocWeWzorMR720hM42 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAFQgfVCtJXG+/2dsb2JhbABFwBKBCIIgAQEBAwESASc9Bw0BCCIUQhsBBgMCBBMIARmHXAYLmhaBKI9akGKRJGADlwCNMIFrgm2CFw
X-IronPort-AV: E=Sophos;i="4.80,593,1344211200"; d="scan'208";a="132034400"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 16 Oct 2012 08:56:18 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9G8uILR022817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Oct 2012 08:56:18 GMT
Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 03:56:17 -0500
From: "Ram Mohan R (rmohanr)" 
To: "mmusic@ietf.org" 
Thread-Topic: New Version Notification for draft-reddy-mmusic-stun-auth-fw-traversal-00.txt
Thread-Index: AQHNq3waO7aij60gREC7F4cuLbkVkg==
Date: Tue, 16 Oct 2012 08:56:17 +0000
Message-ID: 
In-Reply-To: <20121015072602.2192.63285.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [173.39.64.72]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004
x-tm-as-result: No--30.140300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10F923FC59BF444DA544462C94487329@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-stun-auth-fw-traversal-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 08:56:22 -0000

Hi all,

This draft provides a way for firewalls to authenticate attempts to
initiate UDP flows from within an enterprise using extensions
to STUN protocol. This draft was earlier submitted to RTCWEB and the
authors were asked to take the discussion to MMUSIC WG by the AD.

Your comments are welcome.

Regards,
Authors



> On 15/10/12 12:56 PM, "internet-drafts@ietf.org"
> wrote:

>
>A new version of I-D, draft-reddy-mmusic-stun-auth-fw-traversal-00.txt
>has been successfully submitted by Ram Mohan Ravindranath and posted to
>the
>IETF repository.
>
>Filename:	 draft-reddy-mmusic-stun-auth-fw-traversal
>Revision:	 00
>Title:		 STUN Extensions for Firewall Traversal
>Creation date:	 2012-10-15
>WG ID:		 Individual Submission
>Number of pages: 13
>URL:            =20
>http://www.ietf.org/internet-drafts/draft-reddy-mmusic-stun-auth-fw-traver
>sal-00.txt
>Status:         =20
>http://datatracker.ietf.org/doc/draft-reddy-mmusic-stun-auth-fw-traversal
>Htmlized:       =20
>http://tools.ietf.org/html/draft-reddy-mmusic-stun-auth-fw-traversal-00
>
>
>Abstract:
>   Some networks deploy firewalls configured to block UDP traffic.  When
>   SIP user agents or WebRTC endpoints are deployed behind such
>   firewalls, media cannot be sent over UDP across the firewall, but
>   must be sent using TCP (which causes a different user experience) or
>   through a session border controller.
>
>   This draft describes an alternate model wherein extensions to ICE
>   connectivity checks can be examined by the firewall to permit
>   outgoing UDP flows across the firewall.
>
>                 =20
>       =20
>
>
>The IETF Secretariat
>
>



From capelastegui@dit.upm.es  Tue Oct 16 11:46:23 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A0F21F8A37 for ; Tue, 16 Oct 2012 11:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmTgZSwqV5PQ for ; Tue, 16 Oct 2012 11:46:20 -0700 (PDT)
Received: from mail.dit.upm.es (mail.dit.upm.es [IPv6:2001:720:1500:42:215:c5ff:fef6:86e4]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34C21F8A2D for ; Tue, 16 Oct 2012 11:46:19 -0700 (PDT)
Received: from correo2.dit.upm.es (correo.dit.upm.es [IPv6:2001:720:1500:42:250:56ff:fea2:7367]) by mail.dit.upm.es (8.14.2/8.14.2) with ESMTP id q9GIkAgO012610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 20:46:10 +0200
Received: from delta (delta.dit.upm.es [138.4.7.204]) (authenticated bits=0) by correo2.dit.upm.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q9GIk0WM018407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2012 20:46:06 +0200
From: "Pedro Capelastegui" 
To: "'Bert Greevenbosch'" , 
References: <46A1DF3F04371240B504290A071B4DB6290DBC01@szxeml509-mbs>
In-Reply-To: <46A1DF3F04371240B504290A071B4DB6290DBC01@szxeml509-mbs>
Date: Tue, 16 Oct 2012 20:46:02 +0200
Message-ID: <006b01cdabce$810b0c50$832124f0$@dit.upm.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01CDABDF.449C40C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHD8xWaSgFJmhAaarcJTjds3W0Do5fPtQ+w
Content-Language: es
Subject: Re: [MMUSIC] 3D drafts and their relevancy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 18:46:23 -0000

This is a multipart message in MIME format.

------=_NextPart_000_006C_01CDABDF.449C40C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

>> I would like to ask the group whether it believes it is beneficial to
continue specification of 3D in SDP/SIP?

 

I, too,  believe that a specification for 3D video is worth considering. 

 

>From an application standpoint, 3d video streaming and 3d video
calls/conferences should be viable in the near future, if they aren't
already. Regarding streaming, there's plenty of 3D content currently
available, with more created every day, and sales of 3D screens also seem to
be on the rise. 3D conferencing may have to wait a bit more,  since 3D
glasses and video calls don't work that well together, and the most popular
autostereoscopic device out there (the 3DS) is lacking a front-facing 3D
camera - but I'd say it's just a matter of time. 

 

Then there's the issue of the video formats. MVC is obviously appealing,
and its usage with SDP will be specified in
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-mvc/ . The
alternative formats described in Bert's draft and in mine (simulcast,
video+depth, frame-packing) are, by comparison, less sophisticated and
efficient, but not necessarily (as some have suggested) obsolete. Also, the
fact that some of them have been adopted by other standardization bodies
should be taken into account. 

 

Some comments on each individual 3D format:

-          Simulcast, or sending each video view as  an independent 2D video
stream over separate RTP sessions, is the trivial solution for transporting
3D video. It's bandwidth requirements are as inefficient as it gets, and
likely prohibitive for any system using 3+ views. On the upside, it is
fairly easy to implement,  is codec-independent, and doesn't require much
processing power (unlike more complex schemes like MVC). At the very least,
this should be a decent format for mobile 3D applications requiring 2 views.

-          Video plus depth, or sending one 2D video view along with a depth
map stream, is a standard format specified as MPEG-C part 3.  In this
format, the depth map video stream is transmitted as auxiliary data
encapsulated within the video stream for the base view. Video+depth is
backwards compatible, and falls between simulcast and MVC in terms of
complexity and efficiency.  

-          Frame-packing formats are used to multiplex 2 video views as a
single video stream. This is sometimes required to transmit 3D streams
through legacy equipment. The format is as inefficient as simulcast, and
introduces a loss of spatial or temporal resolution, due to the
multiplexing. Frame-packing has been adopted by the DVB 3DTV standard, and
is also used in HDMI. That said, I'm having a hard time finding a
justification for this format in a SIP environment, as it doesn't seem to
have a clear advantage over any of the alternatives.

It is important to note that a draft could specify just a subset of these
formats, if any of them is evaluated as not relevant enough.

 

Best regards,

Pedro

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
Bert Greevenbosch
Sent: Friday, October 12, 2012 8:20 AM
To: mmusic@ietf.org
Subject: [MMUSIC] 3D drafts and their relevancy

 

Hello all,

 

During the Vancouver meeting, the 3D drafts were briefly discussed:

 

http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-parallax/

http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-3d-format/

 

(I can't find them on the MMUSIC page anymore. Can the link be re-inserted,
as they have not been expired yet?)

 

During the discussion, there were some concerns about the relevancy of the
drafts, especially with the existence of MVC.

 

The frame packing formats have been adopted in HDMI 1.4a and DVB 3DTV
standards, both of which are quite recent. Also depth maps are gaining more
interest in the research community, as they provide a nice and concise way
to supply additional 3D information along with a 2D video stream.

 

Moreover, the drafts are not intended as an alternative to MVC. It is just
about providing signalling for codecs that are already in existence today.

 

I feel it would be a pity to stop working on 3D in SDP/SIP now. I believe
having SDP signalling would be quite helpful not just for one-directional
use cases, but especially also for 3D conversational use cases. The arrival
of the first 3D-glasses-free handhelds shows that comfortable 3D
conversation can be achieved in the near future.

 

I would like to ask the group whether it believes it is beneficial to
continue specification of 3D in SDP/SIP?

 

Thanks in advance for your opinions!

 

Best regards,

Bert


------=_NextPart_000_006C_01CDABDF.449C40C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


>> I would like to ask the group whether it believes =
it is beneficial to continue specification of 3D in =
SDP/SIP?
 
I, =
too,  believe that a specification for 3D video is worth =
considering. 
 
From an application standpoint, 3d video streaming and =
3d video calls/conferences should be viable in the near future, if they =
aren’t already. Regarding streaming, there’s plenty of 3D =
content currently available, with more created every day, and sales of =
3D screens also seem to be on the rise. 3D conferencing may have to wait =
a bit more,  since 3D glasses and video calls don’t work that =
well together, and the most popular autostereoscopic device out there =
(the 3DS) is lacking a front-facing 3D camera – but I’d say =
it’s just a matter of time. 
 
Then =
there’s the issue of the video formats. MVC is obviously =
appealing,  and its usage with SDP will be specified in htt=
ps://datatracker.ietf.org/doc/draft-ietf-payload-rtp-mvc/ . The =
alternative formats described in Bert’s draft and in mine =
(simulcast, video+depth, frame-packing) are, by comparison, less =
sophisticated and efficient, but not necessarily (as some have =
suggested) obsolete. Also, the fact that some of them have been adopted =
by other standardization bodies should be taken into account. =

 
Some comments on each individual 3D =
format:
-          =
Simulcast, or sending each video view as  =
an independent 2D video stream over separate RTP sessions, is the =
trivial solution for transporting 3D video. It’s bandwidth =
requirements are as inefficient as it gets, and likely prohibitive for =
any system using 3+ views. On the upside, it is fairly easy to =
implement,  is codec-independent, and doesn’t require much =
processing power (unlike more complex schemes like MVC). At the very =
least, this should be a decent format for mobile 3D applications =
requiring 2 views.
-          =
Video plus depth, or sending one 2D video view =
along with a depth map stream, is a standard format specified as MPEG-C =
part 3.  In this format, the depth map video stream is transmitted =
as auxiliary data encapsulated within the video stream for the base =
view. Video+depth is backwards compatible, and falls between simulcast =
and MVC in terms of complexity and efficiency.  
-          =
Frame-packing formats are used to multiplex 2 =
video views as a single video stream. This is sometimes required to =
transmit 3D streams through legacy equipment. The format is as =
inefficient as simulcast, and introduces a loss of spatial or temporal =
resolution, due to the multiplexing. Frame-packing has been adopted by =
the DVB 3DTV standard, and is also used in HDMI. That said, I’m =
having a hard time finding a justification for this format in a SIP =
environment, as it doesn’t seem to have a clear advantage over any =
of the alternatives.
It is important =
to note that a draft could specify just a subset of these formats, if =
any of them is evaluated as not relevant enough.
 
Best =
regards,
Pedro
 
 
From:=
 =
mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of =
Bert Greevenbosch
Sent: Friday, October 12, 2012 8:20 =
AM
To: mmusic@ietf.org
Subject: [MMUSIC] 3D drafts =
and their relevancy
 
Hello all,
 
During the Vancouver meeting, the 3D drafts were briefly =
discussed:
 
http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-par=
allax/
http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-sdp-3d=
-format/
 
(I can't find them on the MMUSIC page anymore. Can the link =
be re-inserted, as they have not been expired =
yet?)
 
During the discussion, there were some concerns about the =
relevancy of the drafts, especially with the existence of =
MVC.
 
The frame packing formats have been adopted in HDMI 1.4a =
and DVB 3DTV standards, both of which are quite recent. Also depth maps =
are gaining more interest in the research community, as they provide a =
nice and concise way to supply additional 3D information along with a 2D =
video stream.
 
Moreover, the drafts are not intended as an alternative to =
MVC. It is just about providing signalling for codecs that are already =
in existence today.
 
I feel it would be a pity to stop working on 3D in SDP/SIP =
now. I believe having SDP signalling would be quite helpful not just for =
one-directional use cases, but especially also for 3D conversational use =
cases. The arrival of the first 3D-glasses-free handhelds shows that =
comfortable 3D conversation can be achieved in the near =
future.
 
I would like to ask the group whether it believes it is =
beneficial to continue specification of 3D in =
SDP/SIP?
 
Thanks in advance for your =
opinions!
 
Best regards,
Bert

------=_NextPart_000_006C_01CDABDF.449C40C0--


From prvs=563600bf63=aallen@rim.com  Tue Oct 16 14:54:20 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7788421F863B for ; Tue, 16 Oct 2012 14:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.143
X-Spam-Level: 
X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoGyeDzld7or for ; Tue, 16 Oct 2012 14:54:18 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9F21F8622 for ; Tue, 16 Oct 2012 14:54:18 -0700 (PDT)
X-AuditID: 0a41282f-b7f4b6d000002cf7-55-507dd789d8d8
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 43.34.11511.987DD705; Tue, 16 Oct 2012 16:54:17 -0500 (CDT)
Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 16:54:17 -0500
From: Andrew Allen 
To: "Miguel A. Garcia" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-02.txt
Thread-Index: AQHNqxYoq2zcmwg9wEyqMMX6Hf67aZe8ew4A
Date: Tue, 16 Oct 2012 21:54:16 +0000
Message-ID: 
References: <20121015204100.17198.68600.idtracker@ietfa.amsl.com> <507C761D.1090804@ericsson.com>
In-Reply-To: <507C761D.1090804@ericsson.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.254]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXC5Zyvpdt5vTbA4MFVHYs1n1awW0xd/pjF gcnj19erbB5LlvxkCmCKamC0SUosKQvOTM/Tt7NJzMvLL0ksSVVISS1OtlXySU1PzFEIKMos S0yuVHDJLE7OSczMTS1SUshMsVUyUVIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5Cql5 yfkpmXnptkqewf66FhamlrqGSna6CZ08GVNePmQrWCBZse3sT7YGxgfCXYycHBICJhL7Lq1k g7DFJC7cWw9kc3EICaxklDi4ejYrhLOFUWLV2k0sIFVsAsoSy3/PYASxRQRiJLZ0rWAHsYUF giW+fm5jg4iHSOx4fpMVwjaSeHm3E6yGRUBV4vK0a0wgNq+Ah8SNzu1g9UICyRJXfhwDm8kp oCNxcG8/WA2jgKzE7rPXwWxmAXGJW0/mM0FcKiCxZM95ZghbVOLl43+sELaixLITJ9kg6nUk Fuz+BGVrSyxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRMDej2MDMIDkvWa8o M1cvL7VkEyMoIThq6O9gfPve4hCjAAejEg+v1YXaACHWxLLiytxDjBIczEoivOaNQCHelMTK qtSi/Pii0pzU4kOMFsBQmcgsxZ2cD0xWeSXxxgYGKBwlcV7jXSkBQgLpwCSTnZpakFoE08rE wQkymktKpBiYKlKLEktLMuJBCS2+GJjSpBoYj25ke8S1JuAlu/rFV/KvxY9sWrxMrs8hvSJt kUOZe3I9Y+u8c8VpV/YK8d1iKNLIfnxMU9hmjkW7VZw/Y96LlBP/V1prsF4J95oZ28z848+v 9BK2ael/b5gVF2z5My9jsmbvisS8tT/OK3K0b3z/3PL0kgXLps7Vd2byEJxx6tGNmdOPlW+M VmIpzkg01GIuKk4EAJcOla08AwAA
Subject: Re: [MMUSIC] I-D Action:	draft-ietf-mmusic-sdp-miscellaneous-caps-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Oct 2012 21:54:20 -0000

I have reviewed this and agree this is needed to align with RFC 5939. 

I think this is ready now

Andrew

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Miguel A. Garcia
> Sent: Monday, October 15, 2012 3:46 PM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-
> caps-02.txt
> 
> This version of the draft fixes an error detected by Flemming during the
> WGLC. The draft was missing the "["+"]" prefix in the "conn-config-list"
> (connection data parameter in 'lcfg' and 'pcfg' attributes) to indicate
> mandatory extensions.
> 
> So, the "["+"]" prefix has been added as well as an explanatory text in
> this connection data parameter.
> 
> The author believe the draft is now ready
> 
> /Miguel
> 
> On 15/10/2012 22:41, 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           : Miscellanoues Capabilities Negotiation in the
> Session Description Protocol (SDP)
> > 	Author(s)       : Miguel A. Garcia-Martin
> >                            Simo Veikkolainen
> >                            Robert R. Gilman
> > 	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-02.txt
> > 	Pages           : 19
> > 	Date            : 2012-10-15
> >
> > Abstract:
> >     SDP has been extended with a capability negotiation mechanism
> >     framework that allows the endpoints to negotiate transport
> protocols
> >     and attributes.  This framework has been extended with a media
> >     capabilities negotiation mechanism that allows endpoints to
> negotiate
> >     additional media-related capabilities.  This negotiation is
> embedded
> >     into the widely-used SDP offer/answer procedures.
> >
> >     This memo extends the SDP capability negotiation framework to
> allow
> >     endpoints to negotiate three additional SDP capabilities.  In
> >     particular, this memo provides a mechanism to negotiate bandwidth
> >     ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' lin=
e
> for
> >     each session or media).
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-
> caps
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-02
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-
> caps-02
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> >
> 
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From prvs=2637fee60e=aallen@rim.com  Tue Oct 16 17:31:31 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B416F1F0C49 for ; Tue, 16 Oct 2012 17:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.853
X-Spam-Level: 
X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeGlkxcfoouO for ; Tue, 16 Oct 2012 17:31:29 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id C66621F0C42 for ; Tue, 16 Oct 2012 17:31:28 -0700 (PDT)
X-AuditID: 0a41282f-b7f4b6d000002cf7-71-507dfc5f433e
Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id A8.16.11511.F5CFD705; Tue, 16 Oct 2012 19:31:28 -0500 (CDT)
Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 19:31:27 -0500
From: Andrew Allen 
To: "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-12.txt
Thread-Index: AQHNpTTgbvKy70XZ00K/u4QQ8BD0rZe8lWsg
Date: Wed, 17 Oct 2012 00:31:26 +0000
Message-ID: 
References: <20121008091021.2678.43639.idtracker@ietfa.amsl.com>
In-Reply-To: <20121008091021.2678.43639.idtracker@ietfa.amsl.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.67.110.251]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsXC5ZyvpZvwpzbA4OUXZoupyx+zODB6LFny kymAMaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SZ08mQ82/6bpeCGQsWFxQ+ZGxhXSnUxcnJICJhILF3wmBXCFpO4cG89Wxcj F4eQwEpGif7vy1kgnC2MEgvOzWQEqWITUJZY/nsGmC0ioC7xdW8PM4gtLOAo8fPgTSaIuJNE b2MzC4RtJHF/2h2wDSwCqhJzrj4FinNw8Ap4SBzcVAoSFhJwkJj1+Q87iM0JNGbLgc9grYwC shK7z14HG8ksIC5x68l8JohDBSSW7DnPDGGLSrx8/A/qAUWJGXvms0LU60gs2P2JDcLWlli2 8DVYPa+AoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUTA3o9jAzCA5L1mvKDNXLy+1ZBMj KPYdNfR3ML59b3GIUYCDUYmH98P72gAh1sSy4srcQ4wSHMxKIrzmjUAh3pTEyqrUovz4otKc 1OJDjBbAQJnILMWdnA9MS3kl8cYGBigcJXFe410pAUIC6cAUk52aWpBaBNPKxMEJMppLSqQY mChSixJLSzLiQeksvhiY0KQaGPeHaqXkfY0rkjCMlPA5LsTsXzbjEtsC9+8zPQ+eOMIwaU7X 4aoAmZnHfP49rtoT0K6wuEp0leQO7u2zE40ffL34bYXrf2bf1fUtB2ebSu/e/kn+kPKq71uv XVetmeHcl3NB6cvSnEPmawuLhSX2MNrpqbYkLLqirZuSolrhLagZwJVjMCm9S4mlOCPRUIu5 qDgRAAn953YxAwAA
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 00:31:31 -0000

I have reviewed this and have some minor editorial comments:


One NIT

5.6.2.  Generating the Answer

"The Answerer MUST also include its E.164 number of the "c=3D" line."

Shouldn't this be

"The Answerer MUST also include its E.164 number on the "c=3D" line."


Another comment on the new proposed text at the end of 5.6.2:

If the Answerer becomes the active party, generates an SDP answer,	and then=
 it finds out that the circuit-switched call cannot be established, then suc=
h endpoint MUST create a new SDP offer where circuit-switched stream is remo=
ved from the session (actually, by setting the corresponding port in the m=
=3D line to zero) and send it to its counter part. This is to synchronize bo=
th parties (and potential intermediaries) on the state of the session.

Instead of "then such endpoint MUST" why not state "then the Answerer MUST"


Also the proposed new text in 5.6.3:

Note that it if deliver of the Answer is delayed for some reason, the circui=
t-switched call may arrive at the Offerer before the Answer has been process=
ed. In this case, since the correlation mechanisms are negotiated as part of=
 the Offer/Answer exchange,the Answerer cannot know whether the incoming cal=
l attempt is correlated with the session being negotiated, the Offerer SHOUL=
D accept the call only after it has received and processed the Answer.

Propose to replace it with:

"Note that it if delivery of the Answer is delayed for some reason, the circ=
uit-switched call attempt may arrive at the Offerer before the Answer has be=
en processed. In this case, since the correlation mechanisms are negotiated=
 as part of the Offer/Answer exchange, the Answerer cannot know whether or n=
ot the incoming circuit-switched call attempt is correlated with the session=
 being negotiated, the Offerer SHOULD answer the circuit-switched call attem=
pt only after it has received and processed the Answer."

So that there is no ambiguity that we are talking about the circuit-switched=
 call attempt.

Also at the end of the security considerations section

"Additionally, it is strongly RECOMMENDED that the end user is asked for con=
sent prior to the endpoint initiating a circuit-switched connection which mi=
ght incur in charges.

Remove in from "incur in charges"

Andrew

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Monday, October 08, 2012 4:10 AM
> To: i-d-announce@ietf.org
> Cc: mmusic@ietf.org
> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-12.txt
> 
> 
> 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           : Session Description Protocol (SDP) Extension
> For Setting Up Audio and Video Media Streams Over Circuit-Switched
> Bearers In The Public Switched Telephone Network (PSTN)
> 	Author(s)       : Miguel A. Garcia-Martin
>                           Simo Veikkolainen
> 	Filename        : draft-ietf-mmusic-sdp-cs-12.txt
> 	Pages           : 37
> 	Date            : 2012-10-08
> 
> Abstract:
>    This memo describes use cases, requirements, and protocol extensions
>    for using the Session Description Protocol (SDP) Offer/Answer model
>    for establishing audio and video media streams over circuit-switched
>    bearers in the Public Switched Telephone Network (PSTN).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-12
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-12
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

From mperumal@cisco.com  Tue Oct 16 21:55:49 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3B321F871A for ; Tue, 16 Oct 2012 21:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ1+rTa2CRlP for ; Tue, 16 Oct 2012 21:55:48 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A67B421F8717 for ; Tue, 16 Oct 2012 21:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1957; q=dns/txt; s=iport; t=1350449748; x=1351659348; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ftOSlFhRpX8WVhUfDnGo3eO8Yc+pGZTX3IUNFGdxjdc=; b=RZ4Lc2ZYHgs/B3ITVuKybh8bM8U1I5lOnhSBwMEUjv7OV9UE+k2Fr8Nu tOsPTwOMeE/TSACQXSQaSFLfBlk/wvUC1aXJRg6foobr7AVRPyClVCEM7 rDskuLK/zUMOav1Nwct8cZAn1xj7YNlhHqxVIZMIz07gF/jgq93e+ZhIY E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANk5flCtJV2b/2dsb2JhbABFwCaBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUBwEBBQMCBBMIGodiC5saoCCLT4VgYAOXAI0ygWuCbYIX
X-IronPort-AV: E=Sophos;i="4.80,597,1344211200"; d="scan'208";a="132402765"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 17 Oct 2012 04:55:48 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9H4tm3L007132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Oct 2012 04:55:48 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 23:55:47 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" 
To: "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g273-g729-00.txt
Thread-Index: AQHNqs5bgk1o5S37DUCz2thrDjuzS5e86+ew
Date: Wed, 17 Oct 2012 04:55:46 +0000
Message-ID: 
References: <20121015121220.26750.82153.idtracker@ietfa.amsl.com>
In-Reply-To: <20121015121220.26750.82153.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.71.245]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004
x-tm-as-result: No--31.329000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] FW:  I-D Action: draft-ietf-mmusic-sdp-g273-g729-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 04:55:49 -0000

WG,=20

This draft provides the offer/answer considerations for the annexa paramete=
r of G723 and the annexb parameter of G729, G729D and G729E. We believe the=
 approach is in-line with existing specifications and pragmatic implementat=
ions.

Comments/questions welcome.

-- Muthu/Partha

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 internet-drafts@ietf.org
Sent: Monday, October 15, 2012 5:42 PM
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-g273-g729-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Offer/Answer Considerations for G.723 Annex A and G.729 =
Annex B
	Author(s)       : Muthu Arul Mozhi Perumal
                          Parthasarathi Ravindran
	Filename        : draft-ietf-mmusic-sdp-g273-g729-00.txt
	Pages           : 8
	Date            : 2012-10-14

Abstract:
   [RFC4856] describes the annexa parameter for G723 and the annexb
   parameter for G729, G729D and G729E. However, the specification does
   not describe the offerer and answerer behavior when the value of the
   annexa or annexb parameter does not match in the SDP offer and
   answer.  This document provides the offer/answer considerations for
   these parameters and updates [RFC4856].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-g273-g729

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-g273-g729-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

From miguel.a.garcia@ericsson.com  Wed Oct 17 11:12:03 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD0421F8682 for ; Wed, 17 Oct 2012 11:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.243
X-Spam-Level: 
X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIs2LAtdrWny for ; Wed, 17 Oct 2012 11:12:02 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 48B3B21F867C for ; Wed, 17 Oct 2012 11:12:02 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-47-507ef4f01ec1
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FF.DF.17130.0F4FE705; Wed, 17 Oct 2012 20:12:00 +0200 (CEST)
Received: from [159.107.51.88] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 17 Oct 2012 20:12:00 +0200
Message-ID: <507EF4EF.8090701@ericsson.com>
Date: Wed, 17 Oct 2012 20:11:59 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Miguel A. Garcia" 
References: <50742574.6080200@ericsson.com>
In-Reply-To: <50742574.6080200@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvre6HL3UBBos/6Fq8v6Brcayvi81i 6vLHLA7MHlcmXGH1mPJ7I6vHkiU/mQKYo7hsUlJzMstSi/TtErgyZs1oYi74y16xc8Vi1gbG 5WxdjJwcEgImEr9P3mOFsMUkLtxbDxYXEjjFKPH8QWoXIxeQvZpRYsvkxUwgCV4BbYlpM96A FbEIqEosWb+DEcRmEzCXaN24kb2LkYNDVCBYouuwGES5oMTJmU9YQGwRAVOJtllbwGxmgSKJ v9umgLUKC5hJTPr7gR1ir7bEvXf3wOKcAjoSz76fYIeot5W4MOc6VK+8xPa3c5gh6jUlJt9c yjyBUXAWknWzkLTMQtKygJF5FaNwbmJmTnq5uV5qUWZycXF+nl5x6iZGYOge3PLbYAfjpvti hxilOViUxHn1VPf7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDUET/Q1Xxp5zIpxy1qLFKd h1rfvFvLe/HdiS8n5rMIxSWKNGTMvK5+ruycY7PF3Sfh26/dV0wQSzfVSlxof+qsQsjMj+KS e9KXZ+4VZ+44vKMl3MJF58wPD6V7rdt2iNYpaZa9W8V47hDPcUtVNT+Gu0WRxcZfTFb3pPP/ zhTc4HHo7UWtJZOUWIozEg21mIuKEwFi8YLpKwIAAA==
Cc: Flemming Andreasen , mmusic 
Subject: Re: [MMUSIC] WG poll for consensus MSID draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 18:12:03 -0000

We have received clear indications that the MSID draft fills the need of 
RTCWEB. We have not received anyone being against it.

So, once we get a new milestone covering this work, we will request the 
authors to submit a new version as WG item.

    Flemming and Miguel (co-chairs)


On 09/10/2012 15:24, Miguel A. Garcia wrote:
> At the last IETF meeting we had a presentation of the following draft:
>
> http://datatracker.ietf.org/doc/draft-alvestrand-mmusic-msid/
>
> At that time, there was interest in solving the problem of cross session
> stream identification.
>
> We would like to poll the working group for consensus on adopting the
> above mentioned draft as a working group item, once we get an approved
> milestone.
>
> If you support this work or have problems with the adoption of this
> document as WG item, please indicate it by replying to this e-mail within
> the next 5 days.
>
> Flemming and Miguel (co-chairs)
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From miguel.a.garcia@ericsson.com  Wed Oct 17 12:59:59 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982A621F867C for ; Wed, 17 Oct 2012 12:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.243
X-Spam-Level: 
X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok2K7mpHjJ+N for ; Wed, 17 Oct 2012 12:59:59 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C1FC321F859B for ; Wed, 17 Oct 2012 12:59:58 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-f7-507f0e3de565
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E5.AA.04547.D3E0F705; Wed, 17 Oct 2012 21:59:57 +0200 (CEST)
Received: from [159.107.51.88] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 17 Oct 2012 21:59:56 +0200
Message-ID: <507F0E33.5040702@ericsson.com>
Date: Wed, 17 Oct 2012 21:59:47 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Bert Greevenbosch 
References: <46A1DF3F04371240B504290A071B4DB6290DBC01@szxeml509-mbs>
In-Reply-To: <46A1DF3F04371240B504290A071B4DB6290DBC01@szxeml509-mbs>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VteWrz7AoOmytMXvJytYLaYuf8zi wOTRcuQtq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDImbP3CUnCMpWL1un9sDYwnmbsYOTkkBEwk znb/ZIWwxSQu3FvP1sXIxSEkcIpRovHxKmYIZzWjxLk/R1hAqngFtCWeXOxhA7FZBFQlrnQ3 soPYbALmEq0bNwLZHByiAsESXYfFIMoFJU7OfALWKgK07F7nThaQEmYBdYmri4NAwsICxhKL tu1hBLGFBFwkzvd0gtmcAq4SMxuugm1iFrCVuDDnOguELS+x/e0cZoh6TYnJN5cyT2AUnIVk 2ywkLbOQtCxgZF7FKJybmJmTXm6kl1qUmVxcnJ+nV5y6iREYqAe3/FbdwXjnnMghRmkOFiVx Xuute/yFBNITS1KzU1MLUovii0pzUosPMTJxcEo1ME5c3LNzUwMz76t5H7eft1H5/3QZv0Nw rs79uvYUWZ5vc3y0M0Tctp39XXJyydTr8cvCav586PfsFQytsGs1uDXFLclj+8Z9R1lf/ziT dk0rrZJBO5u1la3zR7X10kLdaX4/A+OyGDb8XNShvrFpBbfNmSSWZPULTXkaBv8zt/ien510 SYv9nxJLcUaioRZzUXEiALqTOCYiAgAA
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 3D drafts and their relevancy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 19:59:59 -0000

On 12/10/2012 8:20, Bert Greevenbosch wrote:
> (I can't find them on the MMUSIC page anymore. Can the link be
> re-inserted, as they have not been expired yet?)
>

Hi Bert:

The MMUSIC web page is controlled by the IETF secretariat, and *I guess* 
it is mainly driven by a number of automatic scripts. I suspect these 
scripts might have deleted your drafts due to the mixture of WG items and 
non-WG items.

I will ask the secretariat to re-instantiate your drafts in the Related 
documents section.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From miguel.a.garcia@ericsson.com  Wed Oct 17 13:16:37 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED8521F847D for ; Wed, 17 Oct 2012 13:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.243
X-Spam-Level: 
X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wKTrxlUmlZa for ; Wed, 17 Oct 2012 13:16:36 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E564F21F84B6 for ; Wed, 17 Oct 2012 13:16:34 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-0f-507f1221fe63
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5D.C7.17130.1221F705; Wed, 17 Oct 2012 22:16:33 +0200 (CEST)
Received: from [159.107.51.88] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 17 Oct 2012 22:16:33 +0200
Message-ID: <507F1220.2050905@ericsson.com>
Date: Wed, 17 Oct 2012 22:16:32 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Bert Greevenbosch 
References: <46A1DF3F04371240B504290A071B4DB6290DBC01@szxeml509-mbs> <507F0E33.5040702@ericsson.com>
In-Reply-To: <507F0E33.5040702@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZGfG3VldRqD7A4OtyVYvfT1awWkxd/pjF gcmj5chbVo8lS34yBTBFcdmkpOZklqUW6dslcGVcPq9YcIWtomVjE2sD43zWLkZODgkBE4kF nevZIWwxiQv31rN1MXJxCAmcYpS4dqiXGSQhJLCaUWLp0SoQm1dAW+Lj2TNMXYwcHCwCqhLP tmqChNkEzCVaN25kBwmLCgRLdB0Wg6gWlDg58wkLiC0CtOpe504WkBJmAXWJq4uDQMLCAsYS i7btYYRYlCJxqX8y2GWcAjoSP0++BWtlFrCVuDDnOpQtL7H97RyowzQlJt9cyjyBUXAWkm2z kLTMQtKygJF5FaNwbmJmTnq5uV5qUWZycXF+nl5x6iZGYIge3PLbYAfjpvtihxilOViUxHn1 VPf7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk+PXIIU5DlMk83DTh/fLMrHtft/e/m5Ak 81DbImTiZJUzlRvclDbyM11Y7JbhdPXHow8/rHJMDd6KRHfcqVGVKruy7UJqb/gsqU4Grtmx 5u7Jqg2T9C7+Ff18d4nblCU/i+6d+OA/u+XMgcw3zgJPyvzCmB9mXrrJ37fm8e/cnRbXbC6n nEtSYinOSDTUYi4qTgQAVlW5Fx8CAAA=
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 3D drafts and their relevancy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Oct 2012 20:16:37 -0000

On 17/10/2012 21:59, Miguel A. Garcia wrote:
> On 12/10/2012 8:20, Bert Greevenbosch wrote:
>> (I can't find them on the MMUSIC page anymore. Can the link be
>> re-inserted, as they have not been expired yet?)
>>
>
> Hi Bert:
>
> The MMUSIC web page is controlled by the IETF secretariat, and *I guess*
> it is mainly driven by a number of automatic scripts. I suspect these
> scripts might have deleted your drafts due to the mixture of WG items and
> non-WG items.
>
> I will ask the secretariat to re-instantiate your drafts in the Related
> documents section.
>
> /Miguel

Bert,

it seems that both drafts expired recently, thus, they have disappeared. 
  Should new versions become available, they will be automatically added 
to the MMUSIC documents page.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From Bert.Greevenbosch@huawei.com  Wed Oct 17 18:21:17 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DC921F861A for ; Wed, 17 Oct 2012 18:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.539
X-Spam-Level: 
X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR0BrJe34CaF for ; Wed, 17 Oct 2012 18:21:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C348021F85D5 for ; Wed, 17 Oct 2012 18:21:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKS00889; Thu, 18 Oct 2012 01:21:15 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 02:20:38 +0100
Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 02:21:14 +0100
Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Thu, 18 Oct 2012 09:21:08 +0800
From: Bert Greevenbosch 
To: "Miguel A. Garcia" 
Thread-Topic: [MMUSIC] 3D drafts and their relevancy
Thread-Index: Ac2oQZ/12N4kT72LTemzS7XUlCIKYwEHUdGAAACVwgAAGyJVnA==
Date: Thu, 18 Oct 2012 01:21:07 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB6290E1525@szxeml509-mbs>
References: <46A1DF3F04371240B504290A071B4DB6290DBC01@szxeml509-mbs> <507F0E33.5040702@ericsson.com>,<507F1220.2050905@ericsson.com>
In-Reply-To: <507F1220.2050905@ericsson.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.99.205.88]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] 3D drafts and their relevancy
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2012 01:21:17 -0000

Hi Miguel,

Time flies! Indeed it turns out that the draft expired on 11 October. Then =
I'll submit new versions a.s.a.p.
Thanks for your feedback on the issue, and sorry for failing to notice the =
expiration!

Best regards,
Bert


________________________________________
From: Miguel A. Garcia [Miguel.A.Garcia@ericsson.com]
Sent: 18 October 2012 04:16
To: Bert Greevenbosch
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] 3D drafts and their relevancy

On 17/10/2012 21:59, Miguel A. Garcia wrote:
> On 12/10/2012 8:20, Bert Greevenbosch wrote:
>> (I can't find them on the MMUSIC page anymore. Can the link be
>> re-inserted, as they have not been expired yet?)
>>
>
> Hi Bert:
>
> The MMUSIC web page is controlled by the IETF secretariat, and *I guess*
> it is mainly driven by a number of automatic scripts. I suspect these
> scripts might have deleted your drafts due to the mixture of WG items and
> non-WG items.
>
> I will ask the secretariat to re-instantiate your drafts in the Related
> documents section.
>
> /Miguel

Bert,

it seems that both drafts expired recently, thus, they have disappeared.
  Should new versions become available, they will be automatically added
to the MMUSIC documents page.

/Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain=

From zhou.sujing@zte.com.cn  Wed Oct 17 23:42:47 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB7E21F85A4 for ; Wed, 17 Oct 2012 23:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.015
X-Spam-Level: 
X-Spam-Status: No, score=-100.015 tagged_above=-999 required=5 tests=[AWL=2.583, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBaMHZ9N1AbO for ; Wed, 17 Oct 2012 23:42:46 -0700 (PDT)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15521F85A0 for ; Wed, 17 Oct 2012 23:42:44 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 47DA730219 for ; Thu, 18 Oct 2012 14:42:40 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 5BB724B1227; Thu, 18 Oct 2012 14:39:38 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q9I6gUqL052037; Thu, 18 Oct 2012 14:42:30 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
To: ekr@rtfm.com, bernard_aboba@hotmail.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Thu, 18 Oct 2012 14:42:20 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-18 14:42:13, Serialize complete at 2012-10-18 14:42:13
Content-Type: multipart/alternative; boundary="=_alternative 0024EE6948257A9B_="
X-MAIL: mse02.zte.com.cn q9I6gUqL052037
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2012 06:42:47 -0000

This is a multipart message in MIME format.
--=_alternative 0024EE6948257A9B_=
Content-Type: text/plain; charset="US-ASCII"

Hi, Eric and Bernard,
 
 Sorry for the late reply, I somehow missed a lot of emails from the list.

 Concerning your commonts, I have the following responses:

 1. I agree SDES is not a secure solution in all kinds of key 
agreements/transportation protocols.
 2. The extension I proposed in the draft brings no more problem to the 
original SDES, the problem you
described is misleading. 
   Firstly, the key transportation in SDES is protected by other 
protocols, such as TLS, that is the important assumption.
         without the assumption, it is useless to discuss the security of 
SDES, how can you expect a protocol sending key in plaintext to be called 
secure?
         Under this assumption, the Proxy trying to modify the key does 
not exist, intermediate servers in the path are assumed trusted, the only 
possible Proxy attacker is 
         one of the forking terminals, if such a terminal triggers Alice 
into using an arbitrary key,  the key will be used between Alice and the 
attacker terminal.
 Secondly, the aim of SDES is to protect transported information in 
confidentialty and integrity, 
         in the original SDES, if no additional protection is to be 
applied to SDES, any one on path can see the key, and can obtain the 
plaintext, modify it.
         in the extensioned SDES, the attacker can modify the key of the 
sender, then what else he can obtain besides plaintext and modifying it? 
         Consider if one solution is more secure than another, I think the 
evaluation must be done according to the same goal. 
         An example: 
            the first case. a thief can get any key to  the door lock 
somehow, so the thief can get into the house any time;
            the second case. the thief is the door lock provider, and he 
obviously keeps a copy of any key he sells out. 
            Which one do you think is more weaker or more secure?
 
 

"
I agree.  Since the (only) major advantage of SDES is its widespread 
deployment,
it makes little sense to introduce patches that are unlikely to be widely 
implemented,
particularly when they introduce other security problems.   

> From: ekr at rtfm.com
> Date: Mon, 17 Sep 2012 09:29:33 -0700
> To: mmusic at ietf.org
> Subject: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01
> 
> This document describes an extension to SDES to address the fact that
> in the case of retargeting/forking multiple targets get to see the
> SDES key which the offerer will use for sending data. The proposal
> here is to add an extension which can be sent by the answerer to
> modify the key provided by the offerer.
> 
> 
> This whole line of development doesn't seem like a very good idea.
> During the RTPSEC work, we considered this problem and a bunch of
> related problems with SDES (e.g., early media) and concluded that a
> media-plane key establishment protocol was the right approach to
> addressing this problem, among others. I don't see a lot of point in
> doing piecemeal patches to SDES in an attempt to band-aid it's
> fundamental problems.
> 
> 
> This particular design seems particularly problematic in that
> it allows an on-path proxy to force the offerer into using a
> specific key. The general pattern would look like this:
> 
> Alice Proxy Bob
> 
> OFFER with K1 + keymod --->
> OFFER w/ K2 ------------>
> <----------------- ANSWER
> <- ANSWER with Keymod for K2
> 
> 
> With conventional SDES, the proxy gets to see the SDES key but
> not to modify it. Obviously, he can change the key in flight,
> but the sender will still use the old key. This design would
> further weaken even the limited set of protections provided
> by SDES.
> 
> 
> -Ekr
"
--=_alternative 0024EE6948257A9B_=
Content-Type: text/html; charset="US-ASCII"



Hi, Eric and Bernard,

  

 Sorry for the late reply, I somehow
missed a lot of emails from the list.



 Concerning your commonts, I have
the following responses:



 1. I agree SDES is not a secure
solution in all kinds of key agreements/transportation protocols.

 2. The extension I proposed in
the draft brings no more problem to the original SDES, the problem you

described is misleading. 

   Firstly, the key transportation
in SDES is protected by other protocols, such as TLS, that is the important
assumption.

         without
the assumption, it is useless to discuss the security of SDES, how can
you expect a protocol sending key in plaintext to be called secure?

         Under
this assumption, the Proxy trying to modify the key does not exist, intermediate
servers in the path are assumed trusted, the only possible Proxy attacker
is 

         one
of the forking terminals, if such a terminal triggers Alice into using
an arbitrary key,  the key will be used between Alice and the attacker
terminal.

 Secondly, the aim of SDES is to
protect transported information in confidentialty and integrity, 

         in
the original SDES, if no additional protection is to be applied to SDES,
any one on path can see the key, and can obtain the plaintext, modify it.

         in
the extensioned SDES, the attacker can modify the key of the sender, then
what else he can obtain besides plaintext and modifying it? 

         Consider
if one solution is more secure than another, I think the evaluation must
be done according to the same goal. 

         An
example: 

           
the first case. a thief can get any key to  the door lock somehow,
so the thief can get into the house any time;

           
the second case. the thief is the door lock provider, and he obviously
keeps a copy of any key he sells out. 

           
Which one do you think is more weaker or more secure?

           

        



"




I agree.  Since the (only) major advantage
of SDES is its widespread deployment,

it makes little sense to introduce patches that are unlikely to be widely
implemented,

particularly when they introduce other security problems.   



> From: ekr at rtfm.com

> Date: Mon, 17 Sep 2012 09:29:33 -0700

> To: mmusic at ietf.org

> Subject: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01

> 

> This document describes an extension to SDES to address the fact that

> in the case of retargeting/forking multiple targets get to see the

> SDES key which the offerer will use for sending data. The proposal

> here is to add an extension which can be sent by the answerer to

> modify the key provided by the offerer.

> 

> 

> This whole line of development doesn't seem like a very good idea.

> During the RTPSEC work, we considered this problem and a bunch of

> related problems with SDES (e.g., early media) and concluded that
a

> media-plane key establishment protocol was the right approach to

> addressing this problem, among others. I don't see a lot of point
in

> doing piecemeal patches to SDES in an attempt to band-aid it's

> fundamental problems.

> 

> 

> This particular design seems particularly problematic in that

> it allows an on-path proxy to force the offerer into using a

> specific key. The general pattern would look like this:

> 

> Alice Proxy Bob

> 

> OFFER with K1 + keymod --->

> OFFER w/ K2 ------------>

> <----------------- ANSWER

> <- ANSWER with Keymod for K2

> 

> 

> With conventional SDES, the proxy gets to see the SDES key but

> not to modify it. Obviously, he can change the key in flight,

> but the sender will still use the old key. This design would

> further weaken even the limited set of protections provided

> by SDES.

> 

> 

> -Ekr


"
--=_alternative 0024EE6948257A9B_=--

From miguel.a.garcia@ericsson.com  Thu Oct 18 01:43:00 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9A021F8599 for ; Thu, 18 Oct 2012 01:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.244
X-Spam-Level: 
X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skU-enHUsnwO for ; Thu, 18 Oct 2012 01:42:59 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A296721F8532 for ; Thu, 18 Oct 2012 01:42:56 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-ba-507fc10e8104
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 19.51.11467.E01CF705; Thu, 18 Oct 2012 10:42:55 +0200 (CEST)
Received: from [10.1.2.9] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Oct 2012 10:42:54 +0200
Message-ID: <507FC10D.60500@ericsson.com>
Date: Thu, 18 Oct 2012 10:42:53 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+JvrS7/wfoAg75TvBYXrz1kslizcwKL xfsLuhZzLz9nt5i6/DGLA6vHpsmb2Tym/N7I6rFkyU8mj/9vAgNYorhsUlJzMstSi/TtErgy tj88wFbwhbWi+9wp1gbGByxdjJwcEgImEifOXmKDsMUkLtxbD2RzcQgJnGKUeNN+ggXCWcYo 8XZzFzNIFa+ApsS7OSvAOlgEVCW6Oy6zgthsAuYSrRs3sncxcnCICgRLdB0WgygXlDg58wnY MhEBGYm9mzYzg8xkFpjEKPFq5ikmkISwgKXEj5k7wWxmAVuJC3Ous0DY8hLb384B2ysEtHfy zaXMExj5ZyGZOwtJyywkLQsYmVcxCucmZuaklxvqpRZlJhcX5+fpFaduYgSG6sEtv3V3MJ46 J3KIUZqDRUmclytpv7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxpm9Tz77xBgVJH0UXT5B QOvzB1lnliMsdt6xb/k0ogKUnCV3rwzeVN/+TGsCq1HrV2H1q59XH39n8GLOkoY1hvsDM27f uzBvcemM7/d1TZb7vmC8uOPbN/cXHf8bayZ+2ci749mE4O/LmyXUptlM27PwtbREepTL1zs5 10qa+89OaGRlKT+k8FuJpTgj0VCLuag4EQCrALoIIwIAAA==
Cc: Flemming Andreasen , Dan Wing 
Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2012 08:43:00 -0000

At the last IETF meeting we had a presentation of the following draft:

http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/

At that time, there was interest in adopting this document as WG item. We 
currently have a milestone to submit an informational document describing 
current practices in hosted NAT traversal, where this document fits.

We would like to poll the working group to reconfirm the consensus on 
adopting the above mentioned draft as a working group item.

If you support this work or have problems with the adoption of this 
document as WG item, please indicate it by replying to this e-mail within 
the next 5 days.

     Miguel and Flemming (co-chairs)
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From mperumal@cisco.com  Thu Oct 18 05:09:30 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389BB21F8510 for ; Thu, 18 Oct 2012 05:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKGTGOcppRSG for ; Thu, 18 Oct 2012 05:09:29 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3669F21F850B for ; Thu, 18 Oct 2012 05:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1275; q=dns/txt; s=iport; t=1350562169; x=1351771769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z0/a41c59nfXocwNPiW7NmdMYqZZFrj6IIax37qF+Gs=; b=cbt5thNIbxN4fCUbbjOI6Qb38F3l+++3+OAxJtkvyv+vxw/jOAfNGJq1 y/5ULVKJweE0A5F3lZX34Mk4hPgFKbrnGq3p1bx28Z8BoFOfjdNZh/09B UclR4ihs5L0k64QqFrYMWbHa3EtcV7SlYwswoqbC4IKYtNkPH8/Z/8qF2 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADbwf1CtJXG+/2dsb2JhbABFwD2BCIIgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIGodiC5wjoCiLWBqFSGADlwCNNIFrgm+BYzQ
X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="132975644"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 18 Oct 2012 12:09:28 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9IC9SEC011614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 12:09:28 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 07:09:28 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" 
To: "Miguel A. Garcia" , mmusic 
Thread-Topic: [MMUSIC] WG Poll for consensus on WG item: latching draft
Thread-Index: AQHNrQycKVslsQJzTEuZTFJ1AVGV6Je+97mQ
Date: Thu, 18 Oct 2012 12:09:28 +0000
Message-ID: 
References: <507FC10D.60500@ericsson.com>
In-Reply-To: <507FC10D.60500@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.39.67.39]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002
x-tm-as-result: No--35.175200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Flemming Andreasen \(fandreas\)" , "Dan Wing \(dwing\)" 
Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Oct 2012 12:09:30 -0000

I support it. I think it is quite informative.

Muthu

|-----Original Message-----
|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O=
f Miguel A. Garcia
|Sent: Thursday, October 18, 2012 2:13 PM
|To: mmusic
|Cc: Flemming Andreasen (fandreas); Dan Wing (dwing)
|Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft
|
|At the last IETF meeting we had a presentation of the following draft:
|
|http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/
|
|At that time, there was interest in adopting this document as WG item. We
|currently have a milestone to submit an informational document describing
|current practices in hosted NAT traversal, where this document fits.
|
|We would like to poll the working group to reconfirm the consensus on
|adopting the above mentioned draft as a working group item.
|
|If you support this work or have problems with the adoption of this
|document as WG item, please indicate it by replying to this e-mail within
|the next 5 days.
|
|     Miguel and Flemming (co-chairs)
|--
|Miguel A. Garcia
|+34-91-339-3608
|Ericsson Spain
|_______________________________________________
|mmusic mailing list
|mmusic@ietf.org
|https://www.ietf.org/mailman/listinfo/mmusic

From fandreas@cisco.com  Fri Oct 19 16:45:12 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6310D21F8834 for ; Fri, 19 Oct 2012 16:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kXnYXeX7bfu for ; Fri, 19 Oct 2012 16:45:11 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 30E6C21F882A for ; Fri, 19 Oct 2012 16:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33759; q=dns/txt; s=iport; t=1350690311; x=1351899911; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=PgJmzkVYLyQOvaYGqrlFEHkf07C5DhxX2mu9/WDkV1A=; b=jRvG8FkkhjVOknrMBJgu3zn3MNvMl2plKuGJz4NF2hf9OtZwXdH8hvFn 1qjiT33nMsLyegxdzFQxIp2xtYFxOrzQiZMvDDeb+HHNt/7qWvH+YOgtV aRrPfjjAfTms5DZLf6mbpaxXU6mXY5OHyefTjQB6XZZHKqNnQHJhOHflv E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnIGAF3lgVCrRDoJ/2dsb2JhbABFi3O1GYEIgiABAQEEAQEBDwEKSgcKEQsYCRYBAQ0JAwIBAgEVMAYBDAYCAQEFEgeHYQycGKALi1oKhmUDlW+OTYFrgws
X-IronPort-AV: E=Sophos;i="4.80,617,1344211200"; d="scan'208,217";a="61805382"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 19 Oct 2012 23:45:10 +0000
Received: from Flemmings-MacBook-Pro.local ([10.154.36.151]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9JNjAEq017437; Fri, 19 Oct 2012 23:45:10 GMT
Message-ID: <5081E606.8060300@cisco.com>
Date: Fri, 19 Oct 2012 19:45:10 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic , draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org
References: <505FD907.9070800@cisco.com> <50771F8D.8040004@cisco.com>
In-Reply-To: <50771F8D.8040004@cisco.com>
Content-Type: multipart/alternative; boundary="------------000405080305020007020602"
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-05
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Oct 2012 23:45:12 -0000

This is a multi-part message in MIME format.
--------------000405080305020007020602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The WGLC for the RTSP NAT Evaluation draft is now closed.

We will need resolution to the comments below and an updated document 
addressing them as the next steps before we can move forward.

Thanks

-- Flemming (MMUSIC co-chair)


On 10/11/12 3:35 PM, Flemming Andreasen wrote:
> I have reviewed the RTSP NAT Evaluation document and have several 
> comments on it, both technical and editorial. I will provide the main 
> technical comments below and send the minor and editorial comments 
> directly to the authors in a more "user-friendly" format.
>
>
> Major comments
>
> - STUN based on either RFC 3489 or RFC 5389 (or both). The draft 
> discusses use of STUN as a NAT traversal mechanism (with some RTSP 
> operational "extensions"), and in so doing it references both RFC 3489 
> (which is obsolete) and RFC 5389 (the replacement). Furthermore, in 
> several places, it bases and describes operation on now defunct 
> (obsolete) RFC 3489 logic and messages instead of RFC 5389. This 
> either needs to be rectified, or we should have a very good 
> explanation in the document as to why we are using RFC 3489 (and then 
> be clear which parts are based on RFC 3489 and which are based on RFC 
> 5389).
>
> - "Symmetric RTP" is called out as a potential solution for NAT 
> traversal with 3 different variations. Note that symmetric RTP is 
> defined in RFC 4961, and what is described in this document as 
> "symmetric RTP" looks a lot more like latching to me, with all the 
> potential issues that brings (and then some due to the shared use of 
> ports and hence shared SSRC space between different clients, as noted 
> in the document). The document needs to clear up its terminology in 
> this area ("connect", "binding", latch, symmetric RTP, etc.) and be 
> clearer about what is being proposed (which is latching as far as I 
> can tell, however it makes reference to certain mechanisms that aren't 
> fully described, e.g. binding packets with random nonces).
>
>
> Other significant comments
>
> - The draft intends to investigate and outline different RTSP NAT 
> traversal proposals with the goal of picking one for further detailed 
> specification (which can be found in the draft-ietf-mmusic-rtsp-nat 
> spec). There is a mixture of RFC 2119 language and more informal 
> language in several of these descriptions. Given that these are 
> high-level descriptions and have not been specified in detail, I do 
> not think we should give any other impression and hence I think RFC 
> 2119 language should be avoided.
>
> - The draft suggests that the RTSP server needs to enforce that 
> signaling and media come from the same IP-address as a security remedy 
> in several places, however this may not work with larger scale NATs 
> (e.g. carrier-grade NATs) where the NAT may be using more than one 
> external IP-address.
>
> - The comparison section is missing two of the alternatives considered 
> (namely ALG and TCP tunneling). Also, the comparison chart would lead 
> most people to a different solution than the one chosen. To some 
> extent, I think it's because the requirements list is a simplified 
> list of all the considerations behind each of the proposals (as more 
> fully explained in the document overall). There are additional 
> drawbacks to some of these other solutions that do not show up in the 
> table (e.g. unauthenticated "latching" and requirement for RTSP server 
> to have public IP-address). It would be worthwhile briefly recapping 
> those and hence further motivate the choice of ICE in this section.
>
> Thanks
>
> -- Flemming
>
>
>
> On 9/23/12 11:52 PM, Flemming Andreasen wrote:
>> This is to announce a 2 week Working Group Last Call for
>>
>>     draft-ietf-mmusic-rtsp-nat-evaluation-05
>>
>> as Informational. Please review and provide any comments you may have 
>> on the document by October 7, 2012. Comments should be sent to the 
>> document authors and the MMUSIC WG list. If you review the document 
>> but do not have any comments, please send a note to that effect as well.
>>
>>
>> Thanks
>>
>>        Flemming
>>
>>
>>
>> Draft Info:
>>
>> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>>
>> 	Title           : The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
>> 	Author(s)       : Magnus Westerlund
>>                            Thomas Zeng
>> 	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
>> 	Pages           : 38
>> 	Date            : 2012-05-07
>>
>>     This document describes several Network Address Translator (NAT)
>>     traversal techniques that was considered to be used by Real-time
>>     Streaming Protocol (RTSP).  Each technique includes a description on
>>     how it would be used, the security implications of using it and any
>>     other deployment considerations it has.  There are also disussions on
>>     how NAT traversal techniques relates to firewalls and how each
>>     technique can be applied in different use cases.  These findings
>>     where used when selecting the NAT traversal for RTSP 2.0 standardized
>>     in the MMUSIC WG.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--------------000405080305020007020602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    The WGLC for the RTSP NAT Evaluation draft is now closed.

    

    We will need resolution to the comments below and an updated
    document addressing them as the next steps before we can move
    forward. 

    

    Thanks 

    

    -- Flemming (MMUSIC co-chair)

    

    

    
On 10/11/12 3:35 PM, Flemming Andreasen
      wrote:

    

    

      
      I have reviewed the RTSP NAT Evaluation document and have several
      comments on it, both technical and editorial. I will provide the
      main technical comments below and send the minor and editorial
      comments directly to the authors in a more "user-friendly" format.
      

      

      

      Major comments

      

      - STUN based on either RFC 3489 or RFC 5389 (or both). The draft
      discusses use of STUN as a NAT traversal mechanism (with some RTSP
      operational "extensions"), and in so doing it references both RFC
      3489 (which is obsolete) and RFC 5389 (the replacement).
      Furthermore, in several places, it bases and describes operation
      on now defunct (obsolete) RFC 3489 logic and messages instead of
      RFC 5389. This either needs to be rectified, or we should have a
      very good explanation in the document as to why we are using RFC
      3489 (and then be clear which parts are based on RFC 3489 and
      which are based on RFC 5389). 

      

      - "Symmetric RTP" is called out as a potential solution for NAT
      traversal with 3 different variations. Note that symmetric RTP is
      defined in RFC 4961, and what is described in this document as
      "symmetric RTP" looks a lot more like latching to me, with all the
      potential issues that brings (and then some due to the shared use
      of ports and hence shared SSRC space between different clients, as
      noted in the document). The document needs to clear up its
      terminology in this area ("connect", "binding", latch, symmetric
      RTP, etc.) and be clearer about what is being proposed (which is
      latching as far as I can tell, however it makes reference to
      certain mechanisms that aren't fully described, e.g. binding
      packets with random nonces). 

      

      

      Other significant comments

      

      - The draft intends to investigate and outline different RTSP NAT
      traversal proposals with the goal of picking one for further
      detailed specification (which can be found in the
      draft-ietf-mmusic-rtsp-nat spec). There is a mixture of RFC 2119
      language and more informal language in several of these
      descriptions. Given that these are high-level descriptions and
      have not been specified in detail, I do not think we should give
      any other impression and hence I think RFC 2119 language should be
      avoided. 

      

      - The draft suggests that the RTSP server needs to enforce that
      signaling and media come from the same IP-address as a security
      remedy in several places, however this may not work with larger
      scale NATs (e.g. carrier-grade NATs) where the NAT may be using
      more than one external IP-address. 

      

      - The comparison section is missing two of the alternatives
      considered (namely ALG and TCP tunneling). Also, the comparison
      chart would lead most people to a different solution than the one
      chosen. To some extent, I think it's because the requirements list
      is a simplified list of all the considerations behind each of the
      proposals (as more fully explained in the document overall). There
      are additional drawbacks to some of these other solutions that do
      not show up in the table (e.g. unauthenticated "latching" and
      requirement for RTSP server to have public IP-address). It would
      be worthwhile briefly recapping those and hence further motivate
      the choice of ICE in this section. 

      

      Thanks 

      

      -- Flemming 

      

      

      

      
On 9/23/12 11:52 PM, Flemming
        Andreasen wrote:

      

      
 This is to announce a 2 week
                      Working Group Last Call for

        

            draft-ietf-mmusic-rtsp-nat-evaluation-05

                      

                      as Informational. Please review and provide any
                      comments you may have on the document by October
                      7, 2012. Comments should be sent to the document
                      authors and the MMUSIC WG list. If you review the
                      document but do not have any comments, please send
                      a note to that effect as well. 

                      

                      

                                    Thanks 

                                    

                                           Flemming

                                    

                                    

                                    

                                    Draft Info:

                                  

        
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
	Author(s)       : Magnus Westerlund
                          Thomas Zeng
	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-05.txt
	Pages           : 38
	Date            : 2012-05-07

   This document describes several Network Address Translator (NAT)
   traversal techniques that was considered to be used by Real-time
   Streaming Protocol (RTSP).  Each technique includes a description on
   how it would be used, the security implications of using it and any
   other deployment considerations it has.  There are also disussions on
   how NAT traversal techniques relates to firewalls and how each
   technique can be applied in different use cases.  These findings
   where used when selecting the NAT traversal for RTSP 2.0 standardized
   in the MMUSIC WG.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation/

        

                                  
        

        

        

        
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


      

      

      

      

      

      
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


    

    

  


--------------000405080305020007020602--

From internet-drafts@ietf.org  Sun Oct 21 02:25:23 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D45E21F894E; Sun, 21 Oct 2012 02:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K25Ah97q6HCu; Sun, 21 Oct 2012 02:25:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86A421F88CF; Sun, 21 Oct 2012 02:25:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121021092522.14772.24942.idtracker@ietfa.amsl.com>
Date: Sun, 21 Oct 2012 02:25:22 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-13.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Oct 2012 09:25:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Session Description Protocol (SDP) Extension For Setting=
 Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ=
ic Switched Telephone Network (PSTN)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
	Filename        : draft-ietf-mmusic-sdp-cs-13.txt
	Pages           : 37
	Date            : 2012-10-21

Abstract:
   This memo describes use cases, requirements, and protocol extensions
   for using the Session Description Protocol (SDP) Offer/Answer model
   for establishing audio and video media streams over circuit-switched
   bearers in the Public Switched Telephone Network (PSTN).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-13


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From miguel.a.garcia@ericsson.com  Sun Oct 21 02:26:39 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF6E21F88B0 for ; Sun, 21 Oct 2012 02:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.944
X-Spam-Level: 
X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GcS9yR08f0p for ; Sun, 21 Oct 2012 02:26:38 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63121F889B for ; Sun, 21 Oct 2012 02:26:38 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-bd-5083bfcc3ec1
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 54.B1.17130.CCFB3805; Sun, 21 Oct 2012 11:26:37 +0200 (CEST)
Received: from [159.107.48.144] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Sun, 21 Oct 2012 11:26:36 +0200
Message-ID: <5083BFCA.90304@ericsson.com>
Date: Sun, 21 Oct 2012 11:26:34 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Andrew Allen 
References: <20121008091021.2678.43639.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vvfs/uYAgxNXuS2mdW5ltpi6/DGL A5PHkiU/mTwmfFnJEsAUxWWTkpqTWZZapG+XwJVxayFXwTKtirO/TzE3MB5S6mLk5JAQMJH4 evIaO4QtJnHh3nq2LkYuDiGBU4wSC4/uYodw1jBKHPowlbmLkYODV0BTYuYua5AGFgFVidaP 55lBbDYBc4nWjRvZQUpEBYIlug6LgYR5BQQlTs58wgJiiwgoSpw4PIMNpIRZQF3i6uIgkLCw gKPExwtvwE4QEqiVePXzCCOIzSngKXGw/w0riM0sYCtxYc51FghbXmL72znMEPWaEpNvLmWe wCg4C8m2WUhaZiFpWcDIvIpRODcxMye93FwvtSgzubg4P0+vOHUTIzBID275bbCDcdN9sUOM 0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwbiyaZVtgaLFGdptds/vUogpF s9f3LSombrzsIv3G8PfNbfn7mP5L3bfjsHbbsqKm/MbjiqqinfbvcqepLlp15rHlU8nn7PMF DzW8ulAQ+Pxx55IwxR/Lq1xuBj6Kv6ntOTOZR5S75GNpd/nUFQ+/nPv3++12jtM+AZJ5Bh8+ +cRN38ttHbv1mRJLcUaioRZzUXEiAChnLQYgAgAA
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Oct 2012 09:26:39 -0000

Hi Andrew,

thanks for your comments. I have accepted all your comments and submitted 
version -13:

http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/



See inline answers

On 17/10/2012 2:31, Andrew Allen wrote:
> I have reviewed this and have some minor editorial comments:
>
>
> One NIT
>
> 5.6.2.  Generating the Answer
>
> "The Answerer MUST also include its E.164 number of the "c=" line."
>
> Shouldn't this be
>
> "The Answerer MUST also include its E.164 number on the "c=" line."

Yes, fixed

>
>
> Another comment on the new proposed text at the end of 5.6.2:
>
> If the Answerer becomes the active party, generates an SDP answer,	and
> then it finds out that the circuit-switched call cannot be
> established, then such endpoint MUST create a new SDP offer where
> circuit-switched stream is removed from the session (actually, by
> setting the corresponding port in the m= line to zero) and send it to
> its counter part. This is to synchronize both parties (and potential
> intermediaries) on the state of the session.
>
> Instead of "then such endpoint MUST" why not state "then the Answerer
> MUST"
>

Yes, no problem. Fixed.

>
> Also the proposed new text in 5.6.3:
>
> Note that it if deliver of the Answer is delayed for some reason, the
> circuit-switched call may arrive at the Offerer before the Answer has
> been processed. In this case, since the correlation mechanisms are
> negotiated as part of the Offer/Answer exchange,the Answerer cannot
> know whether the incoming call attempt is correlated with the session
> being negotiated, the Offerer SHOULD accept the call only after it has
> received and processed the Answer.
>
> Propose to replace it with:
>
> "Note that it if delivery of the Answer is delayed for some reason,
> the circuit-switched call attempt may arrive at the Offerer before the
> Answer has been processed. In this case, since the correlation
> mechanisms are negotiated as part of the Offer/Answer exchange, the
> Answerer cannot know whether or not the incoming circuit-switched call
> attempt is correlated with the session being negotiated, the Offerer
> SHOULD answer the circuit-switched call attempt only after it has
> received and processed the Answer."

Fixed.

>
> So that there is no ambiguity that we are talking about the
> circuit-switched call attempt.
>
> Also at the end of the security considerations section
>
> "Additionally, it is strongly RECOMMENDED that the end user is asked
> for consent prior to the endpoint initiating a circuit-switched
> connection which might incur in charges.
>
> Remove in from "incur in charges"

I am ok with that. Fixed.



Thanks,

         Miguel



>
> Andrew
>
>> -----Original Message----- From: mmusic-bounces@ietf.org
>> [mailto:mmusic-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org Sent: Monday, October 08, 2012 4:10 AM To:
>> i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D
>> Action: draft-ietf-mmusic-sdp-cs-12.txt
>>
>>
>> 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           : Session Description Protocol (SDP) Extension For
>> Setting Up Audio and Video Media Streams Over Circuit-Switched
>> Bearers In The Public Switched Telephone Network (PSTN) Author(s)
>> : Miguel A. Garcia-Martin Simo Veikkolainen Filename        :
>> draft-ietf-mmusic-sdp-cs-12.txt Pages           : 37 Date
>> : 2012-10-08
>>
>> Abstract: This memo describes use cases, requirements, and protocol
>> extensions for using the Session Description Protocol (SDP)
>> Offer/Answer model for establishing audio and video media streams
>> over circuit-switched bearers in the Public Switched Telephone
>> Network (PSTN).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-12
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-cs-12
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________ mmusic mailing list
>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other
> than the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and
> delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
> _______________________________________________ mmusic mailing list
> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From miguel.a.garcia@ericsson.com  Sun Oct 21 08:29:38 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C5B21F8480 for ; Sun, 21 Oct 2012 08:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.24
X-Spam-Level: 
X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc3P2cmDaemP for ; Sun, 21 Oct 2012 08:29:38 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8663221F8477 for ; Sun, 21 Oct 2012 08:29:37 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-e9-508414dfd7de
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 33.1A.17130.FD414805; Sun, 21 Oct 2012 17:29:36 +0200 (CEST)
Received: from [159.107.48.144] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Sun, 21 Oct 2012 17:29:35 +0200
Message-ID: <508414DE.7070304@ericsson.com>
Date: Sun, 21 Oct 2012 17:29:34 +0200
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <20121021092522.14772.24942.idtracker@ietfa.amsl.com>
In-Reply-To: <20121021092522.14772.24942.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvre4DkZYAgwX7mC2mLn/MYnHu010W ByaPJUt+MnncvXWJKYApissmJTUnsyy1SN8ugSuj9dIntoJmvoodfy+yNzD2cXcxcnJICJhI fO86zARhi0lcuLeerYuRi0NI4BSjxJ5j85kgnDWMEj9XrmAEqeIV0JY4/fAhWAeLgKrEq5dP wWw2AXOJ1o0b2bsYOThEBYIlug6LQZQLSpyc+YQFxBYREJaY8fYvG4jNLGAsceLLMlYQW1jA UeLBgV1g44WA7Hk/f4LFOQWcJOZO/8EIUW8rcWHOdRYIW15i+9s5zBD1mhKTby5lnsAoOAvJ ullIWmYhaVnAyLyKUTg3MTMnvdxcL7UoM7m4OD9Przh1EyMwVA9u+W2wg3HTfbFDjNIcLEri vHqq+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLpcnd+TFLHpYNKXmE7uUNbPuSZm77Yl pVyb/lLWumVBwoxvbJytprcsp1ks+TFVPvauTQhf1EfHiqQXC15o+5laLTTJOiRlbinZfONn /sQdFt+M/3iJlT9bwqYvt+1I/8s/fG53DKYd2bDBPLSdPTjupWejapzOor2fZKsfxcuLzwt+ X7lvlxJLcUaioRZzUXEiAMBQMR0jAgAA
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-13.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Oct 2012 15:29:38 -0000

This version of the draft fixes a few editorials according to Andrew 
Allen's comments.

The authors believe the draft is complete and ready to request publication.

/Miguel

On 21/10/2012 11:25, 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           : Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)
> 	Author(s)       : Miguel A. Garcia-Martin
>                            Simo Veikkolainen
> 	Filename        : draft-ietf-mmusic-sdp-cs-13.txt
> 	Pages           : 37
> 	Date            : 2012-10-21
>
> Abstract:
>     This memo describes use cases, requirements, and protocol extensions
>     for using the Session Description Protocol (SDP) Offer/Answer model
>     for establishing audio and video media streams over circuit-switched
>     bearers in the Public Switched Telephone Network (PSTN).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-13
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-cs-13
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From harald@alvestrand.no  Sun Oct 21 12:54:56 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B0521F8894 for ; Sun, 21 Oct 2012 12:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.149
X-Spam-Level: 
X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k1kRfPGfyCW for ; Sun, 21 Oct 2012 12:54:55 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A5E6221F887A for ; Sun, 21 Oct 2012 12:54:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 664D239E13F for ; Sun, 21 Oct 2012 21:54:53 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3qQHYzycXUc for ; Sun, 21 Oct 2012 21:54:51 +0200 (CEST)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CB40D39E0E6 for ; Sun, 21 Oct 2012 21:54:51 +0200 (CEST)
Message-ID: <50845309.6000907@alvestrand.no>
Date: Sun, 21 Oct 2012 21:54:49 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <507C7AA4.1010405@alum.mit.edu>
In-Reply-To: <507C7AA4.1010405@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Comments on draft-alvestrand-mmusic-msid-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Oct 2012 19:54:56 -0000

Thanks for the review!


On 10/15/2012 11:05 PM, Paul Kyzivat wrote:
> Harald,
>
> I looked this over, and have a few observations:
>
> Section 2, 1st paragraph
>
> OLD:
>
>    This document extends the Source-Specific Media Attributes framework
>    [RFC5576] by adding a new "msid" attribute that can be used with the
>    "a=ssrc" SDP attribute.  This new attribute allows endpoints to
>    associate RTP media streams that are carried in different RTP
>    sessions, as well as allowing application-specific information to the
>    association.
>
> The above suggests the mechanism is only for associating media streams 
> in *different* sessions. But they can also be in the *same* session. 
> So I would suggest:
>
> NEW:
>
>    This document extends the Source-Specific Media Attributes framework
>    [RFC5576] by adding a new "msid" attribute that can be used with the
>    "a=ssrc" SDP attribute.  This new attribute allows endpoints to
>    associate RTP media streams that are carried in the same or
>    different RTP sessions, as well as allowing application-specific
>    information to the association.

Thanks, I'll change that. (Needed in the abstract too).

>
> Syntax:
>
>      ; "attribute" is defined in RFC 4566.
>      ; This attribute should be used with the ssrc-attr from RFC 5576.
>      attribute =/ msid-attr
>      msid-attr = "msid:" identifier [ " " appdata ]
>      identifier = 1*64 ("0".."9" / "a".."z" / "-")
>      appdata = 1*64 ("0".."9" / "a".."z" / "-")
>
> Do you *really* want to allow identifiers like "-----", "---abc--" and 
> "0---0--0-0"??? If these seem silly and error prone then the syntax 
> could be made more restrictive.
>
> If you *do* want to be this flexible, why not go further, and use 
>  as defined in 4566 for both  and ?

The list of "token" characters is

    token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                          / %x41-5A / %x5E-7E

or !#$%&'*+-./^_`{|}~ in addition to A-Za-z0-9.

Some of these are metacharacters in Javascript.
However, metacharacter exploits was the only reason I could see for 
restricting the syntax - "allows stuff that looks silly" doesn't seem to 
merit extra constraints.
Your mileage may vary; to some degree, it's a matter of taste.

>
> Since it is recommended to generate the identifier via a random number 
> generator, then why not define a representation that is a common 
> encoding of an integer, such as hex or base64?
The reason for this particular pick was that I couldn't see a reason to 
disallow either hex or UUIDs.
There's a few characters missing for Base64 (+ and /), so I obviously 
wasn't thinking of Base64 whenI wrote this text - if people want base64, 
we can add them.
> The examples are obviously not generated this way. So maybe 
> RECOMMENDED is too strong for use of random numbers. (It was offered 
> as a possibility, but not recommended, in the prior version. Why the 
> change?)
Because the more I thought about it, the more it seemed that collisions 
were a bad idea, and collisions are more likely for non-random IDs than 
for randomly generated IDs (for reasonable quality random number 
generators).

>
> Section 3 - Msid-Semantic:
>
>    The ABNF of msid-semantic is:
>
>      attribute =/ msid-semantic-attr
>      msid-semantic-attr = "msid-semantic:" " " identifier token
>      token = 
>
> Above appears broken - there is no separator between identifier and 
> token. Presumably you meant:
>
>      attribute =/ msid-semantic-attr
>      msid-semantic-attr = "msid-semantic:" " " identifier " " token
>      token = 
Thanks - I missed that.
>
> Also, the text isn't clear on the relationship between
> a=msid-semantic:
> a=ssrc-group:
> a=group:
>
> Are these all just *analogous* but independent mechanisms for 
> grouping? Or is it intended that these can be used together to group 
> things of all these types together?
That's because I'm not clear on what it should be.

There's a good reason to say that one can generate an SDP offer with 
both a=msid-semantic and  a=ssrc-group for the same semantic in the same 
offer, because this offers one-round-trip negotiation with both 
endpoints that understand a=msid-semantic and endpoints that only 
understand a=group, but since msid-semantic is able to express the 
semantics of a=ssrc-group, I don't see why a response should reply with 
both ssrc-group and msid-semantic for the same semantic.
>
> RFC 5576 makes it clear that ssrc-group and group are analogous but 
> independent with independent registries.
>
> I find in the iana considerations section that msid-semantic is 
> reusing the "Semantics for the "ssrc-group" SDP Attribute" registry, 
> and registers "WMS" in that registry. So apparently one can use WMS 
> with a=ssrc-group. That suggests it is intended that can be used 
> together.
>
> BUT, ssrc-group is a media level attribute. That implies that the 
> namespace for ssrc-group tokens is independent for each media section 
> in the SDP. But msid-semantic is session-wide. Using it would couple 
> the namespaces of different media sections.
I'm not clear what you want to say here. What namespaces would be 
coupled by msid-semantic?
Since ssrc-group doesn't have tokens (it's just ssrcs), it doesn't seem 
to define a namespace.
>
> I don't know the answer here, but it at least needs clarification and 
> may require some changes.

At least some clarification.
>
> Section 4:
>
> This section feels like it belongs in a separate draft. If it were 
> non-normative then it might be ok as an example. But it is normative. 
> The following clearly is:
It was the original purpose of the draft - the split into a general 
mechanism and a specific usage was done at the behest of MMUSIC. So yes, 
it's definitely intended to be normative.
>
>    When an SDP description is updated, a specific msid continues to
>    refer to the same media stream; an msid value MUST NOT be reused for
>    another media stream within a PeerConnection's lifetime.
>
> It isn't clear if that is intended only for WebRTC media streams. 
> Hopefully so, since it is in a section scoped that way, and might not 
> be desirable for all uses.
The limitation is defined in terms of WebRTC MediaStreams, not RTP media 
streams, so yes. I'll make sure to make the casing right, and add the 
qualifier.
>
> Even for this use that limitation is problematic. Anything that 
> requires the generation of new SDP in a session to be aware of all the 
> historical SDP in that session is problematic. It is easy to get 
> situations (transfer, federation) where contributors to the SDP come 
> and go without knowledge of history prior to their joining.

I don't think that it requires one to be aware of history in practice. 
It just requires that you either record history, or that the identifier 
contains enough randomness, and that the random number generator is run 
once for every new MediaStream.

>
> (This is already a problem in SDP with the requirement that a payload 
> number can never be reused for a different codec within an RTP 
> session. It is my impression that this is often violated, usually 
> without problem.)

I don't know the rules for that - can one renegotiate the codec 
parameters for a payload type, or are those too supposed to be locked down?

Of course this is much more problematic in multiparty sessions than in 
offer/answer negotiated sessions....
>
>     Thanks,
>     Paul
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From internet-drafts@ietf.org  Mon Oct 22 12:07:54 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C7711E8097; Mon, 22 Oct 2012 12:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level: 
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEiiI8fmZS9u; Mon, 22 Oct 2012 12:07:54 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D04821F842D; Mon, 22 Oct 2012 12:07:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121022190754.7463.41798.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2012 12:07:54 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2012 19:07:55 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : Stream Control Transmission Protocol (SCTP)-Based Media =
Transport in the Session Description Protocol (SDP)
	Author(s)       : Salvatore Loreto
                          Gonzalo Camarillo
	Filename        : draft-ietf-mmusic-sctp-sdp-02.txt
	Pages           : 13
	Date            : 2012-10-22

Abstract:
   SCTP (Stream Control Transmission Protocol) is a transport protocol
   used to establish associations between two endpoints.  This document
   describes how to express media transport over SCTP in SDP (Session
   Description Protocol).  This document defines the 'SCTP', 'SCTP/DTLS'
   and 'DTLS/SCTP' protocol identifiers for SDP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-sdp-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From pkyzivat@alum.mit.edu  Mon Oct 22 12:55:44 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B8B21F8512 for ; Mon, 22 Oct 2012 12:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.081
X-Spam-Level: 
X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyXU289E2Tnw for ; Mon, 22 Oct 2012 12:55:42 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 72C7621F8880 for ; Mon, 22 Oct 2012 12:55:41 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id EEg11k0031YDfWL51KvmSV; Mon, 22 Oct 2012 19:55:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id EKus1k0043ZTu2S3gKuszU; Mon, 22 Oct 2012 19:54:52 +0000
Message-ID: <5085A4BB.9040009@alum.mit.edu>
Date: Mon, 22 Oct 2012 15:55:39 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <507C7AA4.1010405@alum.mit.edu> <50845309.6000907@alvestrand.no>
In-Reply-To: <50845309.6000907@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Comments on draft-alvestrand-mmusic-msid-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2012 19:55:44 -0000

On 10/21/12 3:54 PM, Harald Alvestrand wrote:
...
>> Syntax:
>>
>>      ; "attribute" is defined in RFC 4566.
>>      ; This attribute should be used with the ssrc-attr from RFC 5576.
>>      attribute =/ msid-attr
>>      msid-attr = "msid:" identifier [ " " appdata ]
>>      identifier = 1*64 ("0".."9" / "a".."z" / "-")
>>      appdata = 1*64 ("0".."9" / "a".."z" / "-")
>>
>> Do you *really* want to allow identifiers like "-----", "---abc--" and
>> "0---0--0-0"??? If these seem silly and error prone then the syntax
>> could be made more restrictive.
>>
>> If you *do* want to be this flexible, why not go further, and use
>>  as defined in 4566 for both  and ?
>
> The list of "token" characters is
>
>     token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
>                           / %x41-5A / %x5E-7E
>
> or !#$%&'*+-./^_`{|}~ in addition to A-Za-z0-9.
>
> Some of these are metacharacters in Javascript.
> However, metacharacter exploits was the only reason I could see for
> restricting the syntax - "allows stuff that looks silly" doesn't seem to
> merit extra constraints.
> Your mileage may vary; to some degree, it's a matter of taste.
>
>> Since it is recommended to generate the identifier via a random number
>> generator, then why not define a representation that is a common
>> encoding of an integer, such as hex or base64?
> The reason for this particular pick was that I couldn't see a reason to
> disallow either hex or UUIDs.
> There's a few characters missing for Base64 (+ and /), so I obviously
> wasn't thinking of Base64 whenI wrote this text - if people want base64,
> we can add them.
>> The examples are obviously not generated this way. So maybe
>> RECOMMENDED is too strong for use of random numbers. (It was offered
>> as a possibility, but not recommended, in the prior version. Why the
>> change?)
> Because the more I thought about it, the more it seemed that collisions
> were a bad idea, and collisions are more likely for non-random IDs than
> for randomly generated IDs (for reasonable quality random number
> generators).

I don't understand what you are saying overall on the above.
ISTM that the draft should pick a direction. Either:

- mandate use of a random number. Then specify an encoding for it.
   I don't much care what encoding, but it would be helpful to
   specify one.

OR

- be flexible, allowing but not mandating use of a random number.
   Then perhaps be more flexible - perhaps go with .

...

>> Also, the text isn't clear on the relationship between
>> a=msid-semantic:
>> a=ssrc-group:
>> a=group:
>>
>> Are these all just *analogous* but independent mechanisms for
>> grouping? Or is it intended that these can be used together to group
>> things of all these types together?
> That's because I'm not clear on what it should be.

:-)
Then its good to have a discussion about it.

> There's a good reason to say that one can generate an SDP offer with
> both a=msid-semantic and  a=ssrc-group for the same semantic in the same
> offer, because this offers one-round-trip negotiation with both
> endpoints that understand a=msid-semantic and endpoints that only
> understand a=group, but since msid-semantic is able to express the
> semantics of a=ssrc-group, I don't see why a response should reply with
> both ssrc-group and msid-semantic for the same semantic.

Reusing the ssid-group semantic registry for msid-semantic means that 
values defined for msid-semantic will be eligible for use with 
ssid-group. That might be confusing.

It's not clear to me that there is any meaningful overlap between the 
semantics useful for ssrc-group and those useful for msid-semantic. This 
needs to be analyzed from two perspectives:
- can a semantic defined for ssid-group be useful for msid-semantic?
- can a semantic defined for msid-semantic be useful for ssid-group?

I'm not seeing how the 'WMS' semantic would be useful with ssid-group.

But it is perhaps possible that 'FID' and 'FEC' *might* be useful with 
msid-group, to tie together RTP streams from different RTP sessions.

I *do* see how semantics from a=group might be useful with 
msid-semantics. E.g. 'LS', which is used as an example in section 3 of 
the msid-01 draft. But since LS is defined in the registry for a=group, 
and not in the registry for ssid-group, that isn't a valid example.

The logic (in 5576) for establishing a new registry for ssid-group 
(rather than reusing the one from 'group') was that meaningful semantics 
are different when grouping streams in a single session than when 
grouping together different sessions. Since msid-group is largely about 
grouping streams from separate sessions, maybe it would make more sense 
to share a registry with group, rather than with ssid-group. Or maybe 
all three registries should be disjoint.

>> RFC 5576 makes it clear that ssrc-group and group are analogous but
>> independent with independent registries.
>>
>> I find in the iana considerations section that msid-semantic is
>> reusing the "Semantics for the "ssrc-group" SDP Attribute" registry,
>> and registers "WMS" in that registry. So apparently one can use WMS
>> with a=ssrc-group. That suggests it is intended that can be used
>> together.
>>
>> BUT, ssrc-group is a media level attribute. That implies that the
>> namespace for ssrc-group tokens is independent for each media section
>> in the SDP. But msid-semantic is session-wide. Using it would couple
>> the namespaces of different media sections.
> I'm not clear what you want to say here. What namespaces would be
> coupled by msid-semantic?
> Since ssrc-group doesn't have tokens (it's just ssrcs), it doesn't seem
> to define a namespace.

Sorry. Just muddled thinking on my part. There is no shared namespace 
except for the "semantic" namespace.

>> Section 4:
>>
>> This section feels like it belongs in a separate draft. If it were
>> non-normative then it might be ok as an example. But it is normative.
>> The following clearly is:
> It was the original purpose of the draft - the split into a general
> mechanism and a specific usage was done at the behest of MMUSIC. So yes,
> it's definitely intended to be normative.
>>
>>    When an SDP description is updated, a specific msid continues to
>>    refer to the same media stream; an msid value MUST NOT be reused for
>>    another media stream within a PeerConnection's lifetime.
>>
>> It isn't clear if that is intended only for WebRTC media streams.
>> Hopefully so, since it is in a section scoped that way, and might not
>> be desirable for all uses.
> The limitation is defined in terms of WebRTC MediaStreams, not RTP media
> streams, so yes. I'll make sure to make the casing right, and add the
> qualifier.
>>
>> Even for this use that limitation is problematic. Anything that
>> requires the generation of new SDP in a session to be aware of all the
>> historical SDP in that session is problematic. It is easy to get
>> situations (transfer, federation) where contributors to the SDP come
>> and go without knowledge of history prior to their joining.
>
> I don't think that it requires one to be aware of history in practice.
> It just requires that you either record history, or that the identifier
> contains enough randomness, and that the random number generator is run
> once for every new MediaStream.

*If* the IDs must be random then I have no complaint.

Maintaining history can be a problem if one of the players is replaced 
by another that was never privy to the prior history. This may not come 
up with native RTCWEB, but it can arise fairly easily in SIP.

>> (This is already a problem in SDP with the requirement that a payload
>> number can never be reused for a different codec within an RTP
>> session. It is my impression that this is often violated, usually
>> without problem.)
>
> I don't know the rules for that - can one renegotiate the codec
> parameters for a payload type, or are those too supposed to be locked down?

This is a little bit off subject for this discussion thread, but for 
completeness:

 From 8.3.2 of 3264:

    ... However, in the
    case of RTP, the mapping from a particular dynamic payload type
    number to a particular codec within that media stream MUST NOT change
    for the duration of a session. For example, if A generates an offer
    with G.711 assigned to dynamic payload type number 46, payload type
    number 46 MUST refer to G.711 from that point forward in any offers
    or answers for that media stream within the session. However, it is
    acceptable for multiple payload type numbers to be mapped to the same
    codec, so that an updated offer could also use payload type number 72
    for G.711.

         The mappings need to remain fixed for the duration of the
         session because of the loose synchronization between
         signaling exchanges of SDP and the media stream.

According to the words written it may be ok to renegotiate parameters 
other than the codec. But the reason given for this would seem to apply 
for at least some other parameters.

The logic given also doesn't really justify imposing this "for the 
duration of the session", if we interpret "session" here to mean the 
communications session established with SDP, not the RTP session. (I 
think that is the proper interpretation.) It would be more justifiable 
in the context of an RTP session.

In practice it will typically be sufficient to abstain from reusing the 
value for a brief interval around a new O/A. After that it should be 
possible to retire values that weren't mentioned in the most recent O/A 
and make them available for reuse in the future.

ISTM *that* would also be sufficient for msid IDs. (I realize it is 
harder to formalize than just saying they can never be reused.)

> Of course this is much more problematic in multiparty sessions than in
> offer/answer negotiated sessions....

It doesn't require an *obviously* multiparty session. It can be a 
problem when a an intermediary performs a transfer on one side while 
"hiding" it from the other side. And this is pretty common in SIP.

	Thanks,
	Paul


From internet-drafts@ietf.org  Mon Oct 22 15:38:03 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698E511E80EA; Mon, 22 Oct 2012 15:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level: 
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOPAStmbcCAi; Mon, 22 Oct 2012 15:38:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92C11F0C54; Mon, 22 Oct 2012 15:38:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121022223802.9286.54009.idtracker@ietfa.amsl.com>
Date: Mon, 22 Oct 2012 15:38:02 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-13.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2012 22:38:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multiparty Multimedia Session Control Wor=
king Group of the IETF.

	Title           : A Network Address Translator (NAT) Traversal mechanism f=
or media controlled by Real-Time Streaming Protocol (RTSP)
	Author(s)       : Jeff Goldberg
                          Magnus Westerlund
                          Thomas Zeng
	Filename        : draft-ietf-mmusic-rtsp-nat-13.txt
	Pages           : 31
	Date            : 2012-10-22

Abstract:
   This document defines a solution for Network Address Translation
   (NAT) traversal for datagram based media streams setup and controlled
   with Real-time Streaming Protocol version 2 (RTSP 2.0).  It uses
   Interactive Connectivity Establishment (ICE) adapted to use RTSP as a
   signalling channel, defining the necessary extra RTSP extensions and
   procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rtsp-nat-13


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From emil@sip-communicator.org  Mon Oct 22 16:40:29 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF46E21F8612 for ; Mon, 22 Oct 2012 16:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3riQXw7lhIAA for ; Mon, 22 Oct 2012 16:40:28 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7932021F85C8 for ; Mon, 22 Oct 2012 16:40:15 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1838549wgb.13 for ; Mon, 22 Oct 2012 16:40:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding:x-gm-message-state; bh=l1YRVGYgH1foFNUEk2WJHUga44E01+BKdIxjBhsO6oM=; b=M1IQ13xb/l3RHxJ4bdqTUGZb+hTYbe1Dd8Zg9udS4YlBTa7EDtgJNFEH0S3aBxpA4Q UIM0bQAhi/jUa16ajpoC7QqMllnCMJRmPt9IthjeiW7shzEGoup9wrLxryQIbvb6e3Xh J+dQ+j3xboiMpxBbIRYfDogt3iZJd8IShXXSHCmDtylfcbviWkVpf9JNFKmzsfiNzOvG XEiw9C7P2Bis7q/xf9hFCrKDu+uVXWRWr1vmVgkYohMxfTFGk8sH0f7PAxKYi6V7xfKt J/ORM8fCojJ3gmsqb/f6Pxx+OPBFDKnnADmiCHGf6RYGXpDoXyLcLktCrpLELnVidoK8 D/NQ==
Received: by 10.216.201.198 with SMTP id b48mr6230181weo.126.1350949214117; Mon, 22 Oct 2012 16:40:14 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:9c80:cb3c:1bab:fb31]) by mx.google.com with ESMTPS id a10sm24607433wiz.4.2012.10.22.16.40.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 16:40:13 -0700 (PDT)
Message-ID: <5085D95B.8060005@jitsi.org>
Date: Tue, 23 Oct 2012 01:40:11 +0200
From: Emil Ivov 
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: MMUSIC IETF WG 
References: <20121022233050.12293.44073.idtracker@ietfa.amsl.com>
In-Reply-To: <20121022233050.12293.44073.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20121022233050.12293.44073.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkbninQEScDUE0qknmPBU1Vj2hYXdWBN+4g1XErzL7Xpdr4Zv67NuvRO84dBba7QWKr27bB
Subject: [MMUSIC] Trickle ICE Update (Fwd: New Version Notification for draft-rescorla-mmusic-ice-trickle-01.txt)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Oct 2012 23:40:29 -0000

Hey all,

We have just submitted a new version of the Trickle ICE draft. Among the
most notable changes we:

	
o Relaxed requirements about verifying support as discussed here.
o Tried to improve ambiguities introduced by use of 3264 language. This
part needs more work but we'd like to gather more feedback before
proceeding and also see if any parts can be adopted by 5245bis.
o Removed inappropriate assumption of adoption by RTCWEB.

Diff2 available here:
http://tools.ietf.org/rfcdiff?url2=draft-rescorla-mmusic-ice-trickle-01.txt

Comments are most welcome.

Cheers,
Emil


-------- Original Message --------
Subject: New Version Notification for
draft-rescorla-mmusic-ice-trickle-01.txt
Date: Mon, 22 Oct 2012 16:30:50 -0700
From: internet-drafts@ietf.org
To: emcho@jitsi.org
CC: justin@uberti.name, ekr@rtfm.com


A new version of I-D, draft-rescorla-mmusic-ice-trickle-01.txt
has been successfully submitted by Emil Ivov and posted to the
IETF repository.

Filename:	 draft-rescorla-mmusic-ice-trickle
Revision:	 01
Title:		 Trickle ICE: Incremental Provisioning of Candidates for the
Interactive Connectivity Establishment (ICE) Protocol
Creation date:	 2012-10-23
WG ID:		 Individual Submission
Number of pages: 16
URL:
http://www.ietf.org/internet-drafts/draft-rescorla-mmusic-ice-trickle-01.txt
Status:
http://datatracker.ietf.org/doc/draft-rescorla-mmusic-ice-trickle
Htmlized:
http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-rescorla-mmusic-ice-trickle-01

Abstract:
   This document describes an extension to the Interactive Connectivity
   Establishment (ICE) protocol that allows ICE agents to send and
   receive candidates incrementally rather than exchanging complete
   lists.  With such incremental provisioning, ICE agents can begin
   connectivity checks while they are still gathering candidates and
   considerably shorten the time necessary for ICE processing to
   complete.

   The above mechanism is also referred to as "trickle ICE".





The IETF Secretariat





From bernard_aboba@hotmail.com  Tue Oct 23 12:00:43 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0511E8104 for ; Tue, 23 Oct 2012 12:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.933
X-Spam-Level: 
X-Spam-Status: No, score=-100.933 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub9xOP1hNRdb for ; Tue, 23 Oct 2012 12:00:43 -0700 (PDT)
Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3457111E80A3 for ; Tue, 23 Oct 2012 12:00:41 -0700 (PDT)
Received: from BLU002-W121 ([65.55.111.72]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 23 Oct 2012 12:00:40 -0700
Message-ID: 
Content-Type: multipart/alternative; boundary="_fecc2fe7-2891-49e5-8430-a1de787f9a6c_"
X-Originating-IP: [131.107.0.116]
From: Bernard Aboba 
To: "Miguel A. Garcia" 
Date: Tue, 23 Oct 2012 12:00:40 -0700
Importance: Normal
In-Reply-To: <50791CDC.7030104@ericsson.com>
References: , <50791CDC.7030104@ericsson.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 23 Oct 2012 19:00:40.0460 (UTC) FILETIME=[B1F2ECC0:01CDB150]
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] MSID and mslabel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Oct 2012 19:00:43 -0000

--_fecc2fe7-2891-49e5-8430-a1de787f9a6c_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Miguel Garcia said:=20

>=20
> Bernard=2C
>=20
> I cannot identify the "mslabel" attribute. Do you know where it is specif=
ied?
>=20
> Perhaps you refer to the "label" attribute (RFC 4574).
>=20
> /Miguel

[BA] As Harald noted (see http://www.ietf.org/mail-archive/web/mmusic/curre=
nt/msg09712.html)=2C "mslabel" is used within a=3Dssrc lines=2C presumably =
for a similar purpose that "msid" is proposed for.  An example:

SDP from createOffer()=2C Chrome Version 24.0.1297.0 dev

v=3D0
o=3D- 1321413050 2 IN IP4 127.0.0.1
s=3D-
t=3D0 0
a=3Dgroup:BUNDLE audio video
m=3Daudio 1 RTP/SAVPF 103 104 0 8 106 105 13 126
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:9wMh/Gc6fgJBzvzQ
a=3Dice-pwd:4I4SozPeoRtm9C58OF8M/deY
a=3Dice-options:google-ice
a=3Dsendrecv
a=3Dmid:audio
a=3Drtcp-mux
a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_80 inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbv=
g3njMO1FB
a=3Drtpmap:103 ISAC/16000
a=3Drtpmap:104 ISAC/32000
a=3Drtpmap:0 PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:106 CN/32000
a=3Drtpmap:105 CN/16000
a=3Drtpmap:13 CN/8000
a=3Drtpmap:126 telephone-event/8000
a=3Dssrc:1635880669 cname:ZXVf3drwG3fT+Wh5
a=3Dssrc:1635880669 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=3Dssrc:1635880669 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr00
m=3Dvideo 1 RTP/SAVPF 100 101 102
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:9wMh/Gc6fgJBzvzQ
a=3Dice-pwd:4I4SozPeoRtm9C58OF8M/deY
a=3Dice-options:google-ice
a=3Dsendrecv
a=3Dmid:video
a=3Drtcp-mux
a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_80 inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbv=
g3njMO1FB
a=3Drtpmap:100 VP8/90000
a=3Drtpmap:101 red/90000
a=3Drtpmap:102 ulpfec/90000
a=3Dssrc:1563041388 cname:ZXVf3drwG3fT+Wh5
a=3Dssrc:1563041388 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=3Dssrc:1563041388 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr10
 		 	   		  =

--_fecc2fe7-2891-49e5-8430-a1de787f9a6c_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Miguel Garcia said: 

>=3B 
>=3B Bernard=2C
>=3B 
>=3B I cannot identify the "m=
slabel" attribute. Do you know where it is specified?
>=3B 
>=3B =
Perhaps you refer to the "label" attribute (RFC 4574).
>=3B 
>=3B=
 /Miguel

[BA] As Harald noted (see http://www.ietf.org/mail-archive/=
web/mmusic/current/msg09712.html)=2C "mslabel" is used within a=3Dssrc line=
s=2C presumably for a similar purpose that "msid" is proposed for. =3B =
An example:

SDP from createOffer()=2C Chrome Version 24.0.1297.0 dev=


v=3D0
o=3D- 1321413050 2 IN IP4 127.0.0.1
s=3D-
t=3D0 0a=3Dgroup:BUNDLE audio video
m=3Daudio 1 RTP/SAVPF 103 104 0 8 106 105 =
13 126
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:=
9wMh/Gc6fgJBzvzQ
a=3Dice-pwd:4I4SozPeoRtm9C58OF8M/deY
a=3Dice-options=
:google-ice
a=3Dsendrecv
a=3Dmid:audio
a=3Drtcp-mux
a=3Dcrypto:=
1 AES_CM_128_HMAC_SHA1_80 inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FBa=3Drtpmap:103 ISAC/16000
a=3Drtpmap:104 ISAC/32000
a=3Drtpmap:0 PC=
MU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:106 CN/32000
a=3Drtpmap:=
105 CN/16000
a=3Drtpmap:13 CN/8000
a=3Drtpmap:126 telephone-event/800=
0
a=3Dssrc:1635880669 cname:ZXVf3drwG3fT+Wh5
a=3Dssrc:1635880669 msla=
bel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=3Dssrc:1635880669 label:cLFXF=
pfLOP31s7D1A9on2I2rAvhTKqGSZEWr00
m=3Dvideo 1 RTP/SAVPF 100 101 102
c=
=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:9wMh/Gc6fgJ=
BzvzQ
a=3Dice-pwd:4I4SozPeoRtm9C58OF8M/deY
a=3Dice-options:google-ice=

a=3Dsendrecv
a=3Dmid:video
a=3Drtcp-mux
a=3Dcrypto:1 AES_CM_12=
8_HMAC_SHA1_80 inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
a=3Drtpma=
p:100 VP8/90000
a=3Drtpmap:101 red/90000
a=3Drtpmap:102 ulpfec/90000<=
br>a=3Dssrc:1563041388 cname:ZXVf3drwG3fT+Wh5
a=3Dssrc:1563041388 mslabe=
l:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=3Dssrc:1563041388 label:cLFXFpf=
LOP31s7D1A9on2I2rAvhTKqGSZEWr10
 		 	   		  
=

--_fecc2fe7-2891-49e5-8430-a1de787f9a6c_--

From salvatore.loreto@ericsson.com  Tue Oct 23 23:05:24 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB34321F8D1E for ; Tue, 23 Oct 2012 23:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.366
X-Spam-Level: 
X-Spam-Status: No, score=-106.366 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uly8aZTySz5g for ; Tue, 23 Oct 2012 23:05:24 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B274F21F8D79 for ; Tue, 23 Oct 2012 23:05:23 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-11-508785224417
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AC.86.11467.22587805; Wed, 24 Oct 2012 08:05:22 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Oct 2012 08:05:21 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id A712F24C0	for ; Wed, 24 Oct 2012 09:05:21 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0DE6F538D1	for ; Wed, 24 Oct 2012 09:05:21 +0300 (EEST)
Received: from n94.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AF5F7514EC	for ; Wed, 24 Oct 2012 09:05:20 +0300 (EEST)
Message-ID: <50878520.3020009@ericsson.com>
Date: Wed, 24 Oct 2012 09:05:20 +0300
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <20121022190754.7463.41798.idtracker@ietfa.amsl.com>
In-Reply-To: <20121022190754.7463.41798.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvra5Sa3uAwbMufoupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+YR1YILAhXTJ/A2MPbxdjFyckgImEi0rpvDBmGLSVy4tx7I 5uIQEjjFKPG8rZURwtnAKNE94zo7hHORUeLhp11MEM4RRon9DxuYIZw9jBLrPz9kAhnGK6At 0fH8GZjNIqAqMf3jbUYQm03ATOL5wy3MILaoQLLEvA1XmSHqBSVOznzCAmKLCAhLzHj7F+wo YQFniX1nH7KD2EICDhLvb7WC1XAKOEpsnNsC1sssYCtxYc51FghbXmL72znMEA+pSVw9t4kZ oldLovdsJ9MERpFZSNbNQtI+C0n7AkbmVYzCuYmZOenlhnqpRZnJxcX5eXrFqZsYgSF+cMtv 3R2Mp86JHGKU5mBREuflStrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR2E71rp6zQDTn xkiG+4vWN91Xe132UXw/k6ravEVzlk770t57PGNvwM/99zQ+xE67v/B40NXr6RODoxLEqy0q T2767nvVTNdt7RMJOQ3NHEHWMzdUPdelv4y3uj/5cobOp3j7jvQ3jxyObEr4eLcsZX1696Ki X/Ut8zReX74iHPLq1uGz9dNLlViKMxINtZiLihMB+VAlED8CAAA=
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2012 06:05:24 -0000

Hi there,

I have updated the draft trying to capture the result of the discussion 
we had in this mailing list
writing down for SCTP a  syntax similar to that used for RTP,
i.e. with "channle numbers" being used in a way analogous to payload 
type numbers.

The proposal is a very first attempt to see if this is the direction we 
want to go
and it is obviously incomplete lacking the possibility to define
all the properties of the specific channel...

feedback and comments are very welcome and necessary at this point

best regards
Salvatore




On 10/22/12 10:07 PM, 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           : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)
> 	Author(s)       : Salvatore Loreto
>                            Gonzalo Camarillo
> 	Filename        : draft-ietf-mmusic-sctp-sdp-02.txt
> 	Pages           : 13
> 	Date            : 2012-10-22
>
> Abstract:
>     SCTP (Stream Control Transmission Protocol) is a transport protocol
>     used to establish associations between two endpoints.  This document
>     describes how to express media transport over SCTP in SDP (Session
>     Description Protocol).  This document defines the 'SCTP', 'SCTP/DTLS'
>     and 'DTLS/SCTP' protocol identifiers for SDP.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From pkyzivat@alum.mit.edu  Wed Oct 24 08:46:39 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD2721F8BB4 for ; Wed, 24 Oct 2012 08:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.82
X-Spam-Level: 
X-Spam-Status: No, score=0.82 tagged_above=-999 required=5 tests=[AWL=-1.143,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_110=0.6, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ihrjQrLaK6y for ; Wed, 24 Oct 2012 08:46:38 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 5336221F8A34 for ; Wed, 24 Oct 2012 08:46:38 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id F0tP1k0071c6gX8513milA; Wed, 24 Oct 2012 15:46:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id F3lt1k00W3ZTu2S3j3ltQi; Wed, 24 Oct 2012 15:45:53 +0000
Message-ID: <50880D5C.6070002@alum.mit.edu>
Date: Wed, 24 Oct 2012 11:46:36 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <20121022190754.7463.41798.idtracker@ietfa.amsl.com> <50878520.3020009@ericsson.com>
In-Reply-To: <50878520.3020009@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-02.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2012 15:46:39 -0000

Salvatore,

IMO the new version is going in a good direction. But it does lead me to 
a number of additional questions:

- there is going to be a need to work out the offer/answer rules.
   It is currently just touched upon wrt a=setup and a=connection.
   But what are the rules for channel numbers in offers and
   answers, as well as a=streams and a=datachannel in offers and
   answers? Must the channel number be present in both offer and
   answer to be used?

- the mention of both uni- and bi-directional data channels seems good.
   But how is a decision made whether a channel is uni- or bi-
   directional? Is it fixed based on the channel type? Or is it
   negotiated via O/A? (RTP also effectively has this distinction,
   though not clearly defined. It is negotiated via O/A. But it is
   negotiated for the entire m-line, not just for a single payload type.)

   I guess I would prefer that this be settled via O/A. Perhaps
   a=datachannel:n defines what you want to *receive* on the datachannel.
   If there is none, then you don't want to receive, so it's uni-
   directional. If present and has the same datachannel type in both
   O/A then it is bi-directional. If it is present in both O/A but
   channel type is different on two sides then it's two uni-directional
   streams.

- How do datachannel numbers map to stream numbers? It would be
   convenient if they mapped 1:1 so no further syntax was needed.
   That could work well for bi-directional channels, and for uni-
   directional channels that all point the same direction. But when
   there are uni-directional channels in each direction do we want
   to require that the number in the reverse direction be "wasted"?

   In spite of the potential "waste", I guess I prefer the 1:1
   mapping for simplicity.

- what are the assumptions/rules for streams within the limit that
   don't have negotiated datachannel numbers? Are they free to be
   used for unspecified purposes? If so, then what happens if a
   subsequent O/A reuses the connection and adds another datachannel
   number corresponding to a stream already in use?

- There is currently a statement that every channel number that is
   listed MUST be used. Why? What does that mean? What if I have
   nothing to send? Or does it just mean that the receiving end
   must be prepared to receive on that channel?

- the syntax of the datachannel attribute is inconsistent with the
   examples. It makes no provision for the datachannel type or
   the "label" and "options" parameters shown.

- What are the semantics of the datachannel type? Open issue 2
   talks about registering RTCWeb. But what would be in that
   registration? Assuming this is to follow the model for RTP,
   and the examples, then it would be mime type "application/rtcweb"
   that is registered, and that should define the message format for
   messages on the channel. But my understanding of the intended
   use of datachannels in RTCWEB tells me that the message format
   for datachannels will vary. (Or is there a common "wrapper"
   type for all data in RTCWEB channels?)

- Also for datachannel type: If the RTP pattern is followed, so
   that the mime type is formed from the  of the m-line
   and the datachannel type from the a=datachannel line, then every
   channel of the SCTP connection must have the same top level
   mime type. (All "application", or "audio", etc.) This is similar
   to the problem being confronted in
   draft-holmberg-mmusic-sdp-mmt-negotiation. There the solution is
   to introduce a *special*  value ("anytype") and then another
   attribute (a=mmtype) to specify the  type on a per-payload
   number basis. Presumably the same solution could be used here.

So many questions, so little time. :-)

	Thanks,
	Paul

On 10/24/12 2:05 AM, Salvatore Loreto wrote:
> Hi there,
>
> I have updated the draft trying to capture the result of the discussion
> we had in this mailing list
> writing down for SCTP a  syntax similar to that used for RTP,
> i.e. with "channle numbers" being used in a way analogous to payload
> type numbers.
>
> The proposal is a very first attempt to see if this is the direction we
> want to go
> and it is obviously incomplete lacking the possibility to define
> all the properties of the specific channel...
>
> feedback and comments are very welcome and necessary at this point
>
> best regards
> Salvatore


From harald@alvestrand.no  Wed Oct 24 09:40:43 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4779121F8C35 for ; Wed, 24 Oct 2012 09:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.243
X-Spam-Level: 
X-Spam-Status: No, score=-109.243 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVoP3uno60IR for ; Wed, 24 Oct 2012 09:40:42 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 40DB421F8C7B for ; Wed, 24 Oct 2012 09:40:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CA6239E18D for ; Wed, 24 Oct 2012 18:40:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lumtzS5fOBAp for ; Wed, 24 Oct 2012 18:40:39 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8003439E173 for ; Wed, 24 Oct 2012 18:40:39 +0200 (CEST)
Message-ID: <50881A06.1020205@alvestrand.no>
Date: Wed, 24 Oct 2012 18:40:38 +0200
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: , <50791CDC.7030104@ericsson.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000108040601000604070303"
Subject: Re: [MMUSIC] MSID and mslabel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2012 16:40:43 -0000

This is a multi-part message in MIME format.
--------------000108040601000604070303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/23/2012 09:00 PM, Bernard Aboba wrote:
> Miguel Garcia said:
>
> >
> > Bernard,
> >
> > I cannot identify the "mslabel" attribute. Do you know where it is 
> specified?
> >
> > Perhaps you refer to the "label" attribute (RFC 4574).
> >
> > /Miguel
>
> [BA] As Harald noted (see 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09712.html),
> "mslabel" is used within a=ssrc lines, presumably for a similar 
> purpose that "msid" is proposed for.

 From a quick look at the source code, it looks like an identifier for a 
synchronization context - so it's a synonym for cname, more or less.

> An example:
>
> SDP from createOffer(), Chrome Version 24.0.1297.0 dev
>
> v=0
> o=- 1321413050 2 IN IP4 127.0.0.1
> s=-
> t=0 0
> a=group:BUNDLE audio video
> m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126
> c=IN IP4 0.0.0.0
> a=rtcp:1 IN IP4 0.0.0.0
> a=ice-ufrag:9wMh/Gc6fgJBzvzQ
> a=ice-pwd:4I4SozPeoRtm9C58OF8M/deY
> a=ice-options:google-ice
> a=sendrecv
> a=mid:audio
> a=rtcp-mux
> a=crypto:1 AES_CM_128_HMAC_SHA1_80 
> inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
> a=rtpmap:103 ISAC/16000
> a=rtpmap:104 ISAC/32000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:106 CN/32000
> a=rtpmap:105 CN/16000
> a=rtpmap:13 CN/8000
> a=rtpmap:126 telephone-event/8000
> a=ssrc:1635880669 cname:ZXVf3drwG3fT+Wh5
> a=ssrc:1635880669 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
> a=ssrc:1635880669 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr00
> m=video 1 RTP/SAVPF 100 101 102
> c=IN IP4 0.0.0.0
> a=rtcp:1 IN IP4 0.0.0.0
> a=ice-ufrag:9wMh/Gc6fgJBzvzQ
> a=ice-pwd:4I4SozPeoRtm9C58OF8M/deY
> a=ice-options:google-ice
> a=sendrecv
> a=mid:video
> a=rtcp-mux
> a=crypto:1 AES_CM_128_HMAC_SHA1_80 
> inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
> a=rtpmap:100 VP8/90000
> a=rtpmap:101 red/90000
> a=rtpmap:102 ulpfec/90000
> a=ssrc:1563041388 cname:ZXVf3drwG3fT+Wh5
> a=ssrc:1563041388 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
> a=ssrc:1563041388 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr10
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--------------000108040601000604070303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 10/23/2012 09:00 PM, Bernard Aboba
      wrote:

    

    

      
      
Miguel Garcia said: 

        

        
> 

          > Bernard,

          > 

          > I cannot identify the "mslabel" attribute. Do you know
          where it is specified?

          > 

          > Perhaps you refer to the "label" attribute (RFC 4574).

          > 

          > /Miguel

          

          [BA] As Harald noted (see
          http://www.ietf.org/mail-archive/web/mmusic/current/msg09712.html),
        

      

    

    

      

        
"mslabel" is used within a=ssrc lines, presumably for a
          similar purpose that "msid" is proposed for. 

        

      

    

    

    From a quick look at the source code, it looks like an identifier
    for a synchronization context - so it's a synonym for cname, more or
    less.

    

    

      

        
 An example:

          

          SDP from createOffer(), Chrome Version 24.0.1297.0 dev

          

          v=0

          o=- 1321413050 2 IN IP4 127.0.0.1

          s=-

          t=0 0

          a=group:BUNDLE audio video

          m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

          c=IN IP4 0.0.0.0

          a=rtcp:1 IN IP4 0.0.0.0

          a=ice-ufrag:9wMh/Gc6fgJBzvzQ

          a=ice-pwd:4I4SozPeoRtm9C58OF8M/deY

          a=ice-options:google-ice

          a=sendrecv

          a=mid:audio

          a=rtcp-mux

          a=crypto:1 AES_CM_128_HMAC_SHA1_80
          inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB

          a=rtpmap:103 ISAC/16000

          a=rtpmap:104 ISAC/32000

          a=rtpmap:0 PCMU/8000

          a=rtpmap:8 PCMA/8000

          a=rtpmap:106 CN/32000

          a=rtpmap:105 CN/16000

          a=rtpmap:13 CN/8000

          a=rtpmap:126 telephone-event/8000

          a=ssrc:1635880669 cname:ZXVf3drwG3fT+Wh5

          a=ssrc:1635880669 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr

          a=ssrc:1635880669 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr00

          m=video 1 RTP/SAVPF 100 101 102

          c=IN IP4 0.0.0.0

          a=rtcp:1 IN IP4 0.0.0.0

          a=ice-ufrag:9wMh/Gc6fgJBzvzQ

          a=ice-pwd:4I4SozPeoRtm9C58OF8M/deY

          a=ice-options:google-ice

          a=sendrecv

          a=mid:video

          a=rtcp-mux

          a=crypto:1 AES_CM_128_HMAC_SHA1_80
          inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB

          a=rtpmap:100 VP8/90000

          a=rtpmap:101 red/90000

          a=rtpmap:102 ulpfec/90000

          a=ssrc:1563041388 cname:ZXVf3drwG3fT+Wh5

          a=ssrc:1563041388 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr

          a=ssrc:1563041388 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr10

        

      

      

      

      

      
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


    

    

  


--------------000108040601000604070303--

From fluffy@cisco.com  Wed Oct 24 13:57:16 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71C121F8A39 for ; Wed, 24 Oct 2012 13:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.091
X-Spam-Level: 
X-Spam-Status: No, score=-110.091 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcbicjdtXoSX for ; Wed, 24 Oct 2012 13:57:16 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6164421F87DC for ; Wed, 24 Oct 2012 13:57:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1333; q=dns/txt; s=iport; t=1351112228; x=1352321828; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ruhjkvkDF3KzkSxJ+uN9U8xcIdTeohfuLURIe6UV6HI=; b=WkdKzQPn3pt7aXqb5F90iwkJjc1npg10w3lnhQdtGhyhoB0QvJ1G0JhD pRZNAyIPsRYWAjgkjWN7Pl4DQuP3gMv+YbabLmMsmdMMmNzk0pbWM4vOq cxpZqNbiLUsvrZWwLd1aIIRrKR0fHzNknW704S18hvS+o5bca9ez/x2sG w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAKdViFCtJV2a/2dsb2JhbABEwX2BCIIeAQEBAwESASc/EAIBCBgKFBAyJQIEDgUIGodcBpxmoBCLYYYMYQOkQYFrgm+CGQ
X-IronPort-AV: E=Sophos;i="4.80,642,1344211200"; d="scan'208";a="135043616"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 24 Oct 2012 20:57:06 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9OKv6rD021724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 20:57:06 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 15:57:05 -0500
From: "Cullen Jennings (fluffy)" 
To: Jonathan Lennox 
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: AQHNsiofE3x+5VNgHU6WEFgTcA9Jqg==
Date: Wed, 24 Oct 2012 20:57:05 +0000
Message-ID: 
References:  <50222D44.5040105@alvestrand.no>  <502258CA.5030009@alvestrand.no>  <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>,  <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340  9FF2F9E@ESESSCMS0356.	e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>, <000601cd99bc$5b1e5bb0$115b1310$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se> <46F70838-8689-4C1C-9C49-B981B1E2D208@vidyo.com>
In-Reply-To: <46F70838-8689-4C1C-9C49-B981B1E2D208@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000
x-tm-as-result: No--33.032000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18148AFB8F54FF4EBCB4F3137BC97593@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" , Christer Holmberg 
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2012 20:57:17 -0000

On Sep 24, 2012, at 12:41 PM, Jonathan Lennox  wrote:

>=20
> On Sep 23, 2012, at 4:37 PM, Christer Holmberg wrote:
>>=20
>>> Instead, Let us discuss the generic categories of attributes and mentio=
n in this draft.
>>=20
>> I am not sure I understood.
>>=20
>> For sure we will have to discuss how/if attributes are affected, but we =
need to have a general idea on how the multiplexing is going to be offered.=
 Same ports, m=3Dbundle, or something else...
>=20
>=20
> One of the major benefits of the "pure" m=3Dbundle proposal is that we *d=
on't* have to discuss categories of attributes (other than to make recommen=
dations to implementors).  The attributes inside each unbundled m=3D line n=
eed to be self-consistent, and the attributes inside the m=3Dbundle line al=
so need to be self-consistent, but there doesn't need to be any standardize=
d mechanism to infer the one from the others.
>=20
>=20

But the problem is that for some attributes, we have no way of expressing t=
hem per ssrc, only per m line. Yes I realize we could write many extentions=
 to SDP to have new ways of doing it all per ssrc but this seems to be a di=
sadvantage to me. All I wanted was to put multiple things on the same port =
- I should have to redefine a bunch of new  SDP to do that.=20





From martin.thomson@gmail.com  Wed Oct 24 16:58:49 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F351F0C4C for ; Wed, 24 Oct 2012 16:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.831
X-Spam-Level: 
X-Spam-Status: No, score=-3.831 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf1Cfld9p17a for ; Wed, 24 Oct 2012 16:58:49 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7E1F0419 for ; Wed, 24 Oct 2012 16:58:48 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so817007lam.31 for ; Wed, 24 Oct 2012 16:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3e9Lbgw52QcWUPohTEboPqiHGaVKAc4MgtBvgmB1Skw=; b=YHFZdM9snTtIRqMwi65/DcEWRYfXlBrPbkOQ0Ly5ZdDgb7DT1DOAOvlhVCTUGZV1Bs SvaHEUGm1yGErIgeTX/FLHoz8pZJLZ+fC1A2VM+sp7lVDnQ6tPQSa7+LS522w0IhRuxY tsIV8qv2MCD99tyjZsHXcjQnTO3Z4/p8u1xaiEnB551HRMSahq7vcrF2XO+JcnR+LbNY UDDvNQlkiEGdQeUQBFIFlNckvhkl/SAYjPeHXDZaEmWQZwACkBJatV9dvGeygvSuuWBh /LgFXlvK+vV9e67jPsyy3QMbx+wbD638pJft6XiCOnzqUHgQm4vigjp0moWcuqmXznOZ i9HQ==
MIME-Version: 1.0
Received: by 10.112.47.228 with SMTP id g4mr6549689lbn.21.1351123127674; Wed, 24 Oct 2012 16:58:47 -0700 (PDT)
Received: by 10.112.83.2 with HTTP; Wed, 24 Oct 2012 16:58:47 -0700 (PDT)
In-Reply-To: <50881A06.1020205@alvestrand.no>
References:  <50791CDC.7030104@ericsson.com>  <50881A06.1020205@alvestrand.no>
Date: Wed, 24 Oct 2012 16:58:47 -0700
Message-ID: 
From: Martin Thomson 
To: Harald Alvestrand 
Content-Type: text/plain; charset=UTF-8
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] MSID and mslabel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Oct 2012 23:58:49 -0000

On 24 October 2012 09:40, Harald Alvestrand  wrote:
> From a quick look at the source code, it looks like an identifier for a
> synchronization context - so it's a synonym for cname, more or less.

That's not my experience, this appears to be critical to the
functioning of the browser.  I removed the line and the corresponding
track did not get created.

Unless there is something that has changed between the code that was
used to compile my copy of Chromium and what you are seeing.

--Martin

From christer.holmberg@ericsson.com  Thu Oct 25 00:36:44 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3716221F87BD for ; Thu, 25 Oct 2012 00:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.835
X-Spam-Level: 
X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVqxqLMwpmZA for ; Thu, 25 Oct 2012 00:36:43 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 356AD21F879C for ; Thu, 25 Oct 2012 00:36:43 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-8a-5088ec098db4
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EF.71.04547.90CE8805; Thu, 25 Oct 2012 09:36:41 +0200 (CEST)
Received: from ESESSHC005.ericsson.se (153.88.183.33) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 25 Oct 2012 09:36:40 +0200
Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 09:36:40 +0200
From: Christer Holmberg 
To: "'Cullen Jennings (fluffy)'" , Jonathan Lennox 
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: AQHNsiofE3x+5VNgHU6WEFgTcA9JqpfJoQRQ
Date: Thu, 25 Oct 2012 07:36:40 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B01DA1E@ESESSMB209.ericsson.se>
References:  <50222D44.5040105@alvestrand.no>  <502258CA.5030009@alvestrand.no>  <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com> <5038E0EE.60608@alvestrand.no>,  <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>, <0CC47B95-7817-4E2F-B7EE-04FD33E8113C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F97@ESESSCMS0356.eemea.ericsson.se>, <5E3FF4B9-1428-4273-8C07-CA7E09E94108@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F98@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E523@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9D@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E53E@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A0585340  9FF2F9E@ESESSCMS0356.	e emea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E645@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F9F@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E771@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA2@ESESSCMS0356.eemea.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F1773E7FC@US70UWXCHMBA04.zam.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FA4@ESESSCMS0356.eemea.ericsson.se> , <000001cd9815$d0882190$719864b0$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB1@ESESSCMS0356.eemea.ericsson.se>, <000601cd99bc$5b1e5bb0$115b1310$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FB4@ESESSCMS0356.eemea.ericsson.se> <46F70838-8689-4C1C-9C49-B981B1E2D208@vidyo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+JvrS7nm44Ag7UbZC06JrNZ7F98ntli 6vLHLA7MHlN+b2T1WLLkJ5NH27M77AHMUVw2Kak5mWWpRfp2CVwZDxYeYy94yl1xY+td5gbG JZxdjJwcEgImEuv2PWSBsMUkLtxbz9bFyMUhJHCKUWLLzwXMEM5ORonXcxYyQThLGCWuv9zD 2sXIwcEmYCHR/U8bpFtEIFqia/cXFpAws4C6xNXFQSBhYYF4iRXbljJDlCRI7Jq0lhHCNpL4 3NnGBGKzCKhKLF91FGwir4C3xMoPfBCbjvNLtH1qZAOp4RTwlZjy7QSYzQh06PdTa8B6mQXE JW49mc8E8YCAxJI955khbFGJl4//sULYihI7z7YzQ9TrSCzY/YkNwtaWWLbwNVicV0BQ4uTM J+CAEAKKtyyewD6BUWIWkhWzkLTPQtI+C0n7AkaWVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsY gdF3cMtv1R2Md86JHGKU5mBREue13rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj26oG v0VHLEP/+c9PcTlz6Zj/7HcMH5iclF46s2+rnrWaYcP1somHNntZ/78RHZ9yqOcIp+9k5fbn 75ZeuFGqyli0OaQv4Jbd/tTMosBkj9e3bXbqmvUlxzREzymUvFUWdfKYRvnhjxWN7Q+nh0cd CGTd17JUcmWpePiFMJesgNCnkZ45cvxKLMUZiYZazEXFiQC6vSGbjAIAAA==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2012 07:36:44 -0000

Hi,=20

>>>> Instead, Let us discuss the generic categories of attributes and menti=
on in this draft.
>>>=20
>>> I am not sure I understood.
>>>=20
>>> For sure we will have to discuss how/if attributes are affected, but we=
 need to have a general idea on how the multiplexing is going to be offered=
. Same ports, m=3Dbundle, or something else...
>>=20
>>=20
>> One of the major benefits of the "pure" m=3Dbundle proposal is that we *=
don't* have to discuss categories of attributes (other than to make recomme=
ndations to implementors).  The attributes inside each unbundled m=3D line =
need to be=20
>> self-consistent, and the attributes inside the m=3Dbundle line also need=
 to be self-consistent, but there doesn't need to be any standardized mecha=
nism to infer the one from the others.
>=20
> But the problem is that for some attributes, we have no way of expressing=
 them per ssrc, only per m line.

(That is of course not specific to media type multiplexing, but to the usag=
e of multiple sources per m- line in general.)

> Yes I realize we could write many extentions to SDP to have new ways of d=
oing it all per ssrc but this seems to be a disadvantage to me. All I wante=
d was to put multiple things=20
> on the same port - I should have to redefine a bunch of new  SDP to do th=
at.

RFC 5576 is da answah :)

http://tools.ietf.org/rfc/rfc5576.txt

Or, do you have specific examples/use-cases where it wouldn't work?

Regards,

Chrsiter




From magnus.westerlund@ericsson.com  Thu Oct 25 07:40:02 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225B821F89A4 for ; Thu, 25 Oct 2012 07:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.229
X-Spam-Level: 
X-Spam-Status: No, score=-106.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K2HNs7Huokj for ; Thu, 25 Oct 2012 07:39:59 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4C32721F8958 for ; Thu, 25 Oct 2012 07:39:59 -0700 (PDT)
X-AuditID: c1b4fb25-b7f926d00000661f-82-50894f361f13
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D1.76.26143.63F49805; Thu, 25 Oct 2012 16:39:50 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 25 Oct 2012 16:39:50 +0200
Message-ID: <50894F35.1060601@ericsson.com>
Date: Thu, 25 Oct 2012 16:39:49 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Flemming Andreasen 
References: <20120507075517.12573.64357.idtracker@ietfa.amsl.com> <4FA78A27.4040004@ericsson.com> <507724C4.5090601@cisco.com>
In-Reply-To: <507724C4.5090601@cisco.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZGfG3VtfMvzPAYNo8Q4v3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZbz6+5S54JN8xZ2TYQ2MhyW7GDk5JARMJDr3 n2eFsMUkLtxbz9bFyMUhJHCKUWLysvmsEM5yRonDFzaygVTxCmhLrNm8EKyDRUBVYubseUwg NpuAhcTNH41ANRwcogLBEs87iiHKBSVOznzCAhIWAWqdusACJMwsoC7R87uFGcQWFnCWuLr/ EDtIiZBAncTqWekgYU4BTYkDLx4xQ5wmKfH2/StmiFY9iSlXWxghbHmJ5q2zweJCQNMbmjpY JzAKzUKyeBaSlllIWhYwMq9iZM9NzMxJLzfaxAgM0YNbfqvuYLxzTuQQozQHi5I4r/XWPf5C AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKuc3shv/3smaGtSmOGTaZeuHVn+evcjrYunTc29 GcojtmjcXM35gzeGtTMsbs/rwBhTr/b1b/KnXDdwbi3SOL7leNYm0WlzpmiJ/Zacu6ohOHfJ L9NqpvZTs3t+KF/RdBVYfJmj7+zyZ7wTLJMf6s9sjEvq+q43rUanz/gu++xpv94ZTFEzvKfE UpyRaKjFXFScCAALBZryHwIAAA==
Cc: "mmusic \(E-mail\)" 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2012 14:40:02 -0000

Hi Flemming and WG,

Thanks for the detailed review. As you might have seen we managed to
update this document to address your comments. Below is answers to these
questions.

On 2012-10-11 21:57, Flemming Andreasen wrote:
> Hi Magnus
> 
> I have taken a look at the document and, the only real technical
> comments I have at this point are:
> 
> - Section 6.3 (Non-Supporting Proxies), last paragraph says that:
> 
> This variance in results is the reason
>    we don't recommend the usage of the Proxy-Require header. Instead we
>    recommend the usage of the Supported header to force proxies to
>    include the feature tags they support in the proxy-supported which
>    will provide a positive indication when all proxies in the chain
>    between the client and server support the functionality.  Even if not
>    explicitly indicating support, any SETUP response including a
>    transport specification with "D-ICE" will be implicit indication that
>    the proxy chain supports at least passthrough of this media.
> 
> 
> I didn't follow the inferred logic in the last sentence (how does the
> response convey support for the entire chain). Can you elaborate on that
> part ?

We have reformulated this to hopefully make it clear. But the logic is
like this.

If a client includes a transport specification with protocol D-ICE, and
that reaches the server and that supports it and provide that transport
spec in its answer that again reaches the client then you know that the
D-ICE is supported. This would only occur if any proxies are either
explicitly supporting it or are of the pass-through version.

That needs to be compared with a proxy-require where the passthrough
would be forced to negatively answer that. Also a supported header value
will be stripped by a passthrough proxy as it is not explicitly
supporting the functionality.

That is why you have cases where trying and see if it works might be the
best option.

> 
> - Section 8 (Fallback)
> Section title and overall description is a bit confusing (it seems to be
> about about backwards compatibility with non-ICE supporting RTSP entities).
> Also, the section recommends use of defunct (obsolete) behavior defined
> in RFC 3489 to try and determine the NAT type. Why is that (shouldn't we
> be based on RFC 5389) ?

This fallback text is intended as a discussion of what would happen if a
ICE enabled client would try to use its capabilities to facilitate
NAT/FW traversal when the server is non ICE capable.

The second thing to remember is that a SETUP request normally provides
multiple transport offers, rather than doing try, error, re-try other
alternative.

Thus I at least think it is worth talking what it would mean to use STUN
derived reflex ports as transport identifier and then be willing to send
STUN checks towards the server. So far you actually don't need to do a
attempt to determine the mapping behavior. If one would try it could
reveal the failure mode earlier.

But, maybe we should re-structure this section to say that like ICE the
best fallback addresses from functionality point of view would be a
relay address. Barring that one can attempt using a STUN derived one.
This may however fail, and have unexpected impact on server.

I do agree that we should not depend on the classification behavior of
the old STUN spec. But, the text really is a warning that this is brittle.

> Also, we could really use another set of eyes on it (preferably by
> somebody that has both ICE and RTSP expertise)

Me to.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From fluffy@cisco.com  Thu Oct 25 11:08:30 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E4521F899A for ; Thu, 25 Oct 2012 11:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.513
X-Spam-Level: 
X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bak31iWmcGuN for ; Thu, 25 Oct 2012 11:08:29 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 08C3D21F890B for ; Thu, 25 Oct 2012 11:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3459; q=dns/txt; s=iport; t=1351188509; x=1352398109; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Bq8L7mFh1reIajqmlGMbK9IO0qgl+KwuysXjTH+AF48=; b=gUA548l6zItHtQQw71zg+FLwFmASfOBs5YXxJtVERqnEaCZD2i7B/1h6 ZYM6S2b+DChGzbl1ftChNTSg0tGe4Y5fCIBzeD4gM7p97UBJhLV+xB0q9 AjYnJ8Mv5N8okdRaA6bm8NH1SuEgUsw9wjwNoqLuyzlvbfVvhV/FUjcjI I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJd/iVCtJV2d/2dsb2JhbABEwjCBCIIeAQEBAwEBAQEPAQpRCxACAQgYCiQnCyUCBA4FCAEZh1wGC55AoB6LYYYMYQOXDY07gWuCb4IZ
X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="135377437"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2012 18:08:28 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9PI8SlM029780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Oct 2012 18:08:28 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.217]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 13:08:27 -0500
From: "Cullen Jennings (fluffy)" 
To: mmusic WG 
Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
Thread-Index: AQHNstu7D9YwHt3fTEO3WzpM9C0/Cg==
Date: Thu, 25 Oct 2012 18:08:26 +0000
Message-ID: 
References: <5049096F.7080908@cisco.com> <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com>
In-Reply-To: <94A337B1-A851-47E3-9468-07D13C5630BD@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19306.000
x-tm-as-result: No--50.265900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <7197BA48B6CE4743BCF18A2CD09732B6@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Flemming Andreasen \(fandreas\)" , "draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org" 
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2012 18:08:30 -0000

Just to close out this thread=85.=20

I think I am in the rough part of the rough consensus on i18n so I have no =
objection to this draft going forward as is. Thanks to the folks who replie=
d to me.=20


On Sep 28, 2012, at 8:47 AM, Cullen Jennings (fluffy)  wr=
ote:

>=20
> Major comment=20
>=20
> I think the title stuff should be split out to a separate draft. The main=
 reason is that you might want to build a dvicd that supported title but di=
d not supper the others and still be able to say what you were doing was RF=
C X. For example, the RTC Web folks may want to use this.
>=20
> Given the Title is meant to be human readable, I think it needs to be ext=
ended to have normal i18n support.=20
>=20
> Cullen
>=20
>=20
>=20
> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen  wrote=
:
>=20
>> This is to announce a 2 week Working Group Last Call for=20
>>=20
>>     draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt=20
>>=20
>> as Proposed Standard. Please review and provide any comments you may hav=
e on the document by September 21, 2012. Comments should be sent to the doc=
ument authors and the MMUSIC WG list.=20
>>=20
>>=20
>> Thanks=20
>>=20
>>       Flemming
>>=20
>>=20
>>=20
>>=20
>> Draft Info:
>> This draft is a work item of the Multiparty Multimedia Session Control W=
orking Group of the IETF.
>>=20
>> 	Title           : Miscellanoues Capabilities Negotiation in the Session=
 Description Protocol (SDP)
>> 	Author(s)       : Miguel A. Garcia-Martin
>>                          Simo Veikkolainen
>>                          Robert R. Gilman
>> 	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
>> 	Pages           : 19
>> 	Date            : 2012-08-27
>>=20
>> Abstract:
>>   SDP has been extended with a capability negotiation mechanism
>>   framework that allows the endpoints to negotiate transport protocols
>>   and attributes.  This framework has been extended with a media
>>   capabilities negotiation mechanism that allows endpoints to negotiate
>>   additional media-related capabilities.  This negotiation is embedded
>>   into the widely-used SDP offer/answer procedures.
>>=20
>>   This memo extends the SDP capability negotiation framework to allow
>>   endpoints to negotiate three additional SDP capabilities.  In
>>   particular, this memo provides a mechanism to negotiate bandwidth
>>   ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line =
for
>>   each session or media).
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>>=20
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-cap=
s
>>=20
>>=20
>> There's also a htmlized version available at:
>>=20
>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01
>>=20
>>=20
>> A diff from the previous version is available at:
>>=20
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-c=
aps-01
>>=20
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>>=20
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From matthew@matthew.at  Thu Oct 25 15:40:24 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F85E21F8784 for ; Thu, 25 Oct 2012 15:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.43
X-Spam-Level: 
X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TcpUgzonMtN for ; Thu, 25 Oct 2012 15:40:23 -0700 (PDT)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id B617B21F8727 for ; Thu, 25 Oct 2012 15:40:23 -0700 (PDT)
Received: from [10.80.68.50] (unknown [131.107.147.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 8FA74148068 for ; Thu, 25 Oct 2012 15:40:23 -0700 (PDT)
Message-ID: <5089BFD6.5070109@matthew.at>
Date: Thu, 25 Oct 2012 15:40:22 -0700
From: Matthew Kaufman 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] 0.0.0.0 address in draft-rescorla-mmusic-ice-trickle-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Oct 2012 22:40:24 -0000

"In some cases, agents may choose to just send an offer that the remote 
party would reject as invalid unless it supports trickling. One such 
example would be an offer with no ICE candidates and an invalid default 
address (e.g. 0.0.0.0)."

Is there in fact evidence that some/most/all existing SDP-parsing SIP 
applications will in fact reject c= (and a=rtcp) lines that contain 
0.0.0.0 with an appropriate SDP-rejecting answer, rather than just 
answering affirmatively and attempting to send the media packets there?

If we can't confirm this to be the case, this is an inappropriate 
"negotiation" mechanism and the spec needs to get a little more concrete 
about it.

Matthew Kaufman

From dwing@cisco.com  Thu Oct 25 18:03:44 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3B21F8672 for ; Thu, 25 Oct 2012 18:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.588
X-Spam-Level: 
X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EGw4ySAr3lj for ; Thu, 25 Oct 2012 18:03:43 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C773E21F8620 for ; Thu, 25 Oct 2012 18:03:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2113; q=dns/txt; s=iport; t=1351213423; x=1352423023; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=9fLtrBwz8H4ck7V0abbxiTdmLVg2v2Ff6foK12mWKVw=; b=FtxLhYv3VHYShA3jddrSUyJYhK7js+fil8AqKuLM2kkc3/Kupor9XLqQ BVJDhGBNrRWqcoI8sG9Cq0s9Ff+3YF/jXUaPWM/O2JgP2QzHIn0VRUzQM b9qGLGr+2IGJbB3w7C7naLFp0si96MesHuW2Qml+GnR7LPMSkIJH/RfTq s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAAfhiVCrRDoJ/2dsb2JhbABEwjWBCIIeAQEBAwEBAQEFAggBJzQQBwEDAgkRBAEBKAcZDh8JCAIEARILBRKHXAUMnVqgHYthhm0DiFyFFYgFgReNO4Frgw8
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="59205506"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 26 Oct 2012 01:03:43 +0000
Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9Q13hhR031906; Fri, 26 Oct 2012 01:03:43 GMT
From: "Dan Wing" 
To: "'Matthew Kaufman'" , 
References: <5089BFD6.5070109@matthew.at>
In-Reply-To: <5089BFD6.5070109@matthew.at>
Date: Thu, 25 Oct 2012 18:03:43 -0700
Message-ID: <0b3001cdb315$be747240$3b5d56c0$@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLMrXEBLWMzMhvy8/ikuAnrOWlIwJXM0Dnw
Content-Language: en-us
Subject: Re: [MMUSIC] 0.0.0.0 address in draft-rescorla-mmusic-ice-trickle-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Oct 2012 01:03:44 -0000

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Matthew Kaufman
> Sent: Thursday, October 25, 2012 3:40 PM
> To: mmusic@ietf.org
> Subject: [MMUSIC] 0.0.0.0 address in draft-rescorla-mmusic-ice-trickle-
> 01
> 
> "In some cases, agents may choose to just send an offer that the remote
> party would reject as invalid unless it supports trickling. One such
> example would be an offer with no ICE candidates and an invalid default
> address (e.g. 0.0.0.0)."
> 
> Is there in fact evidence that some/most/all existing SDP-parsing SIP
> applications will in fact reject c= (and a=rtcp) lines that contain
> 0.0.0.0 with an appropriate SDP-rejecting answer, rather than just
> answering affirmatively and attempting to send the media packets there?

By my read, they violate the last paragraph of RFC3264 Section 8.4,
http://tools.ietf.org/html/rfc3264#section-8.4, which says:

   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer.

-d

> If we can't confirm this to be the case, this is an inappropriate
> "negotiation" mechanism and the spec needs to get a little more concrete
> about it.
> 
> Matthew Kaufman
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From bernard_aboba@hotmail.com  Sat Oct 27 08:37:00 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4C221F84CA for ; Sat, 27 Oct 2012 08:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.988
X-Spam-Level: 
X-Spam-Status: No, score=-100.988 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWXmAN7gdCuv for ; Sat, 27 Oct 2012 08:36:57 -0700 (PDT)
Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by ietfa.amsl.com (Postfix) with ESMTP id A0B6921F8462 for ; Sat, 27 Oct 2012 08:36:57 -0700 (PDT)
Received: from BLU169-DS3 ([65.55.111.71]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 27 Oct 2012 08:36:56 -0700
X-Originating-IP: [131.107.0.87]
X-EIP: [TYjiccmlDgHN13tJrPSq8IZpv4NzLnHx]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: 
From: Bernard Aboba 
To: 
Date: Sat, 27 Oct 2012 08:36:55 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0362_01CDB41E.3910BFF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac20TijxCHxPx0ojSHmw0osOv8YJ+Q==
Content-Language: en-us
X-OriginalArrivalTime: 27 Oct 2012 15:36:56.0205 (UTC) FILETIME=[E560A3D0:01CDB458]
Subject: Re: [MMUSIC] 0.0.0.0 address in draft-rescorla-mmusic-ice-trickle-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Oct 2012 15:37:00 -0000

------=_NextPart_000_0362_01CDB41E.3910BFF0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dan Wing said:

 

"By my read, they violate the last paragraph of RFC3264 Section 8.4,
http://tools.ietf.org/html/rfc3264#section-8.4, which says:
 
   RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer.
 
-d"
 
[BA] I believe that there is an issue here, but it is with RFC 5245, not RFC
3264. The RFC 3264 paragraph you cite points out the issues with using
0.0.0.0 to place a user on hold, but that is not suggested in
draft-rescorla-mmusic-ice-trickle.  The usage that is suggested (potential
usage of 0.0.0.0 as a placeholder) is described in the above paragraph, with
agents being required to be able to "receive it" (provided that the port
number is not zero).  The problem is how RFC 5245 implementations will
react.  From RFC 5245 Section 9.1.1.1:
 
   These rules imply that setting the IP address in the c line to
   0.0.0.0 will cause an ICE restart.  Consequently, ICE implementations
   MUST NOT utilize this mechanism for call hold, and instead MUST use
   a=inactive and a=sendonly as described in [RFC3264
 ].
 
The implication is that a SIP error is not generated, indicating that
trickle is unsupported; rather, RFC 5245 implies that implementations may
generate repeated ICE restarts as the trickling proceeds.
 
To understand this better, it might help to test what RFC 5245
implementations actually do in response to a trickle offer. 

 

 

[BA] SDP from createOffer(), Chrome Version 24.0.1297.0 dev

v=0
o=- 1321413050 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:9wMh/Gc6fgJBzvzQ
a=ice-pwd:4I4SozPeoRtm9C58OF8M/deY
a=ice-options:google-ice
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=ssrc:1635880669 cname:ZXVf3drwG3fT+Wh5
a=ssrc:1635880669 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=ssrc:1635880669 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr00
m=video 1 RTP/SAVPF 100 101 102
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:9wMh/Gc6fgJBzvzQ
a=ice-pwd:4I4SozPeoRtm9C58OF8M/deY
a=ice-options:google-ice
a=sendrecv
a=mid:video
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
a=rtpmap:100 VP8/90000
a=rtpmap:101 red/90000
a=rtpmap:102 ulpfec/90000
a=ssrc:1563041388 cname:ZXVf3drwG3fT+Wh5
a=ssrc:1563041388 mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=ssrc:1563041388 label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr10


------=_NextPart_000_0362_01CDB41E.3910BFF0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Dan Wing =
said:
 
“By my read, they =
violate the last paragraph of RFC3264 Section =
8.4,
http://tools.ietf=
.org/html/rfc3264#section-8.4, which =
says:
 
   RFC =
2543 [10] specified that placing a user on hold was =
accomplished
   by setting the connection =
address to 0.0.0.0.  Its usage for =
putting
   a call on hold is no longer =
recommended, since it doesn't allow =
for
   RTCP to be used with held streams, =
doesn't work with IPv6, and breaks
   =
with connection oriented media.  However, it can be useful in =
an
   initial offer when the offerer =
knows it wants to use a particular set
   =
of media streams and formats, but doesn't know the addresses =
and
   ports at the time of the =
offer.  Of course, when used, the =
port
   number MUST NOT be zero, which =
would specify that the stream has been
   =
disabled.  An agent MUST be capable of receiving SDP with =
a
   connection address of 0.0.0.0, in =
which case it means that neither
   RTP =
nor RTCP should be sent to the =
peer.
 
-d”
 
[BA] I believe that there is an =
issue here, but it is with RFC 5245, not RFC 3264. The RFC 3264 =
paragraph you cite points out the issues with using 0.0.0.0 to place a =
user on hold, but that is not suggested in =
draft-rescorla-mmusic-ice-trickle.  The usage that is suggested =
(potential usage of 0.0.0.0 as a placeholder) is described in the above =
paragraph, with agents being required to be able to “receive =
it” (provided that the port number is not zero).  The problem =
is how RFC 5245 implementations will react.  From RFC 5245 Section =
9.1.1.1:
 
   =
These rules imply that setting the IP address in the c line =
to
   0.0.0.0 will cause an ICE =
restart.  Consequently, ICE =
implementations
   MUST NOT utilize this =
mechanism for call hold, and instead MUST =
use
   a=3Dinactive and a=3Dsendonly as =
described in [RFC3264].
 
The implication is that a SIP error is not generated, indicating that =
trickle is unsupported; rather, RFC 5245 implies that implementations =
may generate repeated ICE restarts as the trickling =
proceeds.
 
To understand =
this better, it might help to test what RFC 5245 implementations =
actually do in response to a trickle offer. =

 
 
[BA] SDP from createOffer(), Chrome Version =
24.0.1297.0 dev

v=3D0
o=3D- 1321413050 2 IN IP4 =
127.0.0.1
s=3D-
t=3D0 0
a=3Dgroup:BUNDLE audio =
video
m=3Daudio 1 RTP/SAVPF 103 104 0 8 106 105 13 126
c=3DIN IP4 =
0.0.0.0
a=3Drtcp:1 IN IP4 =
0.0.0.0
a=3Dice-ufrag:9wMh/Gc6fgJBzvzQ
a=3Dice-pwd:4I4SozPeoRtm9C58=
OF8M/deY
a=3Dice-options:google-ice
a=3Dsendrecv
a=3Dmid:audioa=3Drtcp-mux
a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_80 =
inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
a=3Drtpmap:103 =
ISAC/16000
a=3Drtpmap:104 ISAC/32000
a=3Drtpmap:0 =
PCMU/8000
a=3Drtpmap:8 PCMA/8000
a=3Drtpmap:106 =
CN/32000
a=3Drtpmap:105 CN/16000
a=3Drtpmap:13 =
CN/8000
a=3Drtpmap:126 telephone-event/8000
a=3Dssrc:1635880669 =
cname:ZXVf3drwG3fT+Wh5
a=3Dssrc:1635880669 =
mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=3Dssrc:1635880669 =
label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr00
m=3Dvideo 1 RTP/SAVPF =
100 101 102
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 =
0.0.0.0
a=3Dice-ufrag:9wMh/Gc6fgJBzvzQ
a=3Dice-pwd:4I4SozPeoRtm9C58=
OF8M/deY
a=3Dice-options:google-ice
a=3Dsendrecv
a=3Dmid:videoa=3Drtcp-mux
a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_80 =
inline:JyWcGXs7j0U5aWAj8RlUdSwWkBRtmbvg3njMO1FB
a=3Drtpmap:100 =
VP8/90000
a=3Drtpmap:101 red/90000
a=3Drtpmap:102 =
ulpfec/90000
a=3Dssrc:1563041388 =
cname:ZXVf3drwG3fT+Wh5
a=3Dssrc:1563041388 =
mslabel:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr
a=3Dssrc:1563041388 =
label:cLFXFpfLOP31s7D1A9on2I2rAvhTKqGSZEWr10
<=
/html>
------=_NextPart_000_0362_01CDB41E.3910BFF0--

From emcho@sip-communicator.org  Sat Oct 27 14:27:42 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C482321F84A6 for ; Sat, 27 Oct 2012 14:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.377
X-Spam-Level: 
X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m85Q72TfXgB7 for ; Sat, 27 Oct 2012 14:27:42 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA48721F8461 for ; Sat, 27 Oct 2012 14:27:41 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id x24so1239060iak.31 for ; Sat, 27 Oct 2012 14:27:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=A2H+v/HlbIHjzBdv1Kr461wb/ziWmKWWSO9aJCKu9TY=; b=UrhdVAeTmD7xdVNATNvEp+jpDqXsNhC7/EgZnjmqWXGJ2XweURY81CEGfiS3MknDzN EcJm7xXSVBIBPvDmLJVivVzj0irO1nbXZPx+eYeFtffOxVCsCFJr6UFMjBDMWiR65B5a ZsbblgyOXnU2YUd3WpniKtsNQCHgymEV5YgWI4LzkmXpjLaiwkWIoOgDZihyHbJ3wKsK HvJFK0kNfqlTTleuQh9NQfGYwv0P2PD+vSgkyM1tiEjpjM5xRhdadKqiOvxVc9ZnW6R3 Xznv2+unMxtlEo5XN1E6mKfl7kfbUY30lAoQc5SVtX34G6bhkHh4O9i1hND58WHVPsVD tYjQ==
Received: by 10.43.52.193 with SMTP id vn1mr22697652icb.5.1351373261400; Sat, 27 Oct 2012 14:27:41 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by mx.google.com with ESMTPS id gs6sm2317684igc.11.2012.10.27.14.27.40 (version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 14:27:41 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so5861734iec.31 for ; Sat, 27 Oct 2012 14:27:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.91.169 with SMTP id cf9mr5674298igb.44.1351373260380; Sat, 27 Oct 2012 14:27:40 -0700 (PDT)
Received: by 10.42.63.146 with HTTP; Sat, 27 Oct 2012 14:27:39 -0700 (PDT)
Received: by 10.42.63.146 with HTTP; Sat, 27 Oct 2012 14:27:39 -0700 (PDT)
In-Reply-To: 
References: <507FC10D.60500@ericsson.com> 
Date: Sat, 27 Oct 2012 23:27:39 +0200
Message-ID: 
From: Emil Ivov 
To: "Muthu Arul Mozhi Perumal (mperumal)" 
Content-Type: multipart/alternative; boundary=e89a8f3b9dad24db9804cd111b64
X-Gm-Message-State: ALoCoQlm37tK+A8kUxGCVuBxWVSflSI8Yf1OXebpoxXXMEjTQaxyFT7Vec3QE0uvsZLPh/mnLdKm
Cc: Flemming Andreasen , mmusic , "Dan Wing \(dwing\)" 
Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Oct 2012 21:27:42 -0000

--e89a8f3b9dad24db9804cd111b64
Content-Type: text/plain; charset=ISO-8859-1

Well I certainly haven't been around long enough to know if there are
people who would have supported this but might have missed the mail.

If you guys don't either, then maybe we can go back to the original plan.
IIRC, back in Paris Gonzalo had agreed to AD sponsor it. Is this still an
option?

--sent from my mobile
On Oct 18, 2012 2:09 PM, "Muthu Arul Mozhi Perumal (mperumal)" <
mperumal@cisco.com> wrote:

> I support it. I think it is quite informative.
>
> Muthu
>
> |-----Original Message-----
> |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Miguel A. Garcia
> |Sent: Thursday, October 18, 2012 2:13 PM
> |To: mmusic
> |Cc: Flemming Andreasen (fandreas); Dan Wing (dwing)
> |Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft
> |
> |At the last IETF meeting we had a presentation of the following draft:
> |
> |http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/
> |
> |At that time, there was interest in adopting this document as WG item. We
> |currently have a milestone to submit an informational document describing
> |current practices in hosted NAT traversal, where this document fits.
> |
> |We would like to poll the working group to reconfirm the consensus on
> |adopting the above mentioned draft as a working group item.
> |
> |If you support this work or have problems with the adoption of this
> |document as WG item, please indicate it by replying to this e-mail within
> |the next 5 days.
> |
> |     Miguel and Flemming (co-chairs)
> |--
> |Miguel A. Garcia
> |+34-91-339-3608
> |Ericsson Spain
> |_______________________________________________
> |mmusic mailing list
> |mmusic@ietf.org
> |https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--e89a8f3b9dad24db9804cd111b64
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Well I certainly haven't been around long enough to know=
 if there are people who would have supported this but might have missed th=
e mail.


If you guys don't either, then maybe we can go back to t=
he original plan. IIRC, back in Paris Gonzalo had agreed to AD sponsor it. =
Is this still an option?


--sent from my mobile


On Oct 18, 2012 2:09 PM, "Muthu Arul Mozhi =
Perumal (mperumal)" <mperumal=
@cisco.com> wrote:

I support it. I think it is quite informative.



Muthu



|-----Original Message-----

|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o=
rg] On Behalf Of Miguel A. Garcia

|Sent: Thursday, October 18, 2012 2:13 PM

|To: mmusic

|Cc: Flemming Andreasen (fandreas); Dan Wing (dwing)

|Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft

|

|At the last IETF meeting we had a presentation of the following draft:

|

|http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/=


|

|At that time, there was interest in adopting this document as WG item. We<=
br>
|currently have a milestone to submit an informational document describing<=
br>
|current practices in hosted NAT traversal, where this document fits.

|

|We would like to poll the working group to reconfirm the consensus on

|adopting the above mentioned draft as a working group item.

|

|If you support this work or have problems with the adoption of this

|document as WG item, please indicate it by replying to this e-mail within<=
br>
|the next 5 days.

|

| =A0 =A0 Miguel and Flemming (co-chairs)

|--

|Miguel A. Garcia

|+34-91-339-3608

|Ericsson Spain

|_______________________________________________

|mmusic mailing list

|mmusic@ietf.org

|https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________

mmusic mailing list

mmusic@ietf.org

=
https://www.ietf.org/mailman/listinfo/mmusic




--e89a8f3b9dad24db9804cd111b64--

From miguel.a.garcia@ericsson.com  Sun Oct 28 02:43:38 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE7021F8630 for ; Sun, 28 Oct 2012 02:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w1hAGUGVTSj for ; Sun, 28 Oct 2012 02:43:38 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAA521F862D for ; Sun, 28 Oct 2012 02:43:36 -0700 (PDT)
X-AuditID: c1b4fb25-b7f926d00000661f-de-508cfe474d3f
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.43.26143.74EFC805; Sun, 28 Oct 2012 10:43:35 +0100 (CET)
Received: from [159.107.48.58] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sun, 28 Oct 2012 10:43:34 +0100
Message-ID: <508CFE3B.1050000@ericsson.com>
Date: Sun, 28 Oct 2012 10:43:23 +0100
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Emil Ivov 
References: <507FC10D.60500@ericsson.com>  
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvra77v54Ag9vPdC0uXnvIZLFm5wQW i/cXdC2mLn/MYnHn0xxWB1aPKb83snosWfKTyeP/m8AA5igum5TUnMyy1CJ9uwSujB8b37MV PBOt2Hh8EnMD4xWBLkZODgkBE4nHy76wQ9hiEhfurWfrYuTiEBI4ySix/NRPZghnNaNE8/Ez bCBVvALaEv9ObWIBsVkEVCWu/PsN1s0mYC7RunEjkM3BISoQLNF1WAyiXFDi5MwnYOUiAvIS 3W2LmEBmMgusYZTY9fUnE0i9sICbxNPbWhC71jNKdH+CuIhTIFBi1cr7TCA2s4CtxIU511kg bHmJ7W/nMIPYQgKaEpNvLmWewCg4C8m+WUhaZiFpWcDIvIqRPTcxMye93GgTIzBwD275rbqD 8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLglGpgjC1dMzP90vzNT6cq y+17+qLq62YmSZ5MX//p3m/l9BJcOavn3xWwbGf2XLdR96WS1sWFhqW1JRO65a7IONpcybi+ pDkkeErs4yW7HVequWayT+Z5/vDzwwcmh5MN18y8ZfGVzbFxbmjQmzTHN5wGvPWHe//flUpV dzSumq98s1JLdjeXAbeFEktxRqKhFnNRcSIAmvaQBioCAAA=
Cc: Flemming Andreasen , mmusic , "Dan Wing \(dwing\)" 
Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Oct 2012 09:43:38 -0000

MMUSIC followers,

I would like to call for more opinions about this draft. It is hard for 
the chairs to evaluate the level of support of a draft when there is 
silence (except for Muthu).

Opinions can be of the type "I support", "I believe we shouldn't work on 
this", or "I don't mind/care". All of them are very valuable to the chairs.

So, please, voice your opinion about this draft.

/Miguel

On 27/10/2012 23:27, Emil Ivov wrote:
> Well I certainly haven't been around long enough to know if there are
> people who would have supported this but might have missed the mail.
>
> If you guys don't either, then maybe we can go back to the original plan.
> IIRC, back in Paris Gonzalo had agreed to AD sponsor it. Is this still an
> option?
>
> --sent from my mobile
>
> On Oct 18, 2012 2:09 PM, "Muthu Arul Mozhi Perumal (mperumal)"
> > wrote:
>
>     I support it. I think it is quite informative.
>
>     Muthu
>
>     |-----Original Message-----
>     |From: mmusic-bounces@ietf.org 
>     [mailto:mmusic-bounces@ietf.org ] On
>     Behalf Of Miguel A. Garcia
>     |Sent: Thursday, October 18, 2012 2:13 PM
>     |To: mmusic
>     |Cc: Flemming Andreasen (fandreas); Dan Wing (dwing)
>     |Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft
>     |
>     |At the last IETF meeting we had a presentation of the following draft:
>     |
>     |http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/
>     |
>     |At that time, there was interest in adopting this document as WG
>     item. We
>     |currently have a milestone to submit an informational document
>     describing
>     |current practices in hosted NAT traversal, where this document fits.
>     |
>     |We would like to poll the working group to reconfirm the consensus on
>     |adopting the above mentioned draft as a working group item.
>     |
>     |If you support this work or have problems with the adoption of this
>     |document as WG item, please indicate it by replying to this e-mail
>     within
>     |the next 5 days.
>     |
>     |     Miguel and Flemming (co-chairs)
>     |--
>     |Miguel A. Garcia
>     |+34-91-339-3608 
>     |Ericsson Spain
>     |_______________________________________________
>     |mmusic mailing list
>     |mmusic@ietf.org 
>     |https://www.ietf.org/mailman/listinfo/mmusic
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org 
>     https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From dwing@cisco.com  Sun Oct 28 09:21:19 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6C21F86B8 for ; Sun, 28 Oct 2012 09:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHGDEP5hosWo for ; Sun, 28 Oct 2012 09:21:18 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E4AD421F85D5 for ; Sun, 28 Oct 2012 09:21:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2500; q=dns/txt; s=iport; t=1351441278; x=1352650878; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=u+fAs4fBRmsiog0L2FJW0HAjiHfBqRYbq0aZs9d/IOY=; b=OWHje1ZXbfPHhWASfd0HGKBB00lWms8M4ymXsUDgWczO28W94ilVLSp8 TG1KIkQt4/bDN24WHouStRzyT+N6pjNbhaWtra/vdeU4BL6XqB1Dhli2J 3qEVVmmoz5mHR+BeXgmSc7se/IOOFxe918jFPEabo9CsRlr4vGWMjIx42 Q=;
X-IronPort-AV: E=Sophos;i="4.80,667,1344211200"; d="scan'208";a="59416573"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 28 Oct 2012 16:21:18 +0000
Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9SGLIus007304; Sun, 28 Oct 2012 16:21:18 GMT
From: "Dan Wing" 
To: "'Emil Ivov'" , "'Muthu Arul Mozhi Perumal \(mperumal\)'" 
References: <507FC10D.60500@ericsson.com>	 
In-Reply-To: 
Date: Sun, 28 Oct 2012 09:21:18 -0700
Message-ID: <017901cdb528$42c9c090$c85d41b0$@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFXADkHFZ2JP+j0eza5rIRpGxqnXAI0nBdeAmjm4NCYl2PeoA==
Content-Language: en-us
Cc: 'Flemming Andreasen' , 'mmusic' 
Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Oct 2012 16:21:19 -0000

> -----Original Message-----
> From: Emil Ivov [mailto:emcho@jitsi.org]
> Sent: Saturday, October 27, 2012 2:28 PM
> To: Muthu Arul Mozhi Perumal (mperumal)
> Cc: Flemming Andreasen; mmusic; Miguel A. Garcia; Dan Wing (dwing)
> Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft
> 
> Well I certainly haven't been around long enough to know if there are
> people who would have supported this but might have missed the mail.
> 
> If you guys don't either, then maybe we can go back to the original
> plan. IIRC, back in Paris Gonzalo had agreed to AD sponsor it. Is this
> still an option?

I'm fine with AD sponsoring of it.  Going through MMUSIC would be better,
though, of course. 

I see you asked the WG again.  Maybe someone will speak up.

-d


> --sent from my mobile
> 
> On Oct 18, 2012 2:09 PM, "Muthu Arul Mozhi Perumal (mperumal)"
>  wrote:
> 
> 
> 	I support it. I think it is quite informative.
> 
> 	Muthu
> 
> 	|-----Original Message-----
> 	|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Miguel A. Garcia
> 	|Sent: Thursday, October 18, 2012 2:13 PM
> 	|To: mmusic
> 	|Cc: Flemming Andreasen (fandreas); Dan Wing (dwing)
> 	|Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft
> 	|
> 	|At the last IETF meeting we had a presentation of the following
> draft:
> 	|
> 	|http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/
> 	|
> 	|At that time, there was interest in adopting this document as WG
> item. We
> 	|currently have a milestone to submit an informational document
> describing
> 	|current practices in hosted NAT traversal, where this document
> fits.
> 	|
> 	|We would like to poll the working group to reconfirm the consensus
> on
> 	|adopting the above mentioned draft as a working group item.
> 	|
> 	|If you support this work or have problems with the adoption of
> this
> 	|document as WG item, please indicate it by replying to this e-mail
> within
> 	|the next 5 days.
> 	|
> 	|     Miguel and Flemming (co-chairs)
> 	|--
> 	|Miguel A. Garcia
> 	|+34-91-339-3608 
> 	|Ericsson Spain
> 	|_______________________________________________
> 	|mmusic mailing list
> 	|mmusic@ietf.org
> 	|https://www.ietf.org/mailman/listinfo/mmusic
> 	_______________________________________________
> 	mmusic mailing list
> 	mmusic@ietf.org
> 	https://www.ietf.org/mailman/listinfo/mmusic
> 



From pkyzivat@alum.mit.edu  Sun Oct 28 14:20:04 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855A321F85A5 for ; Sun, 28 Oct 2012 14:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level: 
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD5TcFMKXXdp for ; Sun, 28 Oct 2012 14:20:03 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 72A4D21F855C for ; Sun, 28 Oct 2012 14:20:01 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id GlCT1k0010SCNGk56lL6si; Sun, 28 Oct 2012 21:20:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id GlLY1k0113ZTu2S3VlLZky; Sun, 28 Oct 2012 21:20:33 +0000
Message-ID: <508DA17F.8000701@alum.mit.edu>
Date: Sun, 28 Oct 2012 17:19:59 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <507FC10D.60500@ericsson.com>   <508CFE3B.1050000@ericsson.com>
In-Reply-To: <508CFE3B.1050000@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Oct 2012 21:20:04 -0000

I support this - I think it is desirable to have this behavior 
documented, since behavior similar to this is fairly widespread. 
Hopefully having it documented will help prevent gratuitous variation.

	Thanks,
	Paul

On 10/28/12 5:43 AM, Miguel A. Garcia wrote:
> MMUSIC followers,
>
> I would like to call for more opinions about this draft. It is hard for
> the chairs to evaluate the level of support of a draft when there is
> silence (except for Muthu).
>
> Opinions can be of the type "I support", "I believe we shouldn't work on
> this", or "I don't mind/care". All of them are very valuable to the chairs.
>
> So, please, voice your opinion about this draft.
>
> /Miguel
>
> On 27/10/2012 23:27, Emil Ivov wrote:
>> Well I certainly haven't been around long enough to know if there are
>> people who would have supported this but might have missed the mail.
>>
>> If you guys don't either, then maybe we can go back to the original plan.
>> IIRC, back in Paris Gonzalo had agreed to AD sponsor it. Is this still an
>> option?
>>
>> --sent from my mobile
>>
>> On Oct 18, 2012 2:09 PM, "Muthu Arul Mozhi Perumal (mperumal)"
>> > wrote:
>>
>>     I support it. I think it is quite informative.
>>
>>     Muthu
>>
>>     |-----Original Message-----
>>     |From: mmusic-bounces@ietf.org 
>>     [mailto:mmusic-bounces@ietf.org ] On
>>     Behalf Of Miguel A. Garcia
>>     |Sent: Thursday, October 18, 2012 2:13 PM
>>     |To: mmusic
>>     |Cc: Flemming Andreasen (fandreas); Dan Wing (dwing)
>>     |Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft
>>     |
>>     |At the last IETF meeting we had a presentation of the following
>> draft:
>>     |
>>     |http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/
>>     |
>>     |At that time, there was interest in adopting this document as WG
>>     item. We
>>     |currently have a milestone to submit an informational document
>>     describing
>>     |current practices in hosted NAT traversal, where this document fits.
>>     |
>>     |We would like to poll the working group to reconfirm the
>> consensus on
>>     |adopting the above mentioned draft as a working group item.
>>     |
>>     |If you support this work or have problems with the adoption of this
>>     |document as WG item, please indicate it by replying to this e-mail
>>     within
>>     |the next 5 days.
>>     |
>>     |     Miguel and Flemming (co-chairs)
>>     |--
>>     |Miguel A. Garcia
>>     |+34-91-339-3608 
>>     |Ericsson Spain
>>     |_______________________________________________
>>     |mmusic mailing list
>>     |mmusic@ietf.org 
>>     |https://www.ietf.org/mailman/listinfo/mmusic
>>     _______________________________________________
>>     mmusic mailing list
>>     mmusic@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>
>


From enrico.marocco@telecomitalia.it  Sun Oct 28 15:05:59 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3194D21F869F for ; Sun, 28 Oct 2012 15:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.719
X-Spam-Level: 
X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeafN2G28BFk for ; Sun, 28 Oct 2012 15:05:58 -0700 (PDT)
Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id B8EA521F868D for ; Sun, 28 Oct 2012 15:05:56 -0700 (PDT)
Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.279.5; Sun, 28 Oct 2012 23:05:54 +0100
Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.279.5; Sun, 28 Oct 2012 23:05:54 +0100
Message-ID: <508DAC41.8040105@telecomitalia.it>
Date: Sun, 28 Oct 2012 23:05:53 +0100
From: Enrico Marocco 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: 
References: <507FC10D.60500@ericsson.com>   <508CFE3B.1050000@ericsson.com> <508DA17F.8000701@alum.mit.edu>
In-Reply-To: <508DA17F.8000701@alum.mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070900010009020608050904"
X-TI-Disclaimer: Disclaimer1
Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Oct 2012 22:05:59 -0000

--------------ms070900010009020608050904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I want to second Paul on this. This draft describes a very common
behavior and having it documented will be useful. With a slight
preference for the WG stream -- the more the eyeballs the better.

Enrico

On 10/28/12 10:19 PM, Paul Kyzivat wrote:
> I support this - I think it is desirable to have this behavior=20
> documented, since behavior similar to this is fairly widespread.=20
> Hopefully having it documented will help prevent gratuitous variation.
>=20
> 	Thanks,
> 	Paul
>=20
> On 10/28/12 5:43 AM, Miguel A. Garcia wrote:
>> MMUSIC followers,
>>
>> I would like to call for more opinions about this draft. It is hard fo=
r
>> the chairs to evaluate the level of support of a draft when there is
>> silence (except for Muthu).
>>
>> Opinions can be of the type "I support", "I believe we shouldn't work =
on
>> this", or "I don't mind/care". All of them are very valuable to the ch=
airs.
>>
>> So, please, voice your opinion about this draft.
>>
>> /Miguel
>>
>> On 27/10/2012 23:27, Emil Ivov wrote:
>>> Well I certainly haven't been around long enough to know if there are=

>>> people who would have supported this but might have missed the mail.
>>>
>>> If you guys don't either, then maybe we can go back to the original p=
lan.
>>> IIRC, back in Paris Gonzalo had agreed to AD sponsor it. Is this stil=
l an
>>> option?
>>>
>>> --sent from my mobile
>>>
>>> On Oct 18, 2012 2:09 PM, "Muthu Arul Mozhi Perumal (mperumal)"
>>> > wrote:
>>>
>>>     I support it. I think it is quite informative.
>>>
>>>     Muthu
>>>
>>>     |-----Original Message-----
>>>     |From: mmusic-bounces@ietf.org 
>>>     [mailto:mmusic-bounces@ietf.org ]=
 On
>>>     Behalf Of Miguel A. Garcia
>>>     |Sent: Thursday, October 18, 2012 2:13 PM
>>>     |To: mmusic
>>>     |Cc: Flemming Andreasen (fandreas); Dan Wing (dwing)
>>>     |Subject: [MMUSIC] WG Poll for consensus on WG item: latching dra=
ft
>>>     |
>>>     |At the last IETF meeting we had a presentation of the following
>>> draft:
>>>     |
>>>     |http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/
>>>     |
>>>     |At that time, there was interest in adopting this document as WG=

>>>     item. We
>>>     |currently have a milestone to submit an informational document
>>>     describing
>>>     |current practices in hosted NAT traversal, where this document f=
its.
>>>     |
>>>     |We would like to poll the working group to reconfirm the
>>> consensus on
>>>     |adopting the above mentioned draft as a working group item.
>>>     |
>>>     |If you support this work or have problems with the adoption of t=
his
>>>     |document as WG item, please indicate it by replying to this e-ma=
il
>>>     within
>>>     |the next 5 days.
>>>     |
>>>     |     Miguel and Flemming (co-chairs)
>>>     |--
>>>     |Miguel A. Garcia
>>>     |+34-91-339-3608 
>>>     |Ericsson Spain
>>>     |_______________________________________________
>>>     |mmusic mailing list
>>>     |mmusic@ietf.org 
>>>     |https://www.ietf.org/mailman/listinfo/mmusic
>>>     _______________________________________________
>>>     mmusic mailing list
>>>     mmusic@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>=20



--------------ms070900010009020608050904
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC
BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr
lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM
zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6
qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD
kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95
m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD
CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy
6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI
zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf
KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR
z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9
sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie
uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t
w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ
G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t
5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB
BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz
WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD
DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp
Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/
5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r
rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN
uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0
UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID
ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG
AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S
nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh
bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH
AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq
MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp
ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g
cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg
Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg
cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp
bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6
Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2
aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0
MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC
AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs
kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6
R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE
GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect
f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB
MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA
oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMjgy
MjA1NTNaMCMGCSqGSIb3DQEJBDEWBBSSpLHYWIZw19lK6Q12LJlUF6pCOTBsBgkqhkiG9w0B
CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE
AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T
dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn
BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB
AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAk7fadztnLBukDhljtP2d+Wo6pqz4ecdxqq7WbNmz
sjPHkGevK/+ap++9xTzUGud8qp91dgbjWjPB5DWeMQ0mCx5+gp0aKG79o8AxxsuM6cBnnvpM
dTSupiOA0CaD7tnNQvg6pKM1biViaYYUCzZkpQPQbptNImenC0Ex+tZYg/U7veg7/IO9RQLh
6+w7tWsckddhuPPaGYsTfy3bdmyE8PNYGD6P1lqce0Z3t3H9nGqIVFTcgjB/C4TeGEfjCAof
HW/Vwn0UcZ5HZMnHtDoz6ezThaL4UJW4Ah87/iAdO/Phm8I4MhHnyeyMEthhN5FKzEpRdSyp
Y1pb1LpKRBfdDgAAAAAAAA==
--------------ms070900010009020608050904--

From miguel.a.garcia@ericsson.com  Mon Oct 29 05:25:07 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C494A21F855C for ; Mon, 29 Oct 2012 05:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sgg1YGsij3-4 for ; Mon, 29 Oct 2012 05:25:06 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5C221F8529 for ; Mon, 29 Oct 2012 05:25:05 -0700 (PDT)
X-AuditID: c1b4fb30-b7f936d0000018b3-2a-508e75a0b16a
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0D.06.06323.0A57E805; Mon, 29 Oct 2012 13:25:04 +0100 (CET)
Received: from [159.107.48.58] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 29 Oct 2012 13:25:04 +0100
Message-ID: <508E759F.3040405@ericsson.com>
Date: Mon, 29 Oct 2012 13:25:03 +0100
From: "Miguel A. Garcia" 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJMWRmVeSWpSXmKPExsUyM+Jvre6C0r4Ag/eHrC3eX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbF2yzfWgg1MFd37P7M1MH5g7GLk5JAQMJE4 eeoqK4QtJnHh3nq2LkYuDiGBk4wSM6avYoFwVjNKTGm6xwxSxSugLXG08Sw7iM0ioCrx/c4V sDibgLlE68aNQHEODlGBYImuw2IQ5YISJ2c+YQGxRQRkJPZu2gxWzgw0ZvadWUwgtrCAkcS3 f5NZIOK2EhfmXIey5SW2v50DVi8koCkx+eZS5gmM/LOQjJ2FpGUWkpYFjMyrGNlzEzNz0svN NzECA+zglt8GOxg33Rc7xCjNwaIkzqunut9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PU Sg/b0JsnLD2nPv26k2kD67vO1N1RJgqdjlP0u6qer97/ZdeXLOn6TMHJmV99Ldym1U6ZcW2R mYzE+XWn6xtzu8OFbX5s0rzcWqrkttBinueuV6bzbbK5rwq8P517MJlnz/NNnDfkbIV3s//j bmFTOLel6KqAlrOzSMyO75P3OLaubeFuTlRiKc5INNRiLipOBACBEzBH/gEAAA==
Cc: Flemming Andreasen 
Subject: [MMUSIC] Agenda of MMUSIC WG  at IETF 85 (Atlanta)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2012 12:25:07 -0000

Greetings.

The preliminary agenda for the MMUSIC WG meeting at IETF 84 in
Atlanta is available:

https://datatracker.ietf.org/meeting/85/agenda/mmusic/

Please send feedback to Flemming and myself.

Cheers,

     Flemming and Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

From iesg-secretary@ietf.org  Mon Oct 29 08:49:19 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D071321F8718; Mon, 29 Oct 2012 08:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2inYyopPCJZr; Mon, 29 Oct 2012 08:49:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6828421F8231; Mon, 29 Oct 2012 08:49:19 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121029154919.23893.32746.idtracker@ietfa.amsl.com>
Date: Mon, 29 Oct 2012 08:49:19 -0700
Cc: mmusic@ietf.org
Subject: [MMUSIC] Last Call:  (Session	Description Protocol (SDP) Media Capabilities Negotiation) to	Proposed Standard
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2012 15:49:20 -0000

The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'Session Description Protocol (SDP) Media Capabilities Negotiation'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Session Description Protocol (SDP) capability negotiation provides a
   general framework for indicating and negotiating capabilities in SDP.
   The base framework defines only capabilities for negotiating
   transport protocols and attributes.  In this document, we extend the
   framework by defining media capabilities that can be used to
   negotiate media types and their associated parameters.

   This document updates the IANA Considerations of RFC 5939.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-media-capabilities/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-media-capabilities/ballot/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/829/




From fandreas@cisco.com  Mon Oct 29 11:39:14 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6551F21F8711 for ; Mon, 29 Oct 2012 11:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wq9ZYYASxed for ; Mon, 29 Oct 2012 11:39:13 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BCEFB21F8720 for ; Mon, 29 Oct 2012 11:39:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4847; q=dns/txt; s=iport; t=1351535952; x=1352745552; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2PuQuexzVf7aw+s6tlMkDWlbQsAdaXddQ0dCJHcS0KY=; b=lc0ADOYczubCt3MouhUAuZApOY4O3+EMWkYkSiSx7LA2p2qBVue+71T6 c2up1iEX7DqMnQHRbTN80x+07vnJg9ruu4Cxassg0B27qXmrd9zq7xC7R +yKdb2mcV3ae6dm3jO20cYUHHw10efqGHHAJ/jHbF0xrrqtu+txLmTn5k E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAP/MjlCtJXHA/2dsb2JhbABEwn+BCIIeAQEBAwEMBgEfAQUzDgUJAgsYCR4HDwIKKxEGDQEFAgEBHodeBpwPn3MEkk4DlXSOV4Frgws
X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="136572952"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2012 18:39:08 +0000
Received: from rtp-fandreas-8716.cisco.com (rtp-fandreas-8716.cisco.com [10.117.7.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9TId7DT008756;  Mon, 29 Oct 2012 18:39:08 GMT
Message-ID: <508ECD4B.60404@cisco.com>
Date: Mon, 29 Oct 2012 14:39:07 -0400
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Magnus Westerlund 
References: <20120507075517.12573.64357.idtracker@ietfa.amsl.com> <4FA78A27.4040004@ericsson.com> <507724C4.5090601@cisco.com> <50894F35.1060601@ericsson.com>
In-Reply-To: <50894F35.1060601@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "mmusic \(E-mail\)" 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rtsp-nat-12.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Oct 2012 18:39:14 -0000

On 10/25/12 10:39 AM, Magnus Westerlund wrote:
> Hi Flemming and WG,
>
> Thanks for the detailed review. As you might have seen we managed to
> update this document to address your comments.
Thanks for the update Magnus - responses below, incl. a request for more 
people to weigh in.

> Below is answers to these
> questions.
>
> On 2012-10-11 21:57, Flemming Andreasen wrote:
>> Hi Magnus
>>
>> I have taken a look at the document and, the only real technical
>> comments I have at this point are:
>>
>> - Section 6.3 (Non-Supporting Proxies), last paragraph says that:
>> 
>> This variance in results is the reason
>>     we don't recommend the usage of the Proxy-Require header. Instead we
>>     recommend the usage of the Supported header to force proxies to
>>     include the feature tags they support in the proxy-supported which
>>     will provide a positive indication when all proxies in the chain
>>     between the client and server support the functionality.  Even if not
>>     explicitly indicating support, any SETUP response including a
>>     transport specification with "D-ICE" will be implicit indication that
>>     the proxy chain supports at least passthrough of this media.
>> 
>>
>> I didn't follow the inferred logic in the last sentence (how does the
>> response convey support for the entire chain). Can you elaborate on that
>> part ?
> We have reformulated this to hopefully make it clear. But the logic is
> like this.
>
> If a client includes a transport specification with protocol D-ICE, and
> that reaches the server and that supports it and provide that transport
> spec in its answer that again reaches the client then you know that the
> D-ICE is supported. This would only occur if any proxies are either
> explicitly supporting it or are of the pass-through version.
>
> That needs to be compared with a proxy-require where the passthrough
> would be forced to negatively answer that. Also a supported header value
> will be stripped by a passthrough proxy as it is not explicitly
> supporting the functionality.
>
> That is why you have cases where trying and see if it works might be the
> best option.

The updated text makes it much clearer.

>> - Section 8 (Fallback)
>> Section title and overall description is a bit confusing (it seems to be
>> about about backwards compatibility with non-ICE supporting RTSP entities).
>> Also, the section recommends use of defunct (obsolete) behavior defined
>> in RFC 3489 to try and determine the NAT type. Why is that (shouldn't we
>> be based on RFC 5389) ?
> This fallback text is intended as a discussion of what would happen if a
> ICE enabled client would try to use its capabilities to facilitate
> NAT/FW traversal when the server is non ICE capable.
>
> The second thing to remember is that a SETUP request normally provides
> multiple transport offers, rather than doing try, error, re-try other
> alternative.
>
> Thus I at least think it is worth talking what it would mean to use STUN
> derived reflex ports as transport identifier and then be willing to send
> STUN checks towards the server. So far you actually don't need to do a
> attempt to determine the mapping behavior. If one would try it could
> reveal the failure mode earlier.
The updated text makes the brittleness issue clearer and also notes that 
RFC3489 based NAT type detection may not work, so I'm ok with that.

> But, maybe we should re-structure this section to say that like ICE the
> best fallback addresses from functionality point of view would be a
> relay address. Barring that one can attempt using a STUN derived one.
> This may however fail, and have unexpected impact on server.
>
I think it would be worthwhile including that (but would welcome other 
points of view).

Also, apart from this, I think we are ready to issue WGLC on this one.

> I do agree that we should not depend on the classification behavior of
> the old STUN spec. But, the text really is a warning that this is brittle.
The updated text makes this clearer.
>> Also, we could really use another set of eyes on it (preferably by
>> somebody that has both ICE and RTSP expertise)
> Me to.
Can we get any volunteers (or suggested names we can bug :-) ?

Thanks

-- Flemming


> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> .
>


From partha@parthasarathi.co.in  Tue Oct 30 09:05:21 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817F021F863F for ; Tue, 30 Oct 2012 09:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHWzFZGGV0UQ for ; Tue, 30 Oct 2012 09:05:20 -0700 (PDT)
Received: from outbound-us3.mailhostbox.com (ift2.mail.pw [70.87.28.154]) by ietfa.amsl.com (Postfix) with ESMTP id B8E8D21F863C for ; Tue, 30 Oct 2012 09:05:20 -0700 (PDT)
Received: from userPC (unknown [122.179.84.0]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id F3A9C868950; Tue, 30 Oct 2012 16:05:16 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1351613119; bh=yQneDEeQ9O8fa+Fn+v2BeKukHEQUkq/C3Osmf/S7Xps=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=PVgnQmntjBAfxPfYUU6A1u3ygAu8QN1Xif62q/ydUS7kqCJyMltdMhWLIUO4qYHQ0 ae+60QE5ZUeMD5Ia1Ct2Ra5851+QV1G8YGdq7RjMs47GvcPdgQ+3BX4ymiQPkZuzKm QTqeal8jtX9X5uhc9ZljmP6PhX0gCenvGVZgiIsI=
From: "Parthasarathi R" 
To: "'Paul Kyzivat'" , 
References: <507FC10D.60500@ericsson.com>			<508CFE3B.1050000@ericsson.com> <508DA17F.8000701@alum.mit.edu>
In-Reply-To: <508DA17F.8000701@alum.mit.edu>
Date: Tue, 30 Oct 2012 21:35:12 +0530
Message-ID: <005401cdb6b8$5a5dd930$0f198b90$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac21UgKmn/iBSHwJRTS1je7ZYhTvLQBZlCwg
Content-Language: en-us
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-RefID: str=0001.0A0C0201.508FFABF.00BA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Oct 2012 16:05:21 -0000

+1

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of
Paul Kyzivat
Sent: Monday, October 29, 2012 2:50 AM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] WG Poll for consensus on WG item: latching draft

I support this - I think it is desirable to have this behavior 
documented, since behavior similar to this is fairly widespread. 
Hopefully having it documented will help prevent gratuitous variation.

	Thanks,
	Paul

On 10/28/12 5:43 AM, Miguel A. Garcia wrote:
> MMUSIC followers,
>
> I would like to call for more opinions about this draft. It is hard for
> the chairs to evaluate the level of support of a draft when there is
> silence (except for Muthu).
>
> Opinions can be of the type "I support", "I believe we shouldn't work on
> this", or "I don't mind/care". All of them are very valuable to the
chairs.
>
> So, please, voice your opinion about this draft.
>
> /Miguel
>
> On 27/10/2012 23:27, Emil Ivov wrote:
>> Well I certainly haven't been around long enough to know if there are
>> people who would have supported this but might have missed the mail.
>>
>> If you guys don't either, then maybe we can go back to the original plan.
>> IIRC, back in Paris Gonzalo had agreed to AD sponsor it. Is this still an
>> option?
>>
>> --sent from my mobile
>>
>> On Oct 18, 2012 2:09 PM, "Muthu Arul Mozhi Perumal (mperumal)"
>> > wrote:
>>
>>     I support it. I think it is quite informative.
>>
>>     Muthu
>>
>>     |-----Original Message-----
>>     |From: mmusic-bounces@ietf.org 
>>     [mailto:mmusic-bounces@ietf.org ] On
>>     Behalf Of Miguel A. Garcia
>>     |Sent: Thursday, October 18, 2012 2:13 PM
>>     |To: mmusic
>>     |Cc: Flemming Andreasen (fandreas); Dan Wing (dwing)
>>     |Subject: [MMUSIC] WG Poll for consensus on WG item: latching draft
>>     |
>>     |At the last IETF meeting we had a presentation of the following
>> draft:
>>     |
>>     |http://datatracker.ietf.org/doc/draft-ivov-mmusic-latching/
>>     |
>>     |At that time, there was interest in adopting this document as WG
>>     item. We
>>     |currently have a milestone to submit an informational document
>>     describing
>>     |current practices in hosted NAT traversal, where this document fits.
>>     |
>>     |We would like to poll the working group to reconfirm the
>> consensus on
>>     |adopting the above mentioned draft as a working group item.
>>     |
>>     |If you support this work or have problems with the adoption of this
>>     |document as WG item, please indicate it by replying to this e-mail
>>     within
>>     |the next 5 days.
>>     |
>>     |     Miguel and Flemming (co-chairs)
>>     |--
>>     |Miguel A. Garcia
>>     |+34-91-339-3608 
>>     |Ericsson Spain
>>     |_______________________________________________
>>     |mmusic mailing list
>>     |mmusic@ietf.org 
>>     |https://www.ietf.org/mailman/listinfo/mmusic
>>     _______________________________________________
>>     mmusic mailing list
>>     mmusic@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


From jmpolk@cisco.com  Wed Oct 31 22:14:16 2012
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE49121F8545 for ; Wed, 31 Oct 2012 22:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGjeOYFlaeUl for ; Wed, 31 Oct 2012 22:14:16 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0C53F21F8531 for ; Wed, 31 Oct 2012 22:14:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1686; q=dns/txt; s=iport; t=1351746856; x=1352956456; h=message-id:date:to:from:subject:mime-version; bh=9Kbi39PUjqrcoSsiRtV0UqZDhJ0Uw5E/ivNIuGo09c8=; b=cf67rHkDWVA6MY2exSlGd3r5BVmoISkR2J7/PeMzRFk+3OIl+GLfpJ2c Q9enEpHM2vtG6XPslA67/0ev0F+Y64BUUY2uTt8Yszw6EOqoUV1VoK8iZ XIR9/W44Y4cMoL7j72TL8ujOcsNS5nrGsuvYhudjSLuUgergma1jeVK4K w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABsEklCtJV2d/2dsb2JhbABEw2WBCII3ASUCVjopRDWHZAuZXIEsoCGSNgOIWo43jT2Ba4MN
X-IronPort-AV: E=Sophos;i="4.80,691,1344211200"; d="scan'208";a="137613580"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2012 05:14:15 +0000
Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA15EFYn024510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Nov 2012 05:14:15 GMT
Message-Id: <201211010514.qA15EFYn024510@rcdn-core-6.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 01 Nov 2012 00:14:14 -0500
To: mmusic 
From: James Polk 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Authenticated-User: jmpolk
Subject: [MMUSIC] Update to trafficclass attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Nov 2012 05:14:17 -0000

MMUSIC

I'm letting the WG know that we've updated the trafficclass attribute 
draft to -03.

http://hive.packetizer.com/users/paulej/internet-drafts/draft-ietf-mmusic-traffic-class-for-sdp-03.txt

Here are the changes listed in Appendix 1 from the above URL

A.1  From -02 to -03

    These are the following changes made between the WG -02 version and
    the -03 version:

    - Rearranged a fair amount of text

    - Separated and defined the components into separate subsections.

    - built 5 different tables, one per category, that lists within each
      category - what applications are appropriate as well as what
      adjectives are appropriate for each application within that
      category.

Other stuff we did (not mentioned in the appendix), that we also changed:

- We also rather significantly modified the IANA considerations section.

- We worked with Paul K on the ABNF, which he likes now.

- created a "partial" admission qualifier for endpoints that send 
more traffic than had capacity admission applied to the session.

- we want to learn about any traffic flows we aren't considering that 
we should be.

- the rearranging made many little things visible that needed fixing, 
adding or deleting.

- what we have *not* addressed is Dan Wing's desire for a label to 
address his sensor traffic.  This is something that makes sense, but 
we want to hear from the WG on this. Should this attribute cover 
sporadic or occasional or busty and not fixed interval traffic such 
as sensor data?

I'll be mentioning most of this during my preso on Tuesday.

Comments and questions are appreciated.

James/Paul/Subha