From nobody Wed Oct 1 00:29:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747701A8828 for ; Wed, 1 Oct 2014 00:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54gd3bqUt-94 for ; Wed, 1 Oct 2014 00:29:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A751A1A1A71 for ; Wed, 1 Oct 2014 00:29:36 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-13-542bad5e870c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 74.58.21432.E5DAB245; Wed, 1 Oct 2014 09:29:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.233]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Wed, 1 Oct 2014 09:29:33 +0200 From: Salvatore Loreto To: Christian Groves Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3KfoBSrEsv43qEmFXeOgwZZPFJwZfrEAgAE5V4A= Date: Wed, 1 Oct 2014 07:29:32 +0000 Message-ID: <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> In-Reply-To: <542AA680.1030809@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RjdurXaIQds8cYsv7xtZLKYuf8zi wOSxZMlPJo8V52eyBDBFcdmkpOZklqUW6dslcGW8X7iQqeCSSsW0BSfZGhjfyHYxcnJICJhI HO86xAphi0lcuLeerYuRi0NI4CijxImejywQzmJGiYlbZjCBVLEJmEk8f7iFuYuRg0MEqHv+ WU2QMLOApsSTOwcYQcLCAj4ST5argYRFBHwlVvVeZYSwrSQuvF0GZrMIqEhcmPICbCKvgL3E rAu7WEBsIQFviTM3boPVcAroSGyb2c8GYjMC3fb91BomiFXiEreezGeCuFlAYsme88wQtqjE y8f/oH5Rklh0+zNUvYHE+3PzmSFsa4k5c86zQ9jaEssWvmaGuEFQ4uTMJywTGMVnIVkxC0n7 LCTts5C0z0LSvoCRdRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYLQd3PLbYAfjy+eOhxgF OBiVeHgTZmiHCLEmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG xpoPgnu/3vwcqeh0kKt3hf+VquaIA4eEAvMruB4mRGtqb59XI7WtX834Tpz/rGYxuR88lzcf n/r/WWvS63+KlaflVVv7uZ7kTS89eLRPP3WSXdQv5WWmqm8P3JHvvboq+OSu0APT48uOeqx0 6eCwXvX42+Tm/dZzl/KemrX12aWEY99TjP/tlFJiKc5INNRiLipOBADojK5HlwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_Tc-0ry74kNuMptFHBjJSasp45o Cc: "" Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 07:29:39 -0000 Hi Christian, thanks a lot for reading and reviewing the draft=20 see more in line On Sep 30, 2014, at 3:48 PM, Christian Groves wrote: > I seemed to have got cut and paste happy in 1) below. The "1*(SP sctp-fmt= )" should only apply to "DTLS/SCTP". >=20 > Christian >=20 > On 30/09/2014 10:12 PM, Christian Groves wrote: >> Hello Salvatore, >>=20 >> There seems to be several issues with the updated syntax: >>=20 >> 1) Cl.4.1 Media Description: With the updated syntax the ability to have= more than one usage of the SCTP association has been lost as "sctp-fmt" is= a single value. there have been several discussion about the ability to have more than one = usage of the SCTP association,=20 and has been agreed not to allow it. So each 'm' line describes a single SCTP association; each association has= only one single specify usage. >> Also "space" should be SP to be consistent with RFC4566. thanks, you are right. I will correct it in my private copy, so it will app= ear correct in the next version.=20 >>=20 >> To address these I suggest the following update: >> e.g. >> sctp-m-line =3D %x6d "=3D" ("application" space sctp-port space "SCTP" 1= *(SP sctp-fmt) CRLF) / ("application" space sctp-port space "SCTP/DTLS" 1*(= SP sctp-fmt) CRLF) / ("application" space udp-port space "DTLS/SCTP" 1*(SP = sctp-fmt) CRLF) sctp-port =3D port >>=20 >> sctp-fmt =3D association-usage >>=20 >> association-usage =3D token >>=20 >> 2) Cl. 4.1.1 sctp-port: The syntax for sctp-port indicates the dual use = of "=3D", i.e. >>=20 >> sctp-port-attr =3D "a=3Dsctp-port=3D" portnumber >> port-number =3D port >>=20 >> That doesn't appear to be consistent with the example in clause 4 which = has: >> a=3Dsctp-port 4060 >>=20 >> To match that the syntax needs to be updated, something like: >>=20 >> sctp-port-attr =3D "a=3Dsctp-port" SP portnumber >> port-number =3D port >> I'm not sure why "portnumber" is used when "port" is commonly used in cl= ause 4.1? >>=20 >> The syntax could be simplified to: >> sctp-port-attr =3D "a=3Dsctp-port" SP port good suggestion. I am including it in my private copy.=20 >>=20 >> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from the sy= ntax between association-usage and max-message-size. >>=20 >> sctpmap-attr =3D "a=3Dfmtp:" association-usage [max-message-size] >>=20 >> should be: >> sctpmap-attr =3D "a=3Dfmtp:" association-usage [SP max-message-size] >>=20 >> The current syntax allows an fmtp usage with no max-message-size paramet= er, e.g. "a=3Dfmtp:bfcp". Should this be allowed? this has been discussed back in April or May. It has been decided that the = max-message-size parameter is optional. In the case it is not present the default value is 64K >>=20 >> 4) Cl.4.1.2: The last sentence of the 1st paragraph and the first senten= ce of the second paragraph appears to be a repeat. got it.=20 >>=20 >> 5) Cl.4.1.2: "If the parameter is not present, the implementation should= provide a >> default, with a suggested value of 64K." Is this 64,000 or is 65,535 byt= es? >>=20 >> 6) Cl.4, 4.1 and 10 refer to the sub-field. These should be update= d to refer to the field. got it.=20 >>=20 >> 7) Cl.10: How will this registry relate to the =93WebSocket Subprotocol = Name Registry=94 (http://www.iana.org/assignments/websocket/websocket.xml#s= ubprotocol-name)? It is not related. The 'association-usage' specifies how the SCTP associati= on will be used. For example in the case of webrtc-datachannel value it would indicate how t= o pair certain streams, how to consider specific stream etc. as described in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol= -08 and in=20 http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ the WebSocket Subprotocol Name Registry is used to populate the protocol fi= eld in the protocol field in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protoc= ol-08#section-5 >>=20 >> 8) Cl.8.2: What's the significance of the the "*" in the examples in ter= ms of "association usage"? good catch I will clarify it. >>=20 >> Regards, Christian >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Oct 1 00:45:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC1B1A8828 for ; Wed, 1 Oct 2014 00:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnUbcHEZevNJ for ; Wed, 1 Oct 2014 00:45:02 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE4F1A0024 for ; Wed, 1 Oct 2014 00:45:01 -0700 (PDT) Received: from ppp118-209-40-172.lns20.mel4.internode.on.net ([118.209.40.172]:58486 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZEZR-00054r-Sz; Wed, 01 Oct 2014 17:43:34 +1000 Message-ID: <542BB0F7.3090608@nteczone.com> Date: Wed, 01 Oct 2014 17:44:55 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Salvatore Loreto References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> In-Reply-To: <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/JwgHgGmdYtZha4owLS4TB2Qor9g Cc: "" Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 07:45:05 -0000 Hello Salvatore, Thanks for the replies. Please see some comments below. Regards, Christian On 1/10/2014 5:29 PM, Salvatore Loreto wrote: > Hi Christian, > > thanks a lot for reading and reviewing the draft > see more in line > > On Sep 30, 2014, at 3:48 PM, Christian Groves wrote: > >> I seemed to have got cut and paste happy in 1) below. The "1*(SP sctp-fmt)" should only apply to "DTLS/SCTP". >> >> Christian >> >> On 30/09/2014 10:12 PM, Christian Groves wrote: >>> Hello Salvatore, >>> >>> There seems to be several issues with the updated syntax: >>> >>> 1) Cl.4.1 Media Description: With the updated syntax the ability to have more than one usage of the SCTP association has been lost as "sctp-fmt" is a single value. > > > there have been several discussion about the ability to have more than one usage of the SCTP association, > and has been agreed not to allow it. > So each 'm' line describes a single SCTP association; each association has only one single specify usage. > [CNG] So how would I specify in SDP a scenario where BFCP uses a DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they both use the same DTLS connection? Are these to be separate m-lines? > > > ..snip.. >>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from the syntax between association-usage and max-message-size. >>> >>> sctpmap-attr = "a=fmtp:" association-usage [max-message-size] >>> >>> should be: >>> sctpmap-attr = "a=fmtp:" association-usage [SP max-message-size] >>> >>> The current syntax allows an fmtp usage with no max-message-size parameter, e.g. "a=fmtp:bfcp". Should this be allowed? > > this has been discussed back in April or May. It has been decided that the max-message-size parameter is optional. > In the case it is not present the default value is 64K > [CNG] I agree that the max-message-size parameter is optional, in that case an endpoint wouldn't specify the whole a=ftmp: line. It seems strange to allow the endpoint to specify half a line? >>> 5) Cl.4.1.2: "If the parameter is not present, the implementation should provide a >>> default, with a suggested value of 64K." Is this 64,000 or is 65,535 bytes? [CNG] I think you skipped this? >>> 7) Cl.10: How will this registry relate to the “WebSocket Subprotocol Name Registry” (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)? > > It is not related. The 'association-usage' specifies how the SCTP association will be used. > For example in the case of webrtc-datachannel value it would indicate how to pair certain streams, > how to consider specific stream etc. > as described in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in > http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ > > the WebSocket Subprotocol Name Registry is used to populate the protocol field in the > protocol field in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-5 > > [CNG] So if I use the SCTP association for "bfcp" then i'd need to document this in the new registry associated with the draft? and if I then used "bfcp" for webrtc-datachannel then i'd need to update the websocket registry. Two places for the same protocol? From nobody Wed Oct 1 04:43:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAD01A0296 for ; Wed, 1 Oct 2014 04:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLkqR7GJP5nJ for ; Wed, 1 Oct 2014 04:43:08 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF121A0324 for ; Wed, 1 Oct 2014 04:43:07 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-9e-542be8c9dfef Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.38.02247.9C8EB245; Wed, 1 Oct 2014 13:43:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Wed, 1 Oct 2014 13:43:05 +0200 From: Christer Holmberg To: Christian Groves , Salvatore Loreto Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAYywg Date: Wed, 1 Oct 2014 11:43:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> In-Reply-To: <542BB0F7.3090608@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7JF9ohBv1tGhZf3jeyWExd/pjF gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4MqY0RxW8EOp4sa/2AbG/TJdjJwcEgImEic+ f2OFsMUkLtxbz9bFyMUhJHCUUeLdkuXMEM5iRom+861ADgcHm4CFRPc/bZAGEYEMidYz99hA bGYBTYkndw4wgtjCAj4Sf04+ZIeo8ZVY1XuVEcJ2k1h2/D0jyBgWARWJ2/+LQcK8QCUbXn5n gVv1/sk1FpAEp4COxKbbf8BsRqDjvp9awwSxS1zi1pP5TBBHC0gs2XOeGcIWlXj5+B8ryHwJ AUWJ5f1yEOU6Egt2f4I6U1ti2cLXzBB7BSVOznzCMoFRbBaSqbOQtMxC0jILScsCRpZVjKLF qcXFuelGRnqpRZnJxcX5eXp5qSWbGIGRc3DLb6sdjAefOx5iFOBgVOLhTZihHSLEmlhWXJl7 iFGag0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgtLUs9P+a+OSrT+3rRMtlF /s0TeW6yXGg79eCx7oQFK5bsnVzFfz1Ea7by+uIaoR/zt/6u2HdhXeLtz6qOAdy2DAUrJdTP /GRMf5q5VvYJy+HJMZsqnb83nI00LV79Y/cipeSOuoc551mVuN58jVSLDYq2e2WuwyHfPSlk l+a5lgurJ36s7DiqxFKckWioxVxUnAgAQlycG30CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/W1uQ-hb_VRvje2AHfmph0_xraEU Cc: "" Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 11:43:09 -0000 Hi, I think we need to be careful with the terminology. As far as I understand, the m- lines describes an SCTP connection - not an = SCTP association - and the sctp-fmt defines the usage of that SCTP connecti= on. Depending on the usage, there may then be multiple SCTP associations - for = example as in the case of a data-channel connection usage, where the number= of SCTP associations will depend on the number of data channels. So, if you want to use BFCP and MSRP, my understanding is that you would ne= ed two m- lines (unless, of course, you transport BFCP and MSRP within data= channels). Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves Sent: 1. lokakuuta 2014 10:45 To: Salvatore Loreto Cc: Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax questio= n Hello Salvatore, Thanks for the replies. Please see some comments below. Regards, Christian On 1/10/2014 5:29 PM, Salvatore Loreto wrote: > Hi Christian, > > thanks a lot for reading and reviewing the draft see more in line > > On Sep 30, 2014, at 3:48 PM, Christian Groves wrote: > >> I seemed to have got cut and paste happy in 1) below. The "1*(SP sctp-fm= t)" should only apply to "DTLS/SCTP". >> >> Christian >> >> On 30/09/2014 10:12 PM, Christian Groves wrote: >>> Hello Salvatore, >>> >>> There seems to be several issues with the updated syntax: >>> >>> 1) Cl.4.1 Media Description: With the updated syntax the ability to hav= e more than one usage of the SCTP association has been lost as "sctp-fmt" i= s a single value. > > > there have been several discussion about the ability to have more than=20 > one usage of the SCTP association, and has been agreed not to allow it. > So each 'm' line describes a single SCTP association; each association h= as only one single specify usage. > [CNG] So how would I specify in SDP a scenario where BFCP uses a DTLS/SCTP = association and MSRP uses a DTLS/SCTP association where they both use the s= ame DTLS connection? Are these to be separate m-lines? > > > ..snip.. >>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from the s= yntax between association-usage and max-message-size. >>> >>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [max-message-size] >>> >>> should be: >>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [SP max-message-size] >>> >>> The current syntax allows an fmtp usage with no max-message-size parame= ter, e.g. "a=3Dfmtp:bfcp". Should this be allowed? > > this has been discussed back in April or May. It has been decided that th= e max-message-size parameter is optional. > In the case it is not present the default value is 64K > [CNG] I agree that the max-message-size parameter is optional, in that=20 case an endpoint wouldn't specify the whole a=3Dftmp: line. It seems=20 strange to allow the endpoint to specify half a line? >>> 5) Cl.4.1.2: "If the parameter is not present, the implementation shoul= d provide a >>> default, with a suggested value of 64K." Is this 64,000 or is 65,535 by= tes? [CNG] I think you skipped this? >>> 7) Cl.10: How will this registry relate to the "WebSocket Subprotocol N= ame Registry" (http://www.iana.org/assignments/websocket/websocket.xml#subp= rotocol-name)? > > It is not related. The 'association-usage' specifies how the SCTP associa= tion will be used. > For example in the case of webrtc-datachannel value it would indicate how= to pair certain streams, > how to consider specific stream etc. > as described in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protoc= ol-08 and in > http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ > > the WebSocket Subprotocol Name Registry is used to populate the protocol = field in the > protocol field in https://tools.ietf.org/html/draft-ietf-rtcweb-data-prot= ocol-08#section-5 > > [CNG] So if I use the SCTP association for "bfcp" then i'd need to=20 document this in the new registry associated with the draft? and if I=20 then used "bfcp" for webrtc-datachannel then i'd need to update the=20 websocket registry. Two places for the same protocol? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Oct 1 05:42:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C667B1A0330 for ; Wed, 1 Oct 2014 05:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBgbaH-JGw8n for ; Wed, 1 Oct 2014 05:42:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E2B1A0337 for ; Wed, 1 Oct 2014 05:42:49 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 869247D4FC894; Wed, 1 Oct 2014 12:42:42 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s91Cgij6026776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 14:42:44 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 14:42:45 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , Christian Groves , Salvatore Loreto Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3KfyS5OvwiZLQEuGEinmeFzmuZwZfrEAgAE5V4CAAARPgIAAQooAgAAv9zA= Date: Wed, 1 Oct 2014 12:42:44 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FQ-qy3g_FBSg5KquHdlnP7DSTJQ Cc: "" Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 12:42:51 -0000 > I think we need to be careful with the terminology. > As far as I understand, the m- lines describes an SCTP connection - not a= n SCTP association - and the sctp-fmt defines the usage of that SCTP connec= tion. Christer,=20 there isn't any concept of an "SCTP connection" (see RFC 4960)! Rather SCTP= association, SCTP path, SCTP stream. If you are refering implicitly to the OSI concept of a (N)-connection (ITU-= T X.200), then an OSI (SCTP)-connection would be mapped to the IETF SCTP as= sociation in my understanding. Regards, Albrecht PS Perhaps you mean sth like, ".. the m- lines describes an IP transport conne= ction for SCTP, which relates to an SCTP association ..." -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Mittwoch, 1. Oktober 2014 13:43 To: Christian Groves; Salvatore Loreto Cc: Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax questio= n Hi, I think we need to be careful with the terminology. As far as I understand, the m- lines describes an SCTP connection - not an = SCTP association - and the sctp-fmt defines the usage of that SCTP connecti= on. Depending on the usage, there may then be multiple SCTP associations - for = example as in the case of a data-channel connection usage, where the number= of SCTP associations will depend on the number of data channels. So, if you want to use BFCP and MSRP, my understanding is that you would ne= ed two m- lines (unless, of course, you transport BFCP and MSRP within data= channels). Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves Sent: 1. lokakuuta 2014 10:45 To: Salvatore Loreto Cc: Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax questio= n Hello Salvatore, Thanks for the replies. Please see some comments below. Regards, Christian On 1/10/2014 5:29 PM, Salvatore Loreto wrote: > Hi Christian, > > thanks a lot for reading and reviewing the draft see more in line > > On Sep 30, 2014, at 3:48 PM, Christian Groves wrote: > >> I seemed to have got cut and paste happy in 1) below. The "1*(SP sctp-fm= t)" should only apply to "DTLS/SCTP". >> >> Christian >> >> On 30/09/2014 10:12 PM, Christian Groves wrote: >>> Hello Salvatore, >>> >>> There seems to be several issues with the updated syntax: >>> >>> 1) Cl.4.1 Media Description: With the updated syntax the ability to hav= e more than one usage of the SCTP association has been lost as "sctp-fmt" i= s a single value. > > > there have been several discussion about the ability to have more than=20 > one usage of the SCTP association, and has been agreed not to allow it. > So each 'm' line describes a single SCTP association; each association h= as only one single specify usage. > [CNG] So how would I specify in SDP a scenario where BFCP uses a DTLS/SCTP = association and MSRP uses a DTLS/SCTP association where they both use the s= ame DTLS connection? Are these to be separate m-lines? > > > ..snip.. >>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from the s= yntax between association-usage and max-message-size. >>> >>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [max-message-size] >>> >>> should be: >>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [SP max-message-size] >>> >>> The current syntax allows an fmtp usage with no max-message-size parame= ter, e.g. "a=3Dfmtp:bfcp". Should this be allowed? > > this has been discussed back in April or May. It has been decided that th= e max-message-size parameter is optional. > In the case it is not present the default value is 64K [CNG] I agree that the max-message-size parameter is optional, in that case= an endpoint wouldn't specify the whole a=3Dftmp: line. It seems strange to= allow the endpoint to specify half a line? >>> 5) Cl.4.1.2: "If the parameter is not present, the implementation=20 >>> should provide a default, with a suggested value of 64K." Is this 64,00= 0 or is 65,535 bytes? [CNG] I think you skipped this? >>> 7) Cl.10: How will this registry relate to the "WebSocket Subprotocol N= ame Registry" (http://www.iana.org/assignments/websocket/websocket.xml#subp= rotocol-name)? > > It is not related. The 'association-usage' specifies how the SCTP associa= tion will be used. > For example in the case of webrtc-datachannel value it would indicate=20 > how to pair certain streams, how to consider specific stream etc. > as described in=20 > https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in=20 > http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ > > the WebSocket Subprotocol Name Registry is used to populate the=20 > protocol field in the protocol field in=20 > https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section > -5 > > [CNG] So if I use the SCTP association for "bfcp" then i'd need to document= this in the new registry associated with the draft? and if I then used "bf= cp" for webrtc-datachannel then i'd need to update the websocket registry. = Two places for the same protocol? _______________________________________________ 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 nobody Wed Oct 1 05:46:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1931A0337 for ; Wed, 1 Oct 2014 05:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PweCX8Ip0WwJ for ; Wed, 1 Oct 2014 05:46:05 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284E41A0340 for ; Wed, 1 Oct 2014 05:46:03 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-aa-542bf78942b2 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 75.2C.21334.987FB245; Wed, 1 Oct 2014 14:46:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Wed, 1 Oct 2014 14:45:57 +0200 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" , Christian Groves , Salvatore Loreto Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAYywg///wCgCAACI0IA== Date: Wed, 1 Oct 2014 12:45:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjW7Xd+0Qg53f+S3+tP5itPjyvpHF YuryxywOzB6tz/ayeixZ8pPJY8X5mSwBzFFcNimpOZllqUX6dglcGbOX7GAr2KBfsW7yBJYG xsdqXYycHBICJhL7L15khrDFJC7cW8/WxcjFISRwlFHixO7XUM5iRom2Uy+BHA4ONgELie5/ 2iBxEYENjBLLum6wg3QzC2hKPLlzgBHEFhbwkfhz8iFYXETAV2JV71VGCDtMYsPNqWA2i4CK RMuPI0wgNi9Qzb8bJxghlu1gkrgy5Q9YglMgWuLAmfssIDYj0HnfT61hglgmLnHryXwmiLMF JJbsOQ/1gqjEy8f/WEEOlRBQlFjeLwdRriOxYPcnNghbW2LZwtfMEHsFJU7OfMIygVFsFpKp s5C0zELSMgtJywJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVF1cMtv3R2Mq187HmIU 4GBU4uFVSNAOEWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jCnbtbZ7izw8lKR3tfpBwOQEpiU3grL1k1l4p9zeM2+6z+LZf9NTJ9q15MzpVL3dsNQ8ZNKy Zb9nF4qeyCz5fmlxnRTHdN9FWhaGxjZ3BaaxT2o5Jrajamn/f9XwNv/m1wLXFookHtq57W1v n1Wb7+qsRq6DSvafplYcelKpuUrVbLaa6q1/65VYijMSDbWYi4oTAeGafyCLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TZmvMJMv29ZfaRoyq9BfZRjZFng Cc: "" Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 12:46:07 -0000 My mistake: I meant SCTP association, which then can contains multiple SCTP= streams. Sorry for the confusion. Regards, Christer -----Original Message----- From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.= com]=20 Sent: 1. lokakuuta 2014 15:43 To: Christer Holmberg; Christian Groves; Salvatore Loreto Cc: Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax questio= n > I think we need to be careful with the terminology. > As far as I understand, the m- lines describes an SCTP connection - not a= n SCTP association - and the sctp-fmt defines the usage of that SCTP connec= tion. Christer, there isn't any concept of an "SCTP connection" (see RFC 4960)! Rather SCTP= association, SCTP path, SCTP stream. If you are refering implicitly to the OSI concept of a (N)-connection (ITU-= T X.200), then an OSI (SCTP)-connection would be mapped to the IETF SCTP as= sociation in my understanding. Regards, Albrecht PS Perhaps you mean sth like, ".. the m- lines describes an IP transport conne= ction for SCTP, which relates to an SCTP association ..." -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Mittwoch, 1. Oktober 2014 13:43 To: Christian Groves; Salvatore Loreto Cc: Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax questio= n Hi, I think we need to be careful with the terminology. As far as I understand, the m- lines describes an SCTP connection - not an = SCTP association - and the sctp-fmt defines the usage of that SCTP connecti= on. Depending on the usage, there may then be multiple SCTP associations - for = example as in the case of a data-channel connection usage, where the number= of SCTP associations will depend on the number of data channels. So, if you want to use BFCP and MSRP, my understanding is that you would ne= ed two m- lines (unless, of course, you transport BFCP and MSRP within data= channels). Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves Sent: 1. lokakuuta 2014 10:45 To: Salvatore Loreto Cc: Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax questio= n Hello Salvatore, Thanks for the replies. Please see some comments below. Regards, Christian On 1/10/2014 5:29 PM, Salvatore Loreto wrote: > Hi Christian, > > thanks a lot for reading and reviewing the draft see more in line > > On Sep 30, 2014, at 3:48 PM, Christian Groves wrote: > >> I seemed to have got cut and paste happy in 1) below. The "1*(SP sctp-fm= t)" should only apply to "DTLS/SCTP". >> >> Christian >> >> On 30/09/2014 10:12 PM, Christian Groves wrote: >>> Hello Salvatore, >>> >>> There seems to be several issues with the updated syntax: >>> >>> 1) Cl.4.1 Media Description: With the updated syntax the ability to hav= e more than one usage of the SCTP association has been lost as "sctp-fmt" i= s a single value. > > > there have been several discussion about the ability to have more than=20 > one usage of the SCTP association, and has been agreed not to allow it. > So each 'm' line describes a single SCTP association; each association h= as only one single specify usage. > [CNG] So how would I specify in SDP a scenario where BFCP uses a DTLS/SCTP = association and MSRP uses a DTLS/SCTP association where they both use the s= ame DTLS connection? Are these to be separate m-lines? > > > ..snip.. >>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from the s= yntax between association-usage and max-message-size. >>> >>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [max-message-size] >>> >>> should be: >>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [SP max-message-size] >>> >>> The current syntax allows an fmtp usage with no max-message-size parame= ter, e.g. "a=3Dfmtp:bfcp". Should this be allowed? > > this has been discussed back in April or May. It has been decided that th= e max-message-size parameter is optional. > In the case it is not present the default value is 64K [CNG] I agree that the max-message-size parameter is optional, in that case= an endpoint wouldn't specify the whole a=3Dftmp: line. It seems strange to= allow the endpoint to specify half a line? >>> 5) Cl.4.1.2: "If the parameter is not present, the implementation=20 >>> should provide a default, with a suggested value of 64K." Is this 64,00= 0 or is 65,535 bytes? [CNG] I think you skipped this? >>> 7) Cl.10: How will this registry relate to the "WebSocket Subprotocol N= ame Registry" (http://www.iana.org/assignments/websocket/websocket.xml#subp= rotocol-name)? > > It is not related. The 'association-usage' specifies how the SCTP associa= tion will be used. > For example in the case of webrtc-datachannel value it would indicate=20 > how to pair certain streams, how to consider specific stream etc. > as described in > https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in=20 > http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ > > the WebSocket Subprotocol Name Registry is used to populate the=20 > protocol field in the protocol field in=20 > https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section > -5 > > [CNG] So if I use the SCTP association for "bfcp" then i'd need to document= this in the new registry associated with the draft? and if I then used "bf= cp" for webrtc-datachannel then i'd need to update the websocket registry. = Two places for the same protocol? _______________________________________________ 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 nobody Wed Oct 1 07:05:50 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003821ACDC1 for ; Wed, 1 Oct 2014 07:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hXhY30QNvd9 for ; Wed, 1 Oct 2014 07:05:44 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0C51ACDC6 for ; Wed, 1 Oct 2014 07:05:34 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-02v.sys.comcast.net with comcast id xq521o00458ss0Y01q5ahJ; Wed, 01 Oct 2014 14:05:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id xq5Z1o0053Ge9ey01q5Z2f; Wed, 01 Oct 2014 14:05:33 +0000 Message-ID: <542C0A2D.5080703@alum.mit.edu> Date: Wed, 01 Oct 2014 10:05:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> In-Reply-To: <542A9E4B.2050608@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412172334; bh=g/ItMo+0WaCQlGDihuiZ5Z4Gjf7OpAdm6l1zsuFF3v8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MwIK8UpPjsmqxmssA/0I+XA+IgkBBDWF0qVzNIPwTGj4rfXSaTr+OEVrpDOlb0YPH kQqsurqnvF1B9g5uCfZukBrVfC5S45slo8YDuZHANdA0dLTDd7dqemI+M69kMzvR6Y +kjykyS42z5pf7H9YlxUe7JmSUaWSDR9ndrVZsWARhUsUJKKoaGSqZOs1A++5xp8mP gC+t18oElIFJvkBMg5Ckk1+F4P5YTd6nPaMTnDJSXUEQRh/3CC39IvxkOocPMuM07z n6Jo1X6CtRcT7prCXd/siKaGQrZl5y4OBCUd31y42xuueCSQjByfh2oPCgodufxFEp EJeMLhCxMSddw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/03ZgGRREI1zfnHafak3ZAX5w1HE Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 14:05:46 -0000 On 9/30/14 8:12 AM, Christian Groves wrote: > 2) Cl. 4.1.1 sctp-port: The syntax for sctp-port indicates the dual use > of "=", i.e. > > sctp-port-attr = "a=sctp-port=" portnumber > port-number = port > > That doesn't appear to be consistent with the example in clause 4 which > has: > a=sctp-port 4060 > > To match that the syntax needs to be updated, something like: > > sctp-port-attr = "a=sctp-port" SP portnumber > port-number = port > I'm not sure why "portnumber" is used when "port" is commonly used in > clause 4.1? > > The syntax could be simplified to: > sctp-port-attr = "a=sctp-port" SP port The above is not a valid syntax for an SDP attribute. The value of an attribute must be separated from the name by a ":". Please take a look at draft-ietf-mmusic-rfc4566bis-12 for more on this. That includes my proposal for cleaning up how attributes are defined. I suggest using that style in this draft. In a similar vein, I suggest that when defining the new fmtp usage, just provide the new syntax for format-specific-params, not for the whole attribute. (While writing this I'm realizing that the new text defining the fmtp parameter in 4566bis should specify *how* this should be done.) Thanks, Paul From nobody Wed Oct 1 07:14:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ABC1ACDBA for ; Wed, 1 Oct 2014 07:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqPQ9HPQnJms for ; Wed, 1 Oct 2014 07:14:11 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6611ACDB8 for ; Wed, 1 Oct 2014 07:14:11 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-03v.sys.comcast.net with comcast id xqDL1o0014xDoy801qEA3r; Wed, 01 Oct 2014 14:14:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id xqEA1o0033Ge9ey01qEAyA; Wed, 01 Oct 2014 14:14:10 +0000 Message-ID: <542C0C31.70506@alum.mit.edu> Date: Wed, 01 Oct 2014 10:14:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> In-Reply-To: <542BB0F7.3090608@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412172850; bh=cIYzsfpg+QclUOq5S0qrNSHGLOv05KPF34hFcqsRdi8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rb8x0ldXSA8aN+Ox06dFFRPDv+422LjgGJWVRna3IvpSUfey6Jh2E5w5/iTzX8tId oEpU+ck5CeAAaigXbt01pZvGgeGkHptkItOr5oH14AWp1bMRi+Xy0Yv3crvCh6AeJb AIc88E/ysL8z5jcD5PrwA1Xaz+SZXJVByPZAIjyPtemxb1D5SwFIGhw2rcMS0jTJOJ rord6I5Ox+tiEoh4Be8zdRwLMTkOlZwFeDj3JtdzKf0AQA6Jf2rjxWEsIjyyJO6K1a pFvxDsFfnpw9cyTrCGPwCMQBfQN4K5hFsAzrIBPpYMNN2FCe4fmVuULvAaaO4iG3Lu g3eftnkfjMdtw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kkxunWXMOooxAkdqQ2z0j6aKJN0 Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 14:14:12 -0000 On 10/1/14 3:44 AM, Christian Groves wrote: >> >> there have been several discussion about the ability to have more than >> one usage of the SCTP association, >> and has been agreed not to allow it. >> So each 'm' line describes a single SCTP association; each >> association has only one single specify usage. >> > > [CNG] So how would I specify in SDP a scenario where BFCP uses a > DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they > both use the same DTLS connection? Are these to be separate m-lines? To have two different SCTP associations over the same DTLS connection, they would have to be distinguished by sctp-port. To achieve that you could write two m-lines. They would share the same ip address and port, and would have different "a=sctp-port" lines. Then they would have to be bundled. Doing that would require extending the definition of bundle to cover that case. (There is no *technical* problem in doing this.) OTOH, in principle they don't need their own SCTP association. AFAIK they each only use one sctp stream-pair (channel). If they could agree on how to choose channels then they could share an SCTP association. That is where draft-ejzak... comes in. Thanks, Paul From nobody Wed Oct 1 07:20:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E62F1ACDC4 for ; Wed, 1 Oct 2014 07:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrqlM7UQmksD for ; Wed, 1 Oct 2014 07:20:19 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D4D1ACDC2 for ; Wed, 1 Oct 2014 07:20:18 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-02v.sys.comcast.net with comcast id xqJP1o0035FMDhs01qLJTp; Wed, 01 Oct 2014 14:20:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id xqLH1o00c3Ge9ey01qLJso; Wed, 01 Oct 2014 14:20:18 +0000 Message-ID: <542C0DA1.4000903@alum.mit.edu> Date: Wed, 01 Oct 2014 10:20:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> In-Reply-To: <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412173218; bh=/lU4OWE+HBTC1L+sU1zj1+U5/p4jvZk5bQRAIVMokg0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PDS97d7/h2/RnFzlLznXY1tRkOw/VRfDAaxDYIqzBWHOHm3VUxvQDaYTGEe5Hmsxx JTQ8hjFS7BhOMp1qgNlGcD2SVJ61i6epP+oI4wJ3vzAllzGoUVxIS3v2abSETWnvj5 wpftY52PI+rNNta7yjrbFWerqXln/lfy0rBCBG1VlGZobaJDNmCBuwLczkDewXNFEf 8vpbGL6eeh83Wp1tpwIBgNG3Tw/jqshf5Fm+Q3hYOlGRW4+W9fZETlum5tOdrNFC6s Kr3qmtKp0V5fjmMeWajLV4d+SM6hA98pJitIfbJfxdj7vfXysdp9vtVrpYRZEhVFG4 zO67fSW1nB/0A== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZPTz6F6nhFWhB2Ojtz9Ron5fi9Q Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 14:20:20 -0000 On 10/1/14 3:29 AM, Salvatore Loreto wrote: >>> 7) Cl.10: How will this registry relate to the “WebSocket Subprotocol Name Registry” (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)? > > > It is not related. The 'association-usage' specifies how the SCTP association will be used. > For example in the case of webrtc-datachannel value it would indicate how to pair certain streams, > how to consider specific stream etc. > as described in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in > http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ > > the WebSocket Subprotocol Name Registry is used to populate the protocol field in the > protocol field in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-5 I agree. The association-usage is describing how the association as a whole, including all of the streams, is used/managed. It doesn't provide a means to separately describe how individual streams within it are to be used. If that is to be done in SDP then something like draft-ejzak... would be required. Thanks, Paul From nobody Wed Oct 1 15:40:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40D91A87CC for ; Wed, 1 Oct 2014 15:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N02EpqbMADdI for ; Wed, 1 Oct 2014 15:40:16 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401F91A87CB for ; Wed, 1 Oct 2014 15:40:16 -0700 (PDT) Received: from ppp118-209-169-149.lns20.mel8.internode.on.net ([118.209.169.149]:50512 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZSXf-0002eB-Kl for mmusic@ietf.org; Thu, 02 Oct 2014 08:38:39 +1000 Message-ID: <542C82C9.60204@nteczone.com> Date: Thu, 02 Oct 2014 08:40:09 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542C0A2D.5080703@alum.mit.edu> In-Reply-To: <542C0A2D.5080703@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nzcNPsODkjONuuM3Ln0OrmY7Cfc Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 22:40:17 -0000 Hello Paul, I agree, good idea to use the new style. Regards, Christian On 2/10/2014 12:05 AM, Paul Kyzivat wrote: > On 9/30/14 8:12 AM, Christian Groves wrote: > >> 2) Cl. 4.1.1 sctp-port: The syntax for sctp-port indicates the dual use >> of "=", i.e. >> >> sctp-port-attr = "a=sctp-port=" portnumber >> port-number = port >> >> That doesn't appear to be consistent with the example in clause 4 which >> has: >> a=sctp-port 4060 >> >> To match that the syntax needs to be updated, something like: >> >> sctp-port-attr = "a=sctp-port" SP portnumber >> port-number = port >> I'm not sure why "portnumber" is used when "port" is commonly used in >> clause 4.1? >> >> The syntax could be simplified to: >> sctp-port-attr = "a=sctp-port" SP port > > The above is not a valid syntax for an SDP attribute. The value of an > attribute must be separated from the name by a ":". > > Please take a look at draft-ietf-mmusic-rfc4566bis-12 for more on this. > > That includes my proposal for cleaning up how attributes are defined. > I suggest using that style in this draft. > > In a similar vein, I suggest that when defining the new fmtp usage, > just provide the new syntax for format-specific-params, not for the > whole attribute. > > (While writing this I'm realizing that the new text defining the fmtp > parameter in 4566bis should specify *how* this should be done.) > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Oct 1 15:46:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D651E1A8823 for ; Wed, 1 Oct 2014 15:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46LzzF3S8Xbp for ; Wed, 1 Oct 2014 15:46:48 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1991A87CC for ; Wed, 1 Oct 2014 15:46:48 -0700 (PDT) Received: from ppp118-209-169-149.lns20.mel8.internode.on.net ([118.209.169.149]:50829 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZSe0-0003Ti-1g; Thu, 02 Oct 2014 08:45:12 +1000 Message-ID: <542C8452.1030206@nteczone.com> Date: Thu, 02 Oct 2014 08:46:42 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "Schwarz, Albrecht (Albrecht)" , Salvatore Loreto References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/s85DQ_ASj0Loy723CR-xeH5FG4U Cc: "" Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 22:46:51 -0000 Hello Christer and Salvatore, I'm happy to use to m-lines. I think it would be good to have something in the draft describing the usage of multiple DTLS/SCTP m-lines (with the same port) so that its clear that's the intention. Christian On 1/10/2014 10:45 PM, Christer Holmberg wrote: > My mistake: I meant SCTP association, which then can contains multiple SCTP streams. > > Sorry for the confusion. > > Regards, > > Christer > > -----Original Message----- > From: Schwarz, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com] > Sent: 1. lokakuuta 2014 15:43 > To: Christer Holmberg; Christian Groves; Salvatore Loreto > Cc: > Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question > >> I think we need to be careful with the terminology. >> As far as I understand, the m- lines describes an SCTP connection - not an SCTP association - and the sctp-fmt defines the usage of that SCTP connection. > Christer, > there isn't any concept of an "SCTP connection" (see RFC 4960)! Rather SCTP association, SCTP path, SCTP stream. > > If you are refering implicitly to the OSI concept of a (N)-connection (ITU-T X.200), then an OSI (SCTP)-connection would be mapped to the IETF SCTP association in my understanding. > > Regards, > Albrecht > > PS > Perhaps you mean sth like, ".. the m- lines describes an IP transport connection for SCTP, which relates to an SCTP association ..." > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Mittwoch, 1. Oktober 2014 13:43 > To: Christian Groves; Salvatore Loreto > Cc: > Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question > > Hi, > > I think we need to be careful with the terminology. > > As far as I understand, the m- lines describes an SCTP connection - not an SCTP association - and the sctp-fmt defines the usage of that SCTP connection. > > Depending on the usage, there may then be multiple SCTP associations - for example as in the case of a data-channel connection usage, where the number of SCTP associations will depend on the number of data channels. > > So, if you want to use BFCP and MSRP, my understanding is that you would need two m- lines (unless, of course, you transport BFCP and MSRP within data channels). > > Regards, > > Christer > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 1. lokakuuta 2014 10:45 > To: Salvatore Loreto > Cc: > Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question > > Hello Salvatore, > > Thanks for the replies. Please see some comments below. > > Regards, Christian > > On 1/10/2014 5:29 PM, Salvatore Loreto wrote: >> Hi Christian, >> >> thanks a lot for reading and reviewing the draft see more in line >> >> On Sep 30, 2014, at 3:48 PM, Christian Groves wrote: >> >>> I seemed to have got cut and paste happy in 1) below. The "1*(SP sctp-fmt)" should only apply to "DTLS/SCTP". >>> >>> Christian >>> >>> On 30/09/2014 10:12 PM, Christian Groves wrote: >>>> Hello Salvatore, >>>> >>>> There seems to be several issues with the updated syntax: >>>> >>>> 1) Cl.4.1 Media Description: With the updated syntax the ability to have more than one usage of the SCTP association has been lost as "sctp-fmt" is a single value. >> >> there have been several discussion about the ability to have more than >> one usage of the SCTP association, and has been agreed not to allow it. >> So each 'm' line describes a single SCTP association; each association has only one single specify usage. >> > [CNG] So how would I specify in SDP a scenario where BFCP uses a DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they both use the same DTLS connection? Are these to be separate m-lines? >> >> ..snip.. >>>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from the syntax between association-usage and max-message-size. >>>> >>>> sctpmap-attr = "a=fmtp:" association-usage [max-message-size] >>>> >>>> should be: >>>> sctpmap-attr = "a=fmtp:" association-usage [SP max-message-size] >>>> >>>> The current syntax allows an fmtp usage with no max-message-size parameter, e.g. "a=fmtp:bfcp". Should this be allowed? >> >> this has been discussed back in April or May. It has been decided that the max-message-size parameter is optional. >> In the case it is not present the default value is 64K > [CNG] I agree that the max-message-size parameter is optional, in that case an endpoint wouldn't specify the whole a=ftmp: line. It seems strange to allow the endpoint to specify half a line? > >>>> 5) Cl.4.1.2: "If the parameter is not present, the implementation >>>> should provide a default, with a suggested value of 64K." Is this 64,000 or is 65,535 bytes? > [CNG] I think you skipped this? > >>>> 7) Cl.10: How will this registry relate to the "WebSocket Subprotocol Name Registry" (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)? >> >> It is not related. The 'association-usage' specifies how the SCTP association will be used. >> For example in the case of webrtc-datachannel value it would indicate >> how to pair certain streams, how to consider specific stream etc. >> as described in >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in >> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ >> >> the WebSocket Subprotocol Name Registry is used to populate the >> protocol field in the protocol field in >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section >> -5 >> >> > [CNG] So if I use the SCTP association for "bfcp" then i'd need to document this in the new registry associated with the draft? and if I then used "bfcp" for webrtc-datachannel then i'd need to update the websocket registry. Two places for the same protocol? > > > _______________________________________________ > 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 nobody Wed Oct 1 16:04:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610251A86F9 for ; Wed, 1 Oct 2014 16:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT7er0twhn8v for ; Wed, 1 Oct 2014 16:04:54 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B161F1A8821 for ; Wed, 1 Oct 2014 16:04:54 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-10v.sys.comcast.net with comcast id xz4Y1o00458ss0Y01z4ujU; Wed, 01 Oct 2014 23:04:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id xz4t1o0063Ge9ey01z4tdc; Wed, 01 Oct 2014 23:04:53 +0000 Message-ID: <542C8895.6080408@alum.mit.edu> Date: Wed, 01 Oct 2014 19:04:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> <542C8452.1030206@nteczone.com> In-Reply-To: <542C8452.1030206@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412204694; bh=uKzstSpV36FtlbtjspJful+WnicvurOsd+nWTW+k2Xw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AITaOz819PHiNtUDbyYm8dcD23bw4VdVQR1pYFNfGDGjJXO32g7we3/JzQVd36nRu +EQ0oUyvE6XzdLfMWvhvCBmokeszXDqSLICjYpwsWbmzlav2SM26HbFyvCEds29uJ3 Fog1NoYgI8iTI+pP5uELPo2T2BRc3JYTN0oJ3HQm+JfR0BAM9FgfTjPXIWbAUkL4Ze etUq7BSMtZY7aR1UTZ4IMFdmfDLKeIfW+sPXv2wpEYfDxZVA50rg/JBhs7tyxJhwCJ Rd0h/UFcdUpdvfuLKboPqxOFtdJPWR0OmHNYQWlbXesMkrF98Tvpzo07ak3XOvv+Qb 6q+W++yzngNNQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CQ6w90ji0IM0NbcovmNyJHdPxnw Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 23:04:56 -0000 On 10/1/14 6:46 PM, Christian Groves wrote: > Hello Christer and Salvatore, > > I'm happy to use to m-lines. I think it would be good to have something > in the draft describing the usage of multiple DTLS/SCTP m-lines (with > the same port) so that its clear that's the intention. The thing is - it would be bad to give an example using bundle while there is no definition of how bundle works for that. (It is not included in the bundle spec.) That would mean adding the interaction with bundle into this draft, or in a new draft. While that is possible, do we want to take that on now? This would be a good time for Christer to chime in. :-) Thanks, Paul > Christian > > On 1/10/2014 10:45 PM, Christer Holmberg wrote: >> My mistake: I meant SCTP association, which then can contains multiple >> SCTP streams. >> >> Sorry for the confusion. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Schwarz, Albrecht (Albrecht) >> [mailto:albrecht.schwarz@alcatel-lucent.com] >> Sent: 1. lokakuuta 2014 15:43 >> To: Christer Holmberg; Christian Groves; Salvatore Loreto >> Cc: >> Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax >> question >> >>> I think we need to be careful with the terminology. >>> As far as I understand, the m- lines describes an SCTP connection - >>> not an SCTP association - and the sctp-fmt defines the usage of that >>> SCTP connection. >> Christer, >> there isn't any concept of an "SCTP connection" (see RFC 4960)! Rather >> SCTP association, SCTP path, SCTP stream. >> >> If you are refering implicitly to the OSI concept of a (N)-connection >> (ITU-T X.200), then an OSI (SCTP)-connection would be mapped to the >> IETF SCTP association in my understanding. >> >> Regards, >> Albrecht >> >> PS >> Perhaps you mean sth like, ".. the m- lines describes an IP transport >> connection for SCTP, which relates to an SCTP association ..." >> >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: Mittwoch, 1. Oktober 2014 13:43 >> To: Christian Groves; Salvatore Loreto >> Cc: >> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax >> question >> >> Hi, >> >> I think we need to be careful with the terminology. >> >> As far as I understand, the m- lines describes an SCTP connection - >> not an SCTP association - and the sctp-fmt defines the usage of that >> SCTP connection. >> >> Depending on the usage, there may then be multiple SCTP associations - >> for example as in the case of a data-channel connection usage, where >> the number of SCTP associations will depend on the number of data >> channels. >> >> So, if you want to use BFCP and MSRP, my understanding is that you >> would need two m- lines (unless, of course, you transport BFCP and >> MSRP within data channels). >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian >> Groves >> Sent: 1. lokakuuta 2014 10:45 >> To: Salvatore Loreto >> Cc: >> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax >> question >> >> Hello Salvatore, >> >> Thanks for the replies. Please see some comments below. >> >> Regards, Christian >> >> On 1/10/2014 5:29 PM, Salvatore Loreto wrote: >>> Hi Christian, >>> >>> thanks a lot for reading and reviewing the draft see more in line >>> >>> On Sep 30, 2014, at 3:48 PM, Christian Groves >>> wrote: >>> >>>> I seemed to have got cut and paste happy in 1) below. The "1*(SP >>>> sctp-fmt)" should only apply to "DTLS/SCTP". >>>> >>>> Christian >>>> >>>> On 30/09/2014 10:12 PM, Christian Groves wrote: >>>>> Hello Salvatore, >>>>> >>>>> There seems to be several issues with the updated syntax: >>>>> >>>>> 1) Cl.4.1 Media Description: With the updated syntax the ability to >>>>> have more than one usage of the SCTP association has been lost as >>>>> "sctp-fmt" is a single value. >>> >>> there have been several discussion about the ability to have more than >>> one usage of the SCTP association, and has been agreed not to allow it. >>> So each 'm' line describes a single SCTP association; each >>> association has only one single specify usage. >>> >> [CNG] So how would I specify in SDP a scenario where BFCP uses a >> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they >> both use the same DTLS connection? Are these to be separate m-lines? >>> >>> ..snip.. >>>>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from >>>>> the syntax between association-usage and max-message-size. >>>>> >>>>> sctpmap-attr = "a=fmtp:" association-usage [max-message-size] >>>>> >>>>> should be: >>>>> sctpmap-attr = "a=fmtp:" association-usage [SP max-message-size] >>>>> >>>>> The current syntax allows an fmtp usage with no max-message-size >>>>> parameter, e.g. "a=fmtp:bfcp". Should this be allowed? >>> >>> this has been discussed back in April or May. It has been decided >>> that the max-message-size parameter is optional. >>> In the case it is not present the default value is 64K >> [CNG] I agree that the max-message-size parameter is optional, in that >> case an endpoint wouldn't specify the whole a=ftmp: line. It seems >> strange to allow the endpoint to specify half a line? >> >>>>> 5) Cl.4.1.2: "If the parameter is not present, the implementation >>>>> should provide a default, with a suggested value of 64K." Is this >>>>> 64,000 or is 65,535 bytes? >> [CNG] I think you skipped this? >> >>>>> 7) Cl.10: How will this registry relate to the "WebSocket >>>>> Subprotocol Name Registry" >>>>> (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)? >>>>> >>> >>> It is not related. The 'association-usage' specifies how the SCTP >>> association will be used. >>> For example in the case of webrtc-datachannel value it would indicate >>> how to pair certain streams, how to consider specific stream etc. >>> as described in >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in >>> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ >>> >>> the WebSocket Subprotocol Name Registry is used to populate the >>> protocol field in the protocol field in >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section >>> -5 >>> >>> >> [CNG] So if I use the SCTP association for "bfcp" then i'd need to >> document this in the new registry associated with the draft? and if I >> then used "bfcp" for webrtc-datachannel then i'd need to update the >> websocket registry. Two places for the same protocol? >> >> >> _______________________________________________ >> 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 nobody Wed Oct 1 16:24:54 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1191A8835 for ; Wed, 1 Oct 2014 16:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-747AeydotE for ; Wed, 1 Oct 2014 16:24:51 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511731A8830 for ; Wed, 1 Oct 2014 16:24:51 -0700 (PDT) Received: from ppp118-209-169-149.lns20.mel8.internode.on.net ([118.209.169.149]:51553 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZTEo-0000O9-LC for mmusic@ietf.org; Thu, 02 Oct 2014 09:23:14 +1000 Message-ID: <542C8D3C.7070105@nteczone.com> Date: Thu, 02 Oct 2014 09:24:44 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542C0DA1.4000903@alum.mit.edu> In-Reply-To: <542C0DA1.4000903@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/pVJqzBbf-UPEYZZSMreQIvXygyk Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 23:24:53 -0000 Hello, On 2/10/2014 12:20 AM, Paul Kyzivat wrote: > On 10/1/14 3:29 AM, Salvatore Loreto wrote: > >>>> 7) Cl.10: How will this registry relate to the “WebSocket >>>> Subprotocol Name Registry” >>>> (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)? >> >> >> It is not related. The 'association-usage' specifies how the SCTP >> association will be used. >> For example in the case of webrtc-datachannel value it would indicate >> how to pair certain streams, >> how to consider specific stream etc. >> as described in >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in >> http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ >> >> the WebSocket Subprotocol Name Registry is used to populate the >> protocol field in the >> protocol field in >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-5 > > I agree. > > The association-usage is describing how the association as a whole, > including all of the streams, is used/managed. > > It doesn't provide a means to separately describe how individual > streams within it are to be used. If that is to be done in SDP then > something like draft-ejzak... would be required. [CNG] My comments on this are in the context of the note in cl.10 of the draft: "[Note] TBD whether a new registry is necessary to register the different possible "association-usage" values." I'm just thinking of the specification effort to introduce new sub-protocols. Consider a gateway scenario where I have a DTLS/SCTP association running datachannel with bfcp and on the other side a SCTP association running BFCP. In either scenario bfcp runs in an SCTP stream. However it means to introduce BFCP (and any other protocol) we have to update two registries with essentially the same value. If we do have a new registry just for "association-usage" it would be good to have some text with regards to a template of information that someone registering the information would need to consider. i.e. what information would someone need to specify to registry BFCP as opposed to just registering BFCP as websocket sub-protocol. Regards, Christian > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Oct 1 16:57:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460E01A886E for ; Wed, 1 Oct 2014 16:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6diRNZ1SDbrN for ; Wed, 1 Oct 2014 16:57:09 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002F41A886C for ; Wed, 1 Oct 2014 16:57:08 -0700 (PDT) Received: from ppp118-209-169-149.lns20.mel8.internode.on.net ([118.209.169.149]:52174 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZTk3-0005Lo-Pe for mmusic@ietf.org; Thu, 02 Oct 2014 09:55:31 +1000 Message-ID: <542C94CE.50600@nteczone.com> Date: Thu, 02 Oct 2014 09:57:02 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <542C0C31.70506@alum.mit.edu> In-Reply-To: <542C0C31.70506@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/o6kIh5Bb5u65w-P0sg3JW3Ik-SI Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 23:57:10 -0000 What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00? It has expired and is based on the old SDP SCTP syntax. Particularly the example in cl.4: m=application 54111 DTLS/SCTP 5000 5001 5002 c=IN IP4 79.97.215.79 a=sctpmap:5000 webrtc-datachannel a=sctpmap:5001 bfcp a=sctpmap:5002 t38 Wouldn't apply if we're saying to use multiple m-lines. I guess cl.5.1.1.3 would use the same Websocket subprotocol name registry as data channel does? Regards, Christian On 2/10/2014 12:14 AM, Paul Kyzivat wrote: > On 10/1/14 3:44 AM, Christian Groves wrote: > >>> >>> there have been several discussion about the ability to have more than >>> one usage of the SCTP association, >>> and has been agreed not to allow it. >>> So each 'm' line describes a single SCTP association; each >>> association has only one single specify usage. >>> >> >> [CNG] So how would I specify in SDP a scenario where BFCP uses a >> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they >> both use the same DTLS connection? Are these to be separate m-lines? > > To have two different SCTP associations over the same DTLS connection, > they would have to be distinguished by sctp-port. To achieve that you > could write two m-lines. They would share the same ip address and > port, and would have different "a=sctp-port" lines. Then they would > have to be bundled. > > Doing that would require extending the definition of bundle to cover > that case. (There is no *technical* problem in doing this.) > > OTOH, in principle they don't need their own SCTP association. AFAIK > they each only use one sctp stream-pair (channel). If they could agree > on how to choose channels then they could share an SCTP association. > That is where draft-ejzak... comes in. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Oct 1 18:37:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AA21A8884 for ; Wed, 1 Oct 2014 18:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyb6HF25zbuX for ; Wed, 1 Oct 2014 18:37:04 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A446D1A8888 for ; Wed, 1 Oct 2014 18:36:57 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-07v.sys.comcast.net with comcast id y1cd1o00B58ss0Y011cxDc; Thu, 02 Oct 2014 01:36:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id y1cw1o00D3Ge9ey011cw0L; Thu, 02 Oct 2014 01:36:56 +0000 Message-ID: <542CAC38.5020708@alum.mit.edu> Date: Wed, 01 Oct 2014 21:36:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <542C0C31.70506@alum.mit.edu> <542C94CE.50600@nteczone.com> In-Reply-To: <542C94CE.50600@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412213817; bh=WiLEyiZ5hDo64hev30ks4yPVfdZTUZlpw9aRc5yf6nQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QHX0OKNdUmcc8IXTaRR9AtS6arMV0lXfHbwTYJbH+fnC7C0qwqH5QHZ5J4a87m3SW VKntLzzBGlSRb7ZxIJ3JQHwJcfK1sQATgY7OzQtmZGn09rAGfXcehd9a2jHg451X/t hyOgqcgJjrR4xIhBKa07MNMovHI56kDPhIjeXEWB4SSgJX8lgeVey4kiy/xLcheIsZ HYygkYmx3SixwMOthoTpLUuNcPnseotyhjYP5lDQSHkHvrkSY3Vp72HFgiX4sLA09a hMFydDpafINp+fxqR7iN86c34SNERH5OqqNdstkw84mjhdVIUtziCBu48FJgFHihxv oiUeiFU0iIdYA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uACl6Fs-4q-95TFYtJL2ldPqobU Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 01:37:06 -0000 On 10/1/14 7:57 PM, Christian Groves wrote: > What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00? I don't know the status. The thought Keith Drage had indicated that he was picking up responsibility for it. Thanks, Paul > It has expired and is based on the old SDP SCTP syntax. Particularly the > example in cl.4: > > m=application 54111 DTLS/SCTP 5000 5001 5002 > c=IN IP4 79.97.215.79 > a=sctpmap:5000 webrtc-datachannel > a=sctpmap:5001 bfcp > a=sctpmap:5002 t38 > > Wouldn't apply if we're saying to use multiple m-lines. > > I guess cl.5.1.1.3 would use the same Websocket subprotocol name > registry as data channel does? > > Regards, Christian > > On 2/10/2014 12:14 AM, Paul Kyzivat wrote: >> On 10/1/14 3:44 AM, Christian Groves wrote: >> >>>> >>>> there have been several discussion about the ability to have more than >>>> one usage of the SCTP association, >>>> and has been agreed not to allow it. >>>> So each 'm' line describes a single SCTP association; each >>>> association has only one single specify usage. >>>> >>> >>> [CNG] So how would I specify in SDP a scenario where BFCP uses a >>> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they >>> both use the same DTLS connection? Are these to be separate m-lines? >> >> To have two different SCTP associations over the same DTLS connection, >> they would have to be distinguished by sctp-port. To achieve that you >> could write two m-lines. They would share the same ip address and >> port, and would have different "a=sctp-port" lines. Then they would >> have to be bundled. >> >> Doing that would require extending the definition of bundle to cover >> that case. (There is no *technical* problem in doing this.) >> >> OTOH, in principle they don't need their own SCTP association. AFAIK >> they each only use one sctp stream-pair (channel). If they could agree >> on how to choose channels then they could share an SCTP association. >> That is where draft-ejzak... comes in. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 nobody Wed Oct 1 18:49:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9501A888A for ; Wed, 1 Oct 2014 18:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlbYjLpvBeYg for ; Wed, 1 Oct 2014 18:49:08 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137F11A888C for ; Wed, 1 Oct 2014 18:49:07 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-12v.sys.comcast.net with comcast id y1ou1o0035FMDhs011p7iu; Thu, 02 Oct 2014 01:49:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id y1p61o00M3Ge9ey011p6az; Thu, 02 Oct 2014 01:49:07 +0000 Message-ID: <542CAF12.1070600@alum.mit.edu> Date: Wed, 01 Oct 2014 21:49:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542C0DA1.4000903@alum.mit.edu> <542C8D3C.7070105@nteczone.com> In-Reply-To: <542C8D3C.7070105@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412214547; bh=iBMowgfZV1M2CbaMvyMojtyNY7tNdGie/r9k7VbnRtw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HGYwFeqWxIRovuc/9ooT0DdJKPh+S6rk+y3QwbK9VkATBsWq3fZ3LIq5FtPQST0Sa W7GVCyfUWFZS+aXTuIfdd3lxyB3Zt5YZR3K9BxCnepH3AvkVzwQR+PNa6DS35WTKAF xYyhkTSwG96SQp6k3GxUp6PreUKA+ZCH0xcg2jtj7h4BH5jHUjI8xUNYEU42npT+JH +jbzzX9lEufrG0b4QZHde/0ls3bqREr7EvaPJHFkivz4hZ0w/eSpG00TJ7vLzrKYLa W5YE0AVYrmdtfKj/jNQ/GKFuADCC5SI4E7pn8lIPQC0Zt9y49h0fJKHZBstpP2uhc6 EsgGTmQAOOSEA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Tfkybk68C_9WjKDhY2ZY8kc-I34 Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 01:49:09 -0000 On 10/1/14 7:24 PM, Christian Groves wrote: >> The association-usage is describing how the association as a whole, >> including all of the streams, is used/managed. >> >> It doesn't provide a means to separately describe how individual >> streams within it are to be used. If that is to be done in SDP then >> something like draft-ejzak... would be required. > > [CNG] My comments on this are in the context of the note in cl.10 of the > draft: "[Note] TBD whether a new registry is necessary to register the > different possible "association-usage" values." Well, the alternatives to establishing a new registry are: - use an existing registry - define all the values directly in the draft. (This will then require a revision to define new ones.) I don't see how we could use an existing one, since the semantics of what are being defined are entirely new. (The websocket protocol registry isn't right for this. It defines a *protocols* that run over a websocket, or at least something similar in nature to a websocket. What we are defining here isn't a protocol in the same sense - it is a *convention* for how to use an SCTP association including the many streams it contains. Each of those streams may have its own protocol.) We could live without any registry *if* we think there is very low likelihood of needing to define new values. But I think it is already clear that is a bad assumption. > I'm just thinking of the specification effort to introduce new > sub-protocols. Consider a gateway scenario where I have a DTLS/SCTP > association running datachannel with bfcp and on the other side a SCTP > association running BFCP. In either scenario bfcp runs in an SCTP > stream. However it means to introduce BFCP (and any other protocol) we > have to update two registries with essentially the same value. > > If we do have a new registry just for "association-usage" it would be > good to have some text with regards to a template of information that > someone registering the information would need to consider. i.e. what > information would someone need to specify to registry BFCP as opposed to > just registering BFCP as websocket sub-protocol. One approach would be to define one new association-usage (beyond the one for rtcweb), that says the usages of the individual streams will be negotiated with SDP, using something like draft-ejzak. Then go ahead and finish that draft. Thanks, Paul From nobody Thu Oct 2 02:39:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0AB1A0255 for ; Thu, 2 Oct 2014 02:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE3dJImUB5AH for ; Thu, 2 Oct 2014 02:39:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0541A01A5 for ; Thu, 2 Oct 2014 02:39:23 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-ef-542d1d491132 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.E0.21432.94D1D245; Thu, 2 Oct 2014 11:39:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 11:39:21 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAYywg///wCgCAACI0IIAAhosAgAAFFYCAANFFoA== Date: Thu, 2 Oct 2014 09:39:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4634D8@ESESSMB209.ericsson.se> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> <542C8452.1030206@nteczone.com> <542C8895.6080408@alum.mit.edu> In-Reply-To: <542C8895.6080408@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja6nrG6IwZ8vehZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx+Ns8loLl9hUH3gY0ML4x7mLk4JAQMJFo /MfWxcgJZIpJXLi3Hsjm4hASOMoocezRZ1YIZzGjxKbuy8wgDWwCFhLd/7RBGkQEfCWePb4N 1iws4CPx5+RDdpj4qt6rjBB2lsS7WRNZQWwWARWJX9PesIDYvEA1s9ctYISYv49Z4vzRDWBF nAI6Ep/aW8CKGIEu+n5qDROIzSwgLnHryXwmiEsFJJbsOc8MYYtKvHz8jxXCVpL4seESC0S9 jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnp pRZlJhcX5+fp5aWWbGIERsnBLb8NdjC+fO54iFGAg1GJh3fBRp0QIdbEsuLK3EOM0hwsSuK8 C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuP5q7bRL879Evo96weBwf83smovzT0xz naUhxOhrvHzZtm/FL2fW/lzX1H2ke4ELp22NsDOnYQpDUPi+uMqZFclG8x/vOfCDSfZaWFDE dO6tNwOOupgt3eD0YO2yHzwfrrM3LLCQytFz2dPKde3km6czHQuPPLffEnX4Qfex6BbXJdtV JjJmzlNiKc5INNRiLipOBABIK9IjcwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-P49EAhSXz4VmNFsS4Qc8ziN3wY Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 09:39:26 -0000 Hi, >> I'm happy to use to m-lines. I think it would be good to have=20 >> something in the draft describing the usage of multiple DTLS/SCTP=20 >> m-lines (with the same port) so that its clear that's the intention. > > The thing is - it would be bad to give an example using bundle while ther= e is no definition of how bundle works for that. (It is not included in the= bundle spec.) > > That would mean adding the interaction with bundle into this draft, or in= a new draft. While that is possible, do we want to take that on now? > > This would be a good time for Christer to chime in. :-) As Paul said, BUNDLE does not specify the usage of multiple DTLS m- lines w= ithin a BUNDLE group, and explicitly says that such usage would have to be = defined in another specification. Personally, I'd be quite surprised if people started to transport BFCP, MSR= P etc over DTLS/SCTP. People haven't used SCTP for that in the past, so why= would they suddenly start now? I think DTLS/SCTP is going to be used mainly for data channel usage, and on= e can then define data channels to transport whatever (including BFCP and M= SRP). Regards, Christer > On 1/10/2014 10:45 PM, Christer Holmberg wrote: >> My mistake: I meant SCTP association, which then can contains=20 >> multiple SCTP streams. >> >> Sorry for the confusion. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Schwarz, Albrecht (Albrecht) >> [mailto:albrecht.schwarz@alcatel-lucent.com] >> Sent: 1. lokakuuta 2014 15:43 >> To: Christer Holmberg; Christian Groves; Salvatore Loreto >> Cc: >> Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax=20 >> question >> >>> I think we need to be careful with the terminology. >>> As far as I understand, the m- lines describes an SCTP connection -=20 >>> not an SCTP association - and the sctp-fmt defines the usage of that=20 >>> SCTP connection. >> Christer, >> there isn't any concept of an "SCTP connection" (see RFC 4960)!=20 >> Rather SCTP association, SCTP path, SCTP stream. >> >> If you are refering implicitly to the OSI concept of a (N)-connection=20 >> (ITU-T X.200), then an OSI (SCTP)-connection would be mapped to the=20 >> IETF SCTP association in my understanding. >> >> Regards, >> Albrecht >> >> PS >> Perhaps you mean sth like, ".. the m- lines describes an IP transport=20 >> connection for SCTP, which relates to an SCTP association ..." >> >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer=20 >> Holmberg >> Sent: Mittwoch, 1. Oktober 2014 13:43 >> To: Christian Groves; Salvatore Loreto >> Cc: >> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax=20 >> question >> >> Hi, >> >> I think we need to be careful with the terminology. >> >> As far as I understand, the m- lines describes an SCTP connection -=20 >> not an SCTP association - and the sctp-fmt defines the usage of that=20 >> SCTP connection. >> >> Depending on the usage, there may then be multiple SCTP associations=20 >> - for example as in the case of a data-channel connection usage,=20 >> where the number of SCTP associations will depend on the number of=20 >> data channels. >> >> So, if you want to use BFCP and MSRP, my understanding is that you=20 >> would need two m- lines (unless, of course, you transport BFCP and=20 >> MSRP within data channels). >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian=20 >> Groves >> Sent: 1. lokakuuta 2014 10:45 >> To: Salvatore Loreto >> Cc: >> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax=20 >> question >> >> Hello Salvatore, >> >> Thanks for the replies. Please see some comments below. >> >> Regards, Christian >> >> On 1/10/2014 5:29 PM, Salvatore Loreto wrote: >>> Hi Christian, >>> >>> thanks a lot for reading and reviewing the draft see more in line >>> >>> On Sep 30, 2014, at 3:48 PM, Christian Groves=20 >>> wrote: >>> >>>> I seemed to have got cut and paste happy in 1) below. The "1*(SP=20 >>>> sctp-fmt)" should only apply to "DTLS/SCTP". >>>> >>>> Christian >>>> >>>> On 30/09/2014 10:12 PM, Christian Groves wrote: >>>>> Hello Salvatore, >>>>> >>>>> There seems to be several issues with the updated syntax: >>>>> >>>>> 1) Cl.4.1 Media Description: With the updated syntax the ability=20 >>>>> to have more than one usage of the SCTP association has been lost=20 >>>>> as "sctp-fmt" is a single value. >>> >>> there have been several discussion about the ability to have more=20 >>> than one usage of the SCTP association, and has been agreed not to allo= w it. >>> So each 'm' line describes a single SCTP association; each=20 >>> association has only one single specify usage. >>> >> [CNG] So how would I specify in SDP a scenario where BFCP uses a=20 >> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where=20 >> they both use the same DTLS connection? Are these to be separate m-lines= ? >>> >>> ..snip.. >>>>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from=20 >>>>> the syntax between association-usage and max-message-size. >>>>> >>>>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [max-message-size] >>>>> >>>>> should be: >>>>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [SP max-message-size] >>>>> >>>>> The current syntax allows an fmtp usage with no max-message-size=20 >>>>> parameter, e.g. "a=3Dfmtp:bfcp". Should this be allowed? >>> >>> this has been discussed back in April or May. It has been decided=20 >>> that the max-message-size parameter is optional. >>> In the case it is not present the default value is 64K >> [CNG] I agree that the max-message-size parameter is optional, in=20 >> that case an endpoint wouldn't specify the whole a=3Dftmp: line. It=20 >> seems strange to allow the endpoint to specify half a line? >> >>>>> 5) Cl.4.1.2: "If the parameter is not present, the implementation=20 >>>>> should provide a default, with a suggested value of 64K." Is this >>>>> 64,000 or is 65,535 bytes? >> [CNG] I think you skipped this? >> >>>>> 7) Cl.10: How will this registry relate to the "WebSocket=20 >>>>> Subprotocol Name Registry" >>>>> (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-= name)? >>>>> >>> >>> It is not related. The 'association-usage' specifies how the SCTP=20 >>> association will be used. >>> For example in the case of webrtc-datachannel value it would=20 >>> indicate how to pair certain streams, how to consider specific stream e= tc. >>> as described in >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and=20 >>> in http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ >>> >>> the WebSocket Subprotocol Name Registry is used to populate the=20 >>> protocol field in the protocol field in=20 >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#secti >>> on >>> -5 >>> >>> >> [CNG] So if I use the SCTP association for "bfcp" then i'd need to=20 >> document this in the new registry associated with the draft? and if I=20 >> then used "bfcp" for webrtc-datachannel then i'd need to update the=20 >> websocket registry. Two places for the same protocol? >> >> >> _______________________________________________ >> 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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Oct 2 05:00:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30151A1ABA for ; Thu, 2 Oct 2014 05:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phVEjcw4U4SS for ; Thu, 2 Oct 2014 04:59:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3171A031C for ; Thu, 2 Oct 2014 04:59:54 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-a1-542d3e387a98 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.F2.21432.83E3D245; Thu, 2 Oct 2014 13:59:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 13:59:52 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAbMGAgACi2wCAABvpAIAAzvdA Date: Thu, 2 Oct 2014 11:59:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4637E9@ESESSMB209.ericsson.se> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <542C0C31.70506@alum.mit.edu> <542C94CE.50600@nteczone.com> <542CAC38.5020708@alum.mit.edu> In-Reply-To: <542CAC38.5020708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja6lnW6IwfyXfBZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx8MtL9oLXEhWTNnI1ME4Q6WLk4JAQMJG4 /kOui5ETyBSTuHBvPVsXIxeHkMBRRom3PXPZIZzFjBLNey4wgjSwCVhIdP/TBmkQEfCVePb4 NhuILSzgI/Hn5EN2mPiq3qtg5SICURJPbtuChFkEVCRWnL/BAmLzApVMW9/KDDG+kUniw6mT rCD1nAI6EhteRIDUMALd8/3UGiYQm1lAXOLWk/lMEHcKSCzZc54ZwhaVePn4HyvEK0oS07am QZTrSCzY/YkNwtaWWLbwNTPEWkGJkzOfsExgFJ2FZOosJC2zkLTMQtKygJFlFaNocWpxUm66 kZFealFmcnFxfp5eXmrJJkZgfBzc8ttgB+PL546HGAU4GJV4eBds1AkRYk0sK67MPcQozcGi JM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MXdez+a+6G3ndW2bH0n596iWbnRf2 1pmsey2+MPjO2fs+bSrnTznlRbjFySaYh2g23auMNKprf//qtPBtw8XFQW8yE6b36fJHLdp2 +l13RI3k8WonAQWxkJPlH+Wes/FIZybZW2oKqfMtmiq6tX+rwnbDDX+e33x9gvX0Wb+CbL3V lc6qa/uUWIozEg21mIuKEwEW7iltcAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/O8589YmAVhNDwqPnUWTDpdXSI6k Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 12:00:03 -0000 Hi, Keep in mind that the purpose of draft-ejzak-mmusic-data-channel-sdpneg is = NOT to negotiate the usage of the SCTP association. It is assumed that the usage of the SCTP association is data channel, and t= he draft defines a mechanism to negotiate data channels on that SCTP associ= ation. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 2. lokakuuta 2014 4:37 To: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax questio= n On 10/1/14 7:57 PM, Christian Groves wrote: > What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00? I don't know the status. The thought Keith Drage had indicated that he was = picking up responsibility for it. Thanks, Paul > It has expired and is based on the old SDP SCTP syntax. Particularly=20 > the example in cl.4: > > m=3Dapplication 54111 DTLS/SCTP 5000 5001 5002 > c=3DIN IP4 79.97.215.79 > a=3Dsctpmap:5000 webrtc-datachannel > a=3Dsctpmap:5001 bfcp > a=3Dsctpmap:5002 t38 > > Wouldn't apply if we're saying to use multiple m-lines. > > I guess cl.5.1.1.3 would use the same Websocket subprotocol name=20 > registry as data channel does? > > Regards, Christian > > On 2/10/2014 12:14 AM, Paul Kyzivat wrote: >> On 10/1/14 3:44 AM, Christian Groves wrote: >> >>>> >>>> there have been several discussion about the ability to have more=20 >>>> than one usage of the SCTP association, and has been agreed not to=20 >>>> allow it. >>>> So each 'm' line describes a single SCTP association; each=20 >>>> association has only one single specify usage. >>>> >>> >>> [CNG] So how would I specify in SDP a scenario where BFCP uses a=20 >>> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where=20 >>> they both use the same DTLS connection? Are these to be separate m-line= s? >> >> To have two different SCTP associations over the same DTLS=20 >> connection, they would have to be distinguished by sctp-port. To=20 >> achieve that you could write two m-lines. They would share the same=20 >> ip address and port, and would have different "a=3Dsctp-port" lines.=20 >> Then they would have to be bundled. >> >> Doing that would require extending the definition of bundle to cover=20 >> that case. (There is no *technical* problem in doing this.) >> >> OTOH, in principle they don't need their own SCTP association. AFAIK=20 >> they each only use one sctp stream-pair (channel). If they could=20 >> agree on how to choose channels then they could share an SCTP associatio= n. >> That is where draft-ejzak... comes in. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 nobody Thu Oct 2 05:16:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474D91A6F90 for ; Thu, 2 Oct 2014 05:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55CLtSQJyfsP for ; Thu, 2 Oct 2014 05:16:32 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099E91A6EF1 for ; Thu, 2 Oct 2014 05:16:31 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-01-542d421d69e6 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.CB.02247.D124D245; Thu, 2 Oct 2014 14:16:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 14:16:29 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAHLDgIAAmB4AgAAoVgCAAM64IA== Date: Thu, 2 Oct 2014 12:16:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D463866@ESESSMB209.ericsson.se> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542C0DA1.4000903@alum.mit.edu> <542C8D3C.7070105@nteczone.com> <542CAF12.1070600@alum.mit.edu> In-Reply-To: <542CAF12.1070600@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja6ck26Iwb9njBZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRft2kYBd/xebzn9kbGOfwdDFyckgImEgs OtXHCGGLSVy4t56ti5GLQ0jgKKPEuYezGSGcxYwSrxtnsXQxcnCwCVhIdP/TBmkQEfCVePb4 NhuILSzgI/Hn5EN2mPiq3quMEHaYxNb/58FsFgEViYdnVzKD2LxANZ1zpzNDzH/KKLHy6lp2 kPmcAjoSK04og9QwAh30/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK0irhICSxLSt aRDlOhILdn9ig7C1JZYtfA21VlDi5MwnLBMYRWchmToLScssJC2zkLQsYGRZxShanFpcnJtu ZKSXWpSZXFycn6eXl1qyiREYIwe3/LbawXjwueMhRgEORiUe3gUbdUKEWBPLiitzDzFKc7Ao ifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjzvkJG9r1lO94nfCbsuLup+CKLUw5 +S/jVxRvfBhUGvGR/4we57LLE5eXSBgdeiJ//cJP9SUduwpn/mraeK/Kqe66v7p0y8HKO6zb lsnkRiy7I6y0nOeGLzNTh00+V62n3PMHwh6dTnXCD647vLYWEk3JC7vbsvqeB6v+Psudj/r/ 3nzpuGyZEktxRqKhFnNRcSIAq8nLInICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lw5oyFY5E83AfMn-bL7j9A1q0t8 Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 12:16:42 -0000 Hi, >>> The association-usage is describing how the association as a whole,=20 >>> including all of the streams, is used/managed. >>> >>> It doesn't provide a means to separately describe how individual=20 >>> streams within it are to be used. If that is to be done in SDP then=20 >>>> something like draft-ejzak... would be required. >> >> [CNG] My comments on this are in the context of the note in cl.10 of=20 >> the >> draft: "[Note] TBD whether a new registry is necessary to register the=20 >> different possible "association-usage" values." > > Well, the alternatives to establishing a new registry are: > > - use an existing registry > >- define all the values directly in the draft. > (This will then require a revision to define new ones.) I think we should have a registry (I don't care whether it's new, or an exi= sting one). > I don't see how we could use an existing one, since the semantics of what= are being defined are entirely=20 > new. (The websocket protocol registry isn't right for this. It defines a = *protocols* that run over a websocket, or=20 > at least something similar in nature to a websocket. What we are defining= here isn't a protocol in the same sense - it is a > *convention* for how to use an SCTP association including the many stream= s it contains. Each of those streams may have its=20 > own protocol.) I agree with that. Then, IF someone e.g. would like to run RTP over SCTP, I guess they would n= eed a new m=3D line protocol value. " DTLS/SCTP/RTP/AVP", or something like= that... > We could live without any registry *if* we think there is very low likeli= hood of needing to define new values. But I think it is already clear that = is a bad assumption. Let's also keep in mind that, while we have been discussing mostly "DTLS/SC= TP", the draft also defines "SCTP" and "SCTP/DTLS". Hopefully we could use = a single registry for all of them... Regards, Christer From nobody Thu Oct 2 05:58:14 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B770F1A7000 for ; Thu, 2 Oct 2014 05:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvyeSl37pxRg for ; Thu, 2 Oct 2014 05:58:08 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2784D1A6FA8 for ; Thu, 2 Oct 2014 05:58:07 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-f5-542d4bdef91a Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.1B.21432.EDB4D245; Thu, 2 Oct 2014 14:58:06 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.233]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 14:58:06 +0200 From: Salvatore Loreto To: " list" Thread-Topic: draft-ietf-mmusic-sctp-sdp-07 Identifiers Thread-Index: AQHPySUltd+wL440/E6WSl3LfehCdA== Date: Thu, 2 Oct 2014 12:58:05 +0000 Message-ID: <07B55D81-EF18-43BD-A0F6-B60CF57EAD90@ericsson.com> References: <29120576-86D3-411E-B24F-5C9208FF43BA@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A3ABB35C5E6C54B94E397756F929902@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje49b90QgzV/5SymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDmnelgKbjFVNB/5ztrA2MfUxcjJISFgIvF3/TcWCFtM4sK9 9WxdjFwcQgJHGSXebr8F5SxmlFj6bAcbSBWbgJnE84dbmLsYOThEBPQkVhy0AgkLCxhLNB59 AFYiImAhseX3LSYIW09iyZRLYHEWARWJrmsQcV4Be4lX63+ALRYCsv+sfs4IYjMCHfH91Bqw GmYBcYlbT+ZDHSogsWTPeWYIW1Ti5eN/rBC2ksTaw9tZIOp1JBbs/sQGYVtL3Grog5qjLbFs 4WtmiL2CEidnPmGZwCg6C8mKWUjaZyFpn4WkfRaS9gWMrKsYRYtTi5Ny042M9FKLMpOLi/Pz 9PJSSzYxAmPl4JbfBjsYXz53PMQowMGoxMO7YKNOiBBrYllxZe4hRmkOFiVx3oXn5gULCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYFSct6Kx6+qKnWuvBYcZfgj5qfzmWiS3Yqfq954J6d4x hqHbjFXMbwp/nRP6IFNRyODMyR88F5q7Tr5Z8oD/nkzG/O0nt7JM+u8+h79y/7JW5ZU7b1zr 4tsVd9m8aSenINduztmCd1+zLFo62XVRw5Hgo2veW9o3nXv+QOy5R2vgzOy719xWXnmrxFKc kWioxVxUnAgAhrDUIXYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/r-agsn6iNV2MG3S00crzN8zLA1w Subject: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 12:58:09 -0000 Hi there, the JSEP editors are suggesting that the code point for SCTP over DTLS shou= ld=20 probably split in two: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". that is to define to different identifiers to be able to distinguish when D= TLS run over TCP or over UDP I am planning to make the changes in the next version. br Salvatore= From nobody Thu Oct 2 07:06:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168C51A03A0 for ; Thu, 2 Oct 2014 07:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL0pl_Pir3SN for ; Thu, 2 Oct 2014 07:05:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783301A038C for ; Thu, 2 Oct 2014 07:05:51 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-aa-542d5bbd3553 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.95.21334.DBB5D245; Thu, 2 Oct 2014 16:05:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 16:05:49 +0200 From: Christer Holmberg To: Salvatore Loreto , " list" Thread-Topic: draft-ietf-mmusic-sctp-sdp-07 Identifiers Thread-Index: AQHPySUltd+wL440/E6WSl3LfehCdJwc/17g Date: Thu, 2 Oct 2014 14:05:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D463AFE@ESESSMB209.ericsson.se> References: <29120576-86D3-411E-B24F-5C9208FF43BA@ericsson.com> <07B55D81-EF18-43BD-A0F6-B60CF57EAD90@ericsson.com> In-Reply-To: <07B55D81-EF18-43BD-A0F6-B60CF57EAD90@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje7eaN0Qg8n9OhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRv+5FawFjRwVr9esY2lgPMrWxcjJISFgIvF6SysLhC0mceHe eqA4F4eQwFFGidOrHzFBOIsZJR7//s7axcjBwSZgIdH9TxukQUQgSeLGvNVMILawgLnE9X0b WCDiFhJbft9igrCNJKbcOwIWZxFQkXh6aQdYnFfAV+L9vYNgcSGBUomOG7fBDuIUcJC42nWB FcRmBDro+6k1YPXMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx//ATpMQUJKYtjUNolxHYsHuT2wQ trbEsoWvmSHWCkqcnPmEZQKj6CwkU2chaZmFpGUWkpYFjCyrGEWLU4uLc9ONjPVSizKTi4vz 8/TyUks2MQIj4uCW37o7GFe/djzEKMDBqMTDu2CjTogQa2JZcWXuIUZpDhYlcd5F5+YFCwmk J5akZqemFqQWxReV5qQWH2Jk4uCUamA0fd5ypuC4VpHDLT4hht0C334w5u/PLWAWnvP1upQl 94rZC7M8Jvl7T3ePbNrKw8e8q+ac+YbeQnO+3sIq79v6yVVnj/vdPHfuwvH98qpmts1FN+/p lLQs417wVCT81oGc5UF12mb/m4PNPdQE7Z3lJL+l/n0kutandpMeh7louUzw0dSWeCWW4oxE Qy3mouJEAJpxD5BpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GrKlabIevJEeSfEoqyEXbnlUkQQ Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 14:05:56 -0000 Hi, I am ok with the split as such, but where is DTLS over TCP defined? In addition, draft-ietf-tsvwg-sctp-dtls-encaps, which defines SCTP over DT= LS, says that the DTLS part "MUST be based on DTLS 1.0". Not really sure wh= at is meant by "based on", but does that cover DTLS over TCP? Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Salvatore Loreto Sent: 2. lokakuuta 2014 15:58 To: list Subject: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 Identifiers Hi there, the JSEP editors are suggesting that the code point for SCTP over DTLS shou= ld probably split in two: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". that is to define to different identifiers to be able to distinguish when D= TLS run over TCP or over UDP I am planning to make the changes in the next version. br Salvatore _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Oct 2 09:08:12 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8F01A8766 for ; Thu, 2 Oct 2014 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV8o0ITi5QK1 for ; Thu, 2 Oct 2014 09:08:05 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEF41A874C for ; Thu, 2 Oct 2014 09:07:57 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id gq15so2746754lab.12 for ; Thu, 02 Oct 2014 09:07:56 -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=NYnFlGt8EDKuJIPv51ZFYfya0jgc2FRy5AuJvzXxCRo=; b=e7wKQ/I9rcugacY2HEJcvTUTAxSye28LQGuI+ORYxUYVsyHwAk74T0w1nxxQSXRIex chQmCUhyyqgQY2bH8HALEHVSJbFccI8+ZSRlibx3BE0G61qgLjGgJ2ADvi1JbB4kDvTn v4wCvMfu3ZjMZswCy9leqyiOdCbLf/M1ujZ6B6uQamFti6rfx+jAlSKFxcuF3rJ1UxGl jXrvKuipDunZR07CczpDzkZcV+y5oFelOLOlRogbgD5hcTCAC+FDjaeUzBWTwhCjsnI3 vvGkYlT2C03QPIKCNNho5xHNJaiYiiMlLKtHM8C+rOyq0EUVKJ8wHjPkyvmqOqeliweT 7cHw== MIME-Version: 1.0 X-Received: by 10.112.34.78 with SMTP id x14mr46070155lbi.38.1412266076117; Thu, 02 Oct 2014 09:07:56 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 2 Oct 2014 09:07:56 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D463AFE@ESESSMB209.ericsson.se> References: <29120576-86D3-411E-B24F-5C9208FF43BA@ericsson.com> <07B55D81-EF18-43BD-A0F6-B60CF57EAD90@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D463AFE@ESESSMB209.ericsson.se> Date: Thu, 2 Oct 2014 09:07:56 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vKekRHIgNtlm_P2gCBs92xjqor8 Cc: " list" Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 16:08:07 -0000 On 2 October 2014 07:05, Christer Holmberg wrote: > In addition, draft-ietf-tsvwg-sctp-dtls-encaps, which defines SCTP over DTLS, says that the DTLS part "MUST be based on DTLS 1.0". Not really sure what is meant by "based on", but does that cover DTLS over TCP? I hope that DTLS 1.2 is OK. We're shipping that. From nobody Thu Oct 2 09:25:45 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209661A879D for ; Thu, 2 Oct 2014 09:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr8yrn4_XB_T for ; Thu, 2 Oct 2014 09:25:39 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2B31A878F for ; Thu, 2 Oct 2014 09:25:39 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-f4-542d7c80d8e9 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F9.39.21334.08C7D245; Thu, 2 Oct 2014 18:25:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 18:25:35 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 Identifiers Thread-Index: AQHP3lsHsj4GpOIlpkiNQd/X8tDGWpwc/Lzw Date: Thu, 2 Oct 2014 16:25:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D464334@ESESSMB209.ericsson.se> References: <29120576-86D3-411E-B24F-5C9208FF43BA@ericsson.com> <07B55D81-EF18-43BD-A0F6-B60CF57EAD90@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D463AFE@ESESSMB209.ericsson.se> 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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW5DjW6IwcQD6hbXzvxjtJi6/DGL A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXxYNknloILrBVn9rxha2Dcw9rFyMkhIWAi 0XJ8JTOELSZx4d56ti5GLg4hgaOMEgvf3mSEcBYzStz7tQnI4eBgE7CQ6P6nDdIgIqArsejs A3YQm1kgSeLuvr9gQ4UF7CWm/tzMAlHjIDGn/TgrhG0kcWLZTkYQm0VAReLS1vXsICN5BXwl WidUQaxqYJLYen8DWC+nQKBE04LXYPWMQMd9P7WGCWKXuMStJ/OZII4WkFiy5zzUA6ISLx// g3pMSWLF9ktgJzMLaEqs36UP0aooMaX7IdjJvAKCEidnPmGZwCg2C8nUWQgds5B0zELSsYCR ZRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYOwc3PJbdwfj6teOhxgFOBiVeHgXbNQJEWJN LCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjEwfRGrTl+0T+f66 bDMng4/yBpEaZbMz/As7JprZLJd0Om9mOS316/mpfHJT/k/dvpchYgLDxYgne33e/eHNqWL7 8LUyvs3D249FlGFBlUeG7g1tRa67cy4xt0r94rQLtlCeEvr0drBv+MWLEpM6vvUzGVw64Gux RPjrysa/DMni0kU3/0z/q8RSnJFoqMVcVJwIAOTGIlV+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Xag__Qct1nLv1Lcj-om_4dbIZuw Cc: " list" Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 16:25:43 -0000 SGksDQoNCj4+IEluIGFkZGl0aW9uLCAgZHJhZnQtaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5jYXBz LCB3aGljaCBkZWZpbmVzIFNDVFAgb3ZlciBEVExTLCBzYXlzIHRoYXQgdGhlIERUTFMgDQo+PiBw YXJ0ICJNVVNUIGJlIGJhc2VkIG9uIERUTFMgMS4wIi4gTm90IHJlYWxseSBzdXJlIHdoYXQgaXMg bWVhbnQgYnkgImJhc2VkIG9uIiwgYnV0IGRvZXMgdGhhdCANCj4+IGNvdmVyIERUTFMgb3ZlciBU Q1A/DQo+DQo+IEkgaG9wZSB0aGF0IERUTFMgMS4yIGlzIE9LLiAgV2UncmUgc2hpcHBpbmcgdGhh dC4NCg0KV2VsbCwgRFRMUyAxLjIgaXMgImJhc2VkIG9uIiBEVExTIDEuMCwgc28uLi4gOikNCg0K UkZDIDYzNDcgKERUTFMgMS4yKSBkb2VzIG1lbnRpb24gRFRMUyBvdmVyIFRDUCwgYnV0IHRoZXJl IGlzIG5vIHJlZmVyZW5jZSwgYW5kIHRoZSBwcm9jZWR1cmVzIGluIHRoZSBSRkMgc2VlbSB0byBh c3N1bWUgKHBsZWFzZSBjb3JyZWN0IG1lIGlmIEknbSB3cm9uZykgVURQLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0K From nobody Thu Oct 2 11:24:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFB41A1A7C for ; Thu, 2 Oct 2014 11:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSyf4CfeSaad for ; Thu, 2 Oct 2014 11:24:18 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46DD1A1A79 for ; Thu, 2 Oct 2014 11:24:18 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-05v.sys.comcast.net with comcast id yJPA1o0045FMDhs01JQHVZ; Thu, 02 Oct 2014 18:24:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id yJQG1o00A3Ge9ey01JQG5f; Thu, 02 Oct 2014 18:24:17 +0000 Message-ID: <542D9850.6050807@alum.mit.edu> Date: Thu, 02 Oct 2014 14:24:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <542C0C31.70506@alum.mit.edu> <542C94CE.50600@nteczone.com> <542CAC38.5020708@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4637E9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4637E9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412274258; bh=v36ttnEMfBOojUSzlz14Z5ewqsqiS1y9n19fcV4aL/0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pb/4o5O4+pl8F+jIbadxk5R/wjtrGVpHHPCDO+JnivXVffdTGQG9U9cUCKPM+6M5c XQlb1cJfCpRy8wZLpJhWn23Mgjoy+B4Zq/W495lC/1+M9qN43ixefGvLYsYl9ktKvn WTnZ2hwQPJ9WpqhBTfeyPTfMLaoTSLrN+NKadVgz9lQFWD2xUUrGVa2pdQVRFgJFSP nxvUz/6CsQxaA/SrUIGbrxD/EvfsEHe5g2jPxWFb+j9eGNns2IG2QlbBgYy9EeYxXh /feTveQOcDcz2hcty6khYtX63OM+uN97teOEWBixMkFSmwdFMHZnCEutKjA9NuAtbP z4hrVArMiLCAw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kBcL1c0GW-uNoLsnegl9DM7NYp0 Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 18:24:20 -0000 On 10/2/14 7:59 AM, Christer Holmberg wrote: > Hi, > > Keep in mind that the purpose of draft-ejzak-mmusic-data-channel-sdpneg is NOT to negotiate the usage of the SCTP association. > > It is assumed that the usage of the SCTP association is data channel, and the draft defines a mechanism to negotiate data channels on that SCTP association. The purpose is to negotiate the use of channels, which is almost the same as negotiating the use of individual SCTP streams within an SCTP association. The reason it was tied to data channels was so that it would be usable from webrtc browser apps. Thanks, Paul > Regards, > > Christer > > > > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 2. lokakuuta 2014 4:37 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question > > On 10/1/14 7:57 PM, Christian Groves wrote: >> What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00? > > I don't know the status. The thought Keith Drage had indicated that he was picking up responsibility for it. > > Thanks, > Paul > >> It has expired and is based on the old SDP SCTP syntax. Particularly >> the example in cl.4: >> >> m=application 54111 DTLS/SCTP 5000 5001 5002 >> c=IN IP4 79.97.215.79 >> a=sctpmap:5000 webrtc-datachannel >> a=sctpmap:5001 bfcp >> a=sctpmap:5002 t38 >> >> Wouldn't apply if we're saying to use multiple m-lines. >> >> I guess cl.5.1.1.3 would use the same Websocket subprotocol name >> registry as data channel does? >> >> Regards, Christian >> >> On 2/10/2014 12:14 AM, Paul Kyzivat wrote: >>> On 10/1/14 3:44 AM, Christian Groves wrote: >>> >>>>> >>>>> there have been several discussion about the ability to have more >>>>> than one usage of the SCTP association, and has been agreed not to >>>>> allow it. >>>>> So each 'm' line describes a single SCTP association; each >>>>> association has only one single specify usage. >>>>> >>>> >>>> [CNG] So how would I specify in SDP a scenario where BFCP uses a >>>> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where >>>> they both use the same DTLS connection? Are these to be separate m-lines? >>> >>> To have two different SCTP associations over the same DTLS >>> connection, they would have to be distinguished by sctp-port. To >>> achieve that you could write two m-lines. They would share the same >>> ip address and port, and would have different "a=sctp-port" lines. >>> Then they would have to be bundled. >>> >>> Doing that would require extending the definition of bundle to cover >>> that case. (There is no *technical* problem in doing this.) >>> >>> OTOH, in principle they don't need their own SCTP association. AFAIK >>> they each only use one sctp stream-pair (channel). If they could >>> agree on how to choose channels then they could share an SCTP association. >>> That is where draft-ejzak... comes in. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> 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 nobody Thu Oct 2 11:32:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1F11A930A for ; Thu, 2 Oct 2014 11:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLt3EyfvIT4Q for ; Thu, 2 Oct 2014 11:31:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563991A9251 for ; Thu, 2 Oct 2014 11:31:59 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-cd-542d9a1dfd48 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 50.02.21432.D1A9D245; Thu, 2 Oct 2014 20:31:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 20:31:57 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAbMGAgACi2wCAABvpAIAAzvdAgABKewCAACMuAA== Date: Thu, 2 Oct 2014 18:31:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4645E4@ESESSMB209.ericsson.se> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <542C0C31.70506@alum.mit.edu> <542C94CE.50600@nteczone.com> <542CAC38.5020708@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4637E9@ESESSMB209.ericsson.se> <542D9850.6050807@alum.mit.edu> In-Reply-To: <542D9850.6050807@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja7sLN0Qg3m/xC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuju2s3a8EVmYppdxYyNzBOEe9i5OSQEDCR aN20lR3CFpO4cG89WxcjF4eQwFFGic770xkhnMWMEvO6JwFlODjYBCwkuv9pgzSICPhKPHt8 mw3EFhbwkfhz8iE7THxV71VGCDtLYt7MfywgNouAisTTP4dZQWxeoJopi/5BzX/OJDHp5EEm kASngI7E01PLwYoYgS76fmoNWJxZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8rhK0ksWL7JUaI eh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7KTTcy 0kstykwuLs7P08tLLdnECIyUg1t+G+xgfPnc8RCjAAejEg/vgo06IUKsiWXFlbmHGKU5WJTE eReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTFByqd/29+97W8NlDu8ZidWVtlfrGWO suOyOVQn2xqpfb9me8MpX1ELWfVCGdc7rA7/DzPtCyi4KH4g14D11QR272jfHKn2n3+WNm0t 0NN9FJ41PWf3dx+rZSrS93ZJ1Rhu2iQ68dOkG5eE1J9Z6SV/fRjV9VS12dt/ps8Sl1VCMRcK L35UV2Ipzkg01GIuKk4EAN03nRp1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TDyth-dRYvhWCed4o5z4klyoWf8 Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 18:32:02 -0000 Hi, >> Keep in mind that the purpose of draft-ejzak-mmusic-data-channel-sdpneg = is NOT to negotiate=20 >> the usage of the SCTP association. >> >> It is assumed that the usage of the SCTP association is data channel, an= d the draft defines a=20 >> mechanism to negotiate data channels on that SCTP association. > > The purpose is to negotiate the use of channels, which is almost the same= as negotiating the use of > individual SCTP streams within an SCTP associa= tion. Correct. But, it is not used to negotiate the SCTP association usage, which= I think is what Christian has been talking about. It assumes that the SCTP= association is used for data channels. Regards, Christer > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul=20 > Kyzivat > Sent: 2. lokakuuta 2014 4:37 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax=20 > question > > On 10/1/14 7:57 PM, Christian Groves wrote: >> What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00? > > I don't know the status. The thought Keith Drage had indicated that he wa= s picking up responsibility for it. > > Thanks, > Paul > >> It has expired and is based on the old SDP SCTP syntax. Particularly=20 >> the example in cl.4: >> >> m=3Dapplication 54111 DTLS/SCTP 5000 5001 5002 >> c=3DIN IP4 79.97.215.79 >> a=3Dsctpmap:5000 webrtc-datachannel >> a=3Dsctpmap:5001 bfcp >> a=3Dsctpmap:5002 t38 >> >> Wouldn't apply if we're saying to use multiple m-lines. >> >> I guess cl.5.1.1.3 would use the same Websocket subprotocol name=20 >> registry as data channel does? >> >> Regards, Christian >> >> On 2/10/2014 12:14 AM, Paul Kyzivat wrote: >>> On 10/1/14 3:44 AM, Christian Groves wrote: >>> >>>>> >>>>> there have been several discussion about the ability to have more=20 >>>>> than one usage of the SCTP association, and has been agreed not to=20 >>>>> allow it. >>>>> So each 'm' line describes a single SCTP association; each=20 >>>>> association has only one single specify usage. >>>>> >>>> >>>> [CNG] So how would I specify in SDP a scenario where BFCP uses a=20 >>>> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where=20 >>>> they both use the same DTLS connection? Are these to be separate m-lin= es? >>> >>> To have two different SCTP associations over the same DTLS=20 >>> connection, they would have to be distinguished by sctp-port. To=20 >>> achieve that you could write two m-lines. They would share the same=20 >>> ip address and port, and would have different "a=3Dsctp-port" lines. >>> Then they would have to be bundled. >>> >>> Doing that would require extending the definition of bundle to cover=20 >>> that case. (There is no *technical* problem in doing this.) >>> >>> OTOH, in principle they don't need their own SCTP association. AFAIK=20 >>> they each only use one sctp stream-pair (channel). If they could=20 >>> agree on how to choose channels then they could share an SCTP associati= on. >>> That is where draft-ejzak... comes in. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> 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 nobody Thu Oct 2 11:55:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91BC1A1AAC for ; Thu, 2 Oct 2014 11:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZAJFTAXp-B9 for ; Thu, 2 Oct 2014 11:55:40 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCBA1A1AA4 for ; Thu, 2 Oct 2014 11:55:39 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-08v.sys.comcast.net with comcast id yJvP1o00A4xDoy801Jvf6j; Thu, 02 Oct 2014 18:55:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id yJve1o00F3Ge9ey01JvedE; Thu, 02 Oct 2014 18:55:39 +0000 Message-ID: <542D9FAA.2000609@alum.mit.edu> Date: Thu, 02 Oct 2014 14:55:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <542C0C31.70506@alum.mit.edu> <542C94CE.50600@nteczone.com> <542CAC38.5020708@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4637E9@ESESSMB209.ericsson.se> <542D9850.6050807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4645E4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4645E4@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412276139; bh=rh9mP4IiUUCY6a18AhODQSbBDxukyEF5+THx00KPPHo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cduGq8P8p3ZQxv/DMEdeLvfQcTaWGSeP3Do1A7EB7dir3kGM+x4DS5EEerK9RaOmu O29XcPPEZuajtJWOY5x+KmZ7hyWKma+RZHvCoKhNEAZMvCTDUdycRCGRCcBrhX/M7w j6lo+ihIYLZwsDNZsO/c09AMHPJXHG1VHTIi9kekKOY3wqzDwnO/y3Wm7tDv+h+rVH qRNr4qASnewnbWLnyxrkR/NUgBHhBm+h07/W2DpG3QoyTNEsz2FlqJZc25TQFlxH8j VdtzEab0wccHZ3CUlgiK9m72xvWyROWOgkmArb5di1IAgl7X9EVysljK89wOTo415k Dv8J5wvsWqiPg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IEK0TDrhMA8EgQKqzXT6fTp87z8 Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 18:55:41 -0000 On 10/2/14 2:31 PM, Christer Holmberg wrote: > Hi, > >>> Keep in mind that the purpose of draft-ejzak-mmusic-data-channel-sdpneg is NOT to negotiate >>> the usage of the SCTP association. >>> >>> It is assumed that the usage of the SCTP association is data channel, and the draft defines a >>> mechanism to negotiate data channels on that SCTP association. >> >> The purpose is to negotiate the use of channels, which is almost the same as negotiating the use of > individual SCTP streams within an SCTP association. > > Correct. But, it is not used to negotiate the SCTP association usage, which I think is what Christian has been talking about. It assumes that the SCTP association is used for data channels. Yes. But for the most part Christian is talking about stream/channel usages that have not yet been defined. When the are defined, they could be done so using channels or something else. The main constraint here is enabling this stuff to work with webrtc. I think that constraint is effectively forcing the use of the data channel association usage. And this is all hypothetical because draft-ejak is far from complete. So, if it goes forward at all it may end up different from what it is now. Thanks, Paul From nobody Thu Oct 2 13:22:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70B31A86EC for ; Thu, 2 Oct 2014 13:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ywTVxEUuBix for ; Thu, 2 Oct 2014 13:22:12 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446C51A02DE for ; Thu, 2 Oct 2014 13:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1464; q=dns/txt; s=iport; t=1412281332; x=1413490932; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=gvxTjVE2Ad/A0HqVMXiQajWwoBSbWKDXiOw6MFuwAE4=; b=CuTOp4JcCa7SDX2+NJhg7LTn6NfSEzeWhm8XDPA25nKLnvxCoTkVmRvR XM2/LfNqSf6ir+l7xqIfqfIxcPWFiN4yMsBUkLrEfNiwE/yLmvR6cV1Yn 32w0TQ1/H7F6ur4g1cJ+sufOv3COUn2HevwYxEv4dfP+uphsXh9FAaeAb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYKAD+zLVStJV2T/2dsb2JhbABfgw64DgUBcpt2FgF7hEJ9NAJMDQgBAYg6mHKlLhiGFY5jAQSYb4RMh1yOH4N/IYJ5AQEB X-IronPort-AV: E=Sophos;i="5.04,640,1406592000"; d="scan'208";a="83552717" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP; 02 Oct 2014 20:22:11 +0000 Received: from [10.98.149.205] (bxb-fandreas-88112.cisco.com [10.98.149.205]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s92KMBgm028228 for ; Thu, 2 Oct 2014 20:22:11 GMT Message-ID: <542DB3F2.808@cisco.com> Date: Thu, 02 Oct 2014 16:22:10 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/KvtEmJynhX9-aAsCtJEbX-Xj8y8 Subject: [MMUSIC] Offer/Answer sections in SDP drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 20:22:14 -0000 Greetings One of the things we have tried to emphasize for SDP related drafts is the need to have well-defined offer/answer procedures, and as part of that, we have been asking people to follow the structure of RFC 3264. This means there needs to be the following O/A sections in SDP related drafts (in the order shown): 1. Generating the Initial Offer 2. Generating the Answer 3. Offerer Processing of the Answer 4. Modifying the Session As part of the bundle-11 draft review, a (general) question came up around what actually goes in the "Generating the Answer" section. More specifically, should this section a) Apply to the initial offer only b) Apply to the initial offer and subsequent offers for the parts that apply in a general manner to both [parts that apply to subsequent offers only would be covered by "Modifying the Session"] c) Apply to all offers. I believe the answer is b), however some feel the answer is c). One of the issues I see with that is that you potentially end up depending on text/rules from "Modifying the Session", however those procedures have not been defined at that point in the document. This can of course be solved with forward referencing (as is done in bundle-11), however it makes it harder to follow IMO and I also do not believe this is what RFC 3264 intended. Comments on the above would be appreciated. Thanks -- Flemming From nobody Thu Oct 2 13:53:25 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE671A7D85 for ; Thu, 2 Oct 2014 13:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuaKonXOaWOM for ; Thu, 2 Oct 2014 13:53:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7310B1A86F0 for ; Thu, 2 Oct 2014 13:53:13 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-d8-542dbb37ccb2 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.C3.24955.73BBD245; Thu, 2 Oct 2014 22:53:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 22:53:11 +0200 From: Christer Holmberg To: Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] Offer/Answer sections in SDP drafts Thread-Index: AQHP3n6SQ2p6yESBZkaoSXn9EKGU3JwdRvHg Date: Thu, 2 Oct 2014 20:53:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4647DA@ESESSMB209.ericsson.se> References: <542DB3F2.808@cisco.com> In-Reply-To: <542DB3F2.808@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja75bt0Qg3O3JS3eX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAldF7awd7wQ2hitZnHewNjI/4uhg5OSQETCR+ nnvPDGGLSVy4t56ti5GLQ0jgKKPE/9nbmSCcxYwSu3qPMXYxcnCwCVhIdP/TBmkQEXCVOLLw LhOILSxgKXFy+QVmiLiVxKOTJ5ggbCOJB0fPgsVZBFQkTvZuZwGxeQV8JU7MXswKYgsBxZ+t +8oOYnMKqEpM/nIarJcR6KDvp9aA2cwC4hK3nsxngjhUQGLJnvNQR4tKvHz8jxXCVpJYexhi PrOAjsSC3Z/YIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+Wm GxnrpRZlJhcX5+fp5aWWbGIERsnBLb9VdzBefuN4iFGAg1GJh3fBRp0QIdbEsuLK3EOM0hws SuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOJXn2Beb2xOLp+/eefTepZQDEw7l J4VFdly/tm9O8JT0O78bN3T8FLjIGD2h4dIKyQseSZsF/e5tOJjx5VzmsaDQs8dPdKtM5K3c w9TRu649WozVdOXegFVr3D+rfnzc+lVsSbHmpTdcrnlr+8PEnzn5zgk5UizbxSt2a7HwJO5W jRfX9vi8OabEUpyRaKjFXFScCACboWOBcwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f2HbZoFGK6qPxHx3lQaOFs0EWPg Subject: Re: [MMUSIC] Offer/Answer sections in SDP drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 20:53:23 -0000 Hi, In general, I believe the answer is c). Of course, if there are major differences in the generating-answer procedur= es, depending on whether the answer is generated for the initial or a modif= ication offer, they could be put in separate places. But, in the case of BU= NDLE, the generating-answer procedures are more or less identical (some par= t may only apply to one case, though), so I see no need to separate them. And, unless I've missed something, I believe I got rid of the forward refer= ences in version -11 :) Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreas= en Sent: 02 October 2014 23:22 To: mmusic Subject: [MMUSIC] Offer/Answer sections in SDP drafts Greetings One of the things we have tried to emphasize for SDP related drafts is the = need to have well-defined offer/answer procedures, and as part of that, we = have been asking people to follow the structure of RFC 3264.=20 This means there needs to be the following O/A sections in SDP related draf= ts (in the order shown): 1. Generating the Initial Offer 2. Generating the Answer 3. Offerer Processing of the Answer 4. Modifying the Session As part of the bundle-11 draft review, a (general) question came up around = what actually goes in the "Generating the Answer" section. More specificall= y, should this section a) Apply to the initial offer only b) Apply to the initial offer and subsequent offers for the parts that= apply in a general manner to both [parts that apply to subsequent offers o= nly would be covered by "Modifying the Session"] c) Apply to all offers. I believe the answer is b), however some feel the answer is c). One of the = issues I see with that is that you potentially end up depending on text/rul= es from "Modifying the Session", however those procedures have not been def= ined at that point in the document. This can of course be solved with forwa= rd referencing (as is done in bundle-11), however it makes it harder to fol= low IMO and I also do not believe this is what RFC 3264 intended. Comments on the above would be appreciated. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Sun Oct 5 20:52:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04D41A01D5 for ; Sun, 5 Oct 2014 20:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5jfCBdCeaAz for ; Sun, 5 Oct 2014 20:52:53 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07DD1A1B0D for ; Sun, 5 Oct 2014 20:52:52 -0700 (PDT) Received: from ppp118-209-167-95.lns20.mel8.internode.on.net ([118.209.167.95]:57650 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XazL5-0007Tg-Rj for mmusic@ietf.org; Mon, 06 Oct 2014 14:52:00 +1100 Message-ID: <54321211.2010804@nteczone.com> Date: Mon, 06 Oct 2014 14:52:49 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> <542C8452.1030206@nteczone.com> <542C8895.6080408@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4634D8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4634D8@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FF6PDywb_8tMXPq9vjkyob_xsfY Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2014 03:52:55 -0000 Hello Christer, On 2/10/2014 7:39 PM, Christer Holmberg wrote: > Hi, > >>> I'm happy to use to m-lines. I think it would be good to have >>> something in the draft describing the usage of multiple DTLS/SCTP >>> m-lines (with the same port) so that its clear that's the intention. >> The thing is - it would be bad to give an example using bundle while there is no definition of how bundle works for that. (It is not included in the bundle spec.) >> >> That would mean adding the interaction with bundle into this draft, or in a new draft. While that is possible, do we want to take that on now? >> >> This would be a good time for Christer to chime in. :-) > As Paul said, BUNDLE does not specify the usage of multiple DTLS m- lines within a BUNDLE group, and explicitly says that such usage would have to be defined in another specification. > > Personally, I'd be quite surprised if people started to transport BFCP, MSRP etc over DTLS/SCTP. People haven't used SCTP for that in the past, so why would they suddenly start now? [CNG] It seems now people are being forced to use to SCTP due to interoperation with WebRTC. They may want to run over a secure association etc. There will be new protocols that will be defined. > > I think DTLS/SCTP is going to be used mainly for data channel usage, and one can then define data channels to transport whatever (including BFCP and MSRP). [CNG] Mainly or only? If its mainly then there's a possibility to run something else in another SCTP association. If this "something else" runs in across a separate SCTP association on a seperate DTLS port then its no issue. If this "something else" is a separate SCTP association on the same DTLS port then it is an issue. There has been a suggestion to use bundle, but bundle doesn't cover this. I think the draft should offer some guidance or at least highlight the issues with respect to this. With regards to the data channels if I do as you say and use datachannels for bfcp and msrp in the one DTLS/SCTP association. How would I go about signalling that via SDP? Do I use the same method as CLUE and define a group for each of these? Do I use ejzak? Do I use both? CLUE decided that it didn't need to consider other protocols. However shouldn't the scope of the mmusic work be to look at the scenarios where you could have multiple protocols? Regards, Christian > > Regards, > > Christer > > > > >> On 1/10/2014 10:45 PM, Christer Holmberg wrote: >>> My mistake: I meant SCTP association, which then can contains >>> multiple SCTP streams. >>> >>> Sorry for the confusion. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> Sent: 1. lokakuuta 2014 15:43 >>> To: Christer Holmberg; Christian Groves; Salvatore Loreto >>> Cc: >>> Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax >>> question >>> >>>> I think we need to be careful with the terminology. >>>> As far as I understand, the m- lines describes an SCTP connection - >>>> not an SCTP association - and the sctp-fmt defines the usage of that >>>> SCTP connection. >>> Christer, >>> there isn't any concept of an "SCTP connection" (see RFC 4960)! >>> Rather SCTP association, SCTP path, SCTP stream. >>> >>> If you are refering implicitly to the OSI concept of a (N)-connection >>> (ITU-T X.200), then an OSI (SCTP)-connection would be mapped to the >>> IETF SCTP association in my understanding. >>> >>> Regards, >>> Albrecht >>> >>> PS >>> Perhaps you mean sth like, ".. the m- lines describes an IP transport >>> connection for SCTP, which relates to an SCTP association ..." >>> >>> >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer >>> Holmberg >>> Sent: Mittwoch, 1. Oktober 2014 13:43 >>> To: Christian Groves; Salvatore Loreto >>> Cc: >>> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax >>> question >>> >>> Hi, >>> >>> I think we need to be careful with the terminology. >>> >>> As far as I understand, the m- lines describes an SCTP connection - >>> not an SCTP association - and the sctp-fmt defines the usage of that >>> SCTP connection. >>> >>> Depending on the usage, there may then be multiple SCTP associations >>> - for example as in the case of a data-channel connection usage, >>> where the number of SCTP associations will depend on the number of >>> data channels. >>> >>> So, if you want to use BFCP and MSRP, my understanding is that you >>> would need two m- lines (unless, of course, you transport BFCP and >>> MSRP within data channels). >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 1. lokakuuta 2014 10:45 >>> To: Salvatore Loreto >>> Cc: >>> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax >>> question >>> >>> Hello Salvatore, >>> >>> Thanks for the replies. Please see some comments below. >>> >>> Regards, Christian >>> >>> On 1/10/2014 5:29 PM, Salvatore Loreto wrote: >>>> Hi Christian, >>>> >>>> thanks a lot for reading and reviewing the draft see more in line >>>> >>>> On Sep 30, 2014, at 3:48 PM, Christian Groves >>>> wrote: >>>> >>>>> I seemed to have got cut and paste happy in 1) below. The "1*(SP >>>>> sctp-fmt)" should only apply to "DTLS/SCTP". >>>>> >>>>> Christian >>>>> >>>>> On 30/09/2014 10:12 PM, Christian Groves wrote: >>>>>> Hello Salvatore, >>>>>> >>>>>> There seems to be several issues with the updated syntax: >>>>>> >>>>>> 1) Cl.4.1 Media Description: With the updated syntax the ability >>>>>> to have more than one usage of the SCTP association has been lost >>>>>> as "sctp-fmt" is a single value. >>>> >>>> there have been several discussion about the ability to have more >>>> than one usage of the SCTP association, and has been agreed not to allow it. >>>> So each 'm' line describes a single SCTP association; each >>>> association has only one single specify usage. >>>> >>> [CNG] So how would I specify in SDP a scenario where BFCP uses a >>> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where >>> they both use the same DTLS connection? Are these to be separate m-lines? >>>> ..snip.. >>>>>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from >>>>>> the syntax between association-usage and max-message-size. >>>>>> >>>>>> sctpmap-attr = "a=fmtp:" association-usage [max-message-size] >>>>>> >>>>>> should be: >>>>>> sctpmap-attr = "a=fmtp:" association-usage [SP max-message-size] >>>>>> >>>>>> The current syntax allows an fmtp usage with no max-message-size >>>>>> parameter, e.g. "a=fmtp:bfcp". Should this be allowed? >>>> >>>> this has been discussed back in April or May. It has been decided >>>> that the max-message-size parameter is optional. >>>> In the case it is not present the default value is 64K >>> [CNG] I agree that the max-message-size parameter is optional, in >>> that case an endpoint wouldn't specify the whole a=ftmp: line. It >>> seems strange to allow the endpoint to specify half a line? >>> >>>>>> 5) Cl.4.1.2: "If the parameter is not present, the implementation >>>>>> should provide a default, with a suggested value of 64K." Is this >>>>>> 64,000 or is 65,535 bytes? >>> [CNG] I think you skipped this? >>> >>>>>> 7) Cl.10: How will this registry relate to the "WebSocket >>>>>> Subprotocol Name Registry" >>>>>> (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)? >>>>>> >>>> >>>> It is not related. The 'association-usage' specifies how the SCTP >>>> association will be used. >>>> For example in the case of webrtc-datachannel value it would >>>> indicate how to pair certain streams, how to consider specific stream etc. >>>> as described in >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and >>>> in http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ >>>> >>>> the WebSocket Subprotocol Name Registry is used to populate the >>>> protocol field in the protocol field in >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#secti >>>> on >>>> -5 >>>> >>>> >>> [CNG] So if I use the SCTP association for "bfcp" then i'd need to >>> document this in the new registry associated with the draft? and if I >>> then used "bfcp" for webrtc-datachannel then i'd need to update the >>> websocket registry. Two places for the same protocol? >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 nobody Sun Oct 5 20:54:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3640B1A1B0D for ; Sun, 5 Oct 2014 20:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBYPtxvx_WII for ; Sun, 5 Oct 2014 20:54:36 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D237A1A01D5 for ; Sun, 5 Oct 2014 20:54:35 -0700 (PDT) Received: from ppp118-209-167-95.lns20.mel8.internode.on.net ([118.209.167.95]:57653 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XazMm-0007kV-27 for mmusic@ietf.org; Mon, 06 Oct 2014 14:53:44 +1100 Message-ID: <54321279.2040905@nteczone.com> Date: Mon, 06 Oct 2014 14:54:33 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <542C0C31.70506@alum.mit.edu> <542C94CE.50600@nteczone.com> <542CAC38.5020708@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4637E9@ESESSMB209.ericsson.se> <542D9850.6050807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4645E4@ESESSMB209.ericsson.se> <542D9FAA.2000609@alum.mit.edu> In-Reply-To: <542D9FAA.2000609@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/go3blrPyh5d21wn5zCbFlSIlR_8 Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2014 03:54:37 -0000 On 3/10/2014 4:55 AM, Paul Kyzivat wrote: > On 10/2/14 2:31 PM, Christer Holmberg wrote: >> Hi, >> >>>> Keep in mind that the purpose of >>>> draft-ejzak-mmusic-data-channel-sdpneg is NOT to negotiate >>>> the usage of the SCTP association. >>>> >>>> It is assumed that the usage of the SCTP association is data >>>> channel, and the draft defines a >>>> mechanism to negotiate data channels on that SCTP association. >>> >>> The purpose is to negotiate the use of channels, which is almost the >>> same as negotiating the use of > individual SCTP streams within an >>> SCTP association. >> >> Correct. But, it is not used to negotiate the SCTP association usage, >> which I think is what Christian has been talking about. It assumes >> that the SCTP association is used for data channels. > > Yes. But for the most part Christian is talking about stream/channel > usages that have not yet been defined. When the are defined, they > could be done so using channels or something else. The main constraint > here is enabling this stuff to work with webrtc. > > I think that constraint is effectively forcing the use of the data > channel association usage. > > And this is all hypothetical because draft-ejak is far from complete. > So, if it goes forward at all it may end up different from what it is > now. [CNG] I've been talking about both, negotiating the SCTP association usage and/or the usage of the individual SCTP streams/data channels. Paul is correct in that I'm thinking of usages/protocols that have not yet been defined. I'm trying to understand the process on how these would be added in the future to situations where data channel is used and situations where data channel is not used. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Oct 6 00:09:50 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE191A1B43 for ; Mon, 6 Oct 2014 00:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6I9lo8ZpJnjK for ; Mon, 6 Oct 2014 00:09:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2122C1A1B40 for ; Mon, 6 Oct 2014 00:09:44 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-89-54324036fefd Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.38.21432.63042345; Mon, 6 Oct 2014 09:09:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Mon, 6 Oct 2014 09:09:42 +0200 From: Christer Holmberg To: Christian Groves , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAYywg///wCgCAACI0IIAAhosAgAAFFYCAANFFoIAFyIGAgABUJqA= Date: Mon, 6 Oct 2014 07:09:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4692C9@ESESSMB209.ericsson.se> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> <542C8452.1030206@nteczone.com> <542C8895.6080408@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4634D8@ESESSMB209.ericsson.se> <54321211.2010804@nteczone.com> In-Reply-To: <54321211.2010804@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja6Zg1GIwZejJhZf3jeyWExd/pjF gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mpo25JWsDqgYuaDg8wNjB8duxg5OCQETCT+ vdbuYuQEMsUkLtxbz9bFyMUhJHCUUeLKgx4WCGcxo0THulvsIA1sAhYS3f/AGkQEoiUmLWxm A7GFBXwk/px8yA4R95VY1XuVEcIuk+jcORHMZhFQkVjx+jGYzQtUc+/yWaj5S1gk1m9pZgZJ cAroSGzpnA5WxAh00fdTa5hAbGYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf6wQzyhJTNuaBlGu I7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkqmzkLTMQtIyC0nLAkaWVYyixanFSbnpRkZ6 qUWZycXF+Xl6eaklmxiBMXJwy2+DHYwvnzseYhTgYFTi4U3YbxgixJpYVlyZe4hRmoNFSZx3 4bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYJ3ScjXtTejK0IHh/nusH4UN8S1ikDgod +Fm3+Nnry09LFTcvW3D02FaOLNHHC5oEXXovlnZOZev3W9q9Lutc5ubv6Tus9B9qX3rdUmml 8y33UtC9v0s/J60TSBP33lATfaB4lbDRMvmtPILfayfMfhaduI2JtZzbI+XlpMP9iwS/iX0r m9mySImlOCPRUIu5qDgRAJUBr/xyAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/33HssYxYTp__AcVTe1e3GdfS-k8 Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2014 07:09:49 -0000 Hi, >>>> I'm happy to use to m-lines. I think it would be good to have=20 >>>> something in the draft describing the usage of multiple DTLS/SCTP=20 >>>> m-lines (with the same port) so that its clear that's the intention. >>> The thing is - it would be bad to give an example using bundle while=20 >>> there is no definition of how bundle works for that. (It is not=20 >>> included in the bundle spec.) >>> >>> That would mean adding the interaction with bundle into this draft, or = in a new draft. While that is possible, do we want to take that on now? >>> >>> This would be a good time for Christer to chime in. :-) >> As Paul said, BUNDLE does not specify the usage of multiple DTLS m- line= s within a BUNDLE group, and explicitly says that such usage would have to = be defined in another specification. >> >> Personally, I'd be quite surprised if people started to transport BFCP, = MSRP etc over DTLS/SCTP. People haven't used SCTP for that in the past, so = why would they suddenly start now? > [CNG] It seems now people are being forced to use to SCTP due to interope= ration with WebRTC. They may want to run over a secure association etc. The= re will be new protocols that will be defined. Currently WebRTC only defines the usage of SCTP for the data channel. >> I think DTLS/SCTP is going to be used mainly for data channel usage, and= one can then define data channels to transport whatever (including BFCP an= d MSRP). > [CNG] Mainly or only? If its mainly then there's a possibility to run som= ething else in another SCTP association. If this "something else"=20 > runs in across a separate SCTP association on a seperate DTLS port then i= ts no issue. If this "something else" is a separate SCTP association on the= same DTLS port then it is an issue.=20 > There has been a suggestion to use bundle, but bundle doesn't cover this.= =20 The core BUNDLE spec doesn't cover it, but someone can write an extension w= hich defines how it is done.=20 > I think the draft should offer some guidance or at least highlight the is= sues with respect to this. I do agree that some words about why only a single SCTP association usage i= s allowed would be good. >With regards to the data channels if I do as you say and use datachannels = for bfcp and msrp in the one DTLS/SCTP association. How would I go about si= gnalling that via SDP? > >Do I use the same method as CLUE and define a group for each of these? Do = I use ejzak? Do I use both? CLUE decided that it didn't need to consider ot= her protocols.=20 >However shouldn't the scope of the mmusic work be to look at the scenarios= where you could have multiple protocols? Currently, there is no generic way to signal the datachannel usage in SDP. = The ejzak draft defines SDP attributes for doing that, but the draft hasn't= taken off.=20 Regards, Christer >> On 1/10/2014 10:45 PM, Christer Holmberg wrote: >>> My mistake: I meant SCTP association, which then can contains=20 >>> multiple SCTP streams. >>> >>> Sorry for the confusion. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: Schwarz, Albrecht (Albrecht) >>> [mailto:albrecht.schwarz@alcatel-lucent.com] >>> Sent: 1. lokakuuta 2014 15:43 >>> To: Christer Holmberg; Christian Groves; Salvatore Loreto >>> Cc: >>> Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax=20 >>> question >>> >>>> I think we need to be careful with the terminology. >>>> As far as I understand, the m- lines describes an SCTP connection -=20 >>>> not an SCTP association - and the sctp-fmt defines the usage of=20 >>>> that SCTP connection. >>> Christer, >>> there isn't any concept of an "SCTP connection" (see RFC 4960)! >>> Rather SCTP association, SCTP path, SCTP stream. >>> >>> If you are refering implicitly to the OSI concept of a=20 >>> (N)-connection (ITU-T X.200), then an OSI (SCTP)-connection would be=20 >>> mapped to the IETF SCTP association in my understanding. >>> >>> Regards, >>> Albrecht >>> >>> PS >>> Perhaps you mean sth like, ".. the m- lines describes an IP=20 >>> transport connection for SCTP, which relates to an SCTP association ...= " >>> >>> >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer=20 >>> Holmberg >>> Sent: Mittwoch, 1. Oktober 2014 13:43 >>> To: Christian Groves; Salvatore Loreto >>> Cc: >>> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax=20 >>> question >>> >>> Hi, >>> >>> I think we need to be careful with the terminology. >>> >>> As far as I understand, the m- lines describes an SCTP connection -=20 >>> not an SCTP association - and the sctp-fmt defines the usage of that=20 >>> SCTP connection. >>> >>> Depending on the usage, there may then be multiple SCTP associations >>> - for example as in the case of a data-channel connection usage,=20 >>> where the number of SCTP associations will depend on the number of=20 >>> data channels. >>> >>> So, if you want to use BFCP and MSRP, my understanding is that you=20 >>> would need two m- lines (unless, of course, you transport BFCP and=20 >>> MSRP within data channels). >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian=20 >>> Groves >>> Sent: 1. lokakuuta 2014 10:45 >>> To: Salvatore Loreto >>> Cc: >>> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax=20 >>> question >>> >>> Hello Salvatore, >>> >>> Thanks for the replies. Please see some comments below. >>> >>> Regards, Christian >>> >>> On 1/10/2014 5:29 PM, Salvatore Loreto wrote: >>>> Hi Christian, >>>> >>>> thanks a lot for reading and reviewing the draft see more in line >>>> >>>> On Sep 30, 2014, at 3:48 PM, Christian Groves=20 >>>> wrote: >>>> >>>>> I seemed to have got cut and paste happy in 1) below. The "1*(SP=20 >>>>> sctp-fmt)" should only apply to "DTLS/SCTP". >>>>> >>>>> Christian >>>>> >>>>> On 30/09/2014 10:12 PM, Christian Groves wrote: >>>>>> Hello Salvatore, >>>>>> >>>>>> There seems to be several issues with the updated syntax: >>>>>> >>>>>> 1) Cl.4.1 Media Description: With the updated syntax the ability=20 >>>>>> to have more than one usage of the SCTP association has been lost=20 >>>>>> as "sctp-fmt" is a single value. >>>> >>>> there have been several discussion about the ability to have more=20 >>>> than one usage of the SCTP association, and has been agreed not to all= ow it. >>>> So each 'm' line describes a single SCTP association; each=20 >>>> association has only one single specify usage. >>>> >>> [CNG] So how would I specify in SDP a scenario where BFCP uses a=20 >>> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where=20 >>> they both use the same DTLS connection? Are these to be separate m-line= s? >>>> ..snip.. >>>>>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from=20 >>>>>> the syntax between association-usage and max-message-size. >>>>>> >>>>>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [max-message-size] >>>>>> >>>>>> should be: >>>>>> sctpmap-attr =3D "a=3Dfmtp:" association-usage [SP max-message-size] >>>>>> >>>>>> The current syntax allows an fmtp usage with no max-message-size=20 >>>>>> parameter, e.g. "a=3Dfmtp:bfcp". Should this be allowed? >>>> >>>> this has been discussed back in April or May. It has been decided=20 >>>> that the max-message-size parameter is optional. >>>> In the case it is not present the default value is 64K >>> [CNG] I agree that the max-message-size parameter is optional, in=20 >>> that case an endpoint wouldn't specify the whole a=3Dftmp: line. It=20 >>> seems strange to allow the endpoint to specify half a line? >>> >>>>>> 5) Cl.4.1.2: "If the parameter is not present, the implementation=20 >>>>>> should provide a default, with a suggested value of 64K." Is this >>>>>> 64,000 or is 65,535 bytes? >>> [CNG] I think you skipped this? >>> >>>>>> 7) Cl.10: How will this registry relate to the "WebSocket=20 >>>>>> Subprotocol Name Registry" >>>>>> (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol= -name)? >>>>>> >>>> >>>> It is not related. The 'association-usage' specifies how the SCTP=20 >>>> association will be used. >>>> For example in the case of webrtc-datachannel value it would=20 >>>> indicate how to pair certain streams, how to consider specific stream = etc. >>>> as described in >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and=20 >>>> in http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/ >>>> >>>> the WebSocket Subprotocol Name Registry is used to populate the=20 >>>> protocol field in the protocol field in=20 >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#sect >>>> i >>>> on >>>> -5 >>>> >>>> >>> [CNG] So if I use the SCTP association for "bfcp" then i'd need to=20 >>> document this in the new registry associated with the draft? and if=20 >>> I then used "bfcp" for webrtc-datachannel then i'd need to update=20 >>> the websocket registry. Two places for the same protocol? >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 nobody Mon Oct 6 04:14:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6888B1A1BC6 for ; Mon, 6 Oct 2014 04:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYcDxbpNoz6a for ; Mon, 6 Oct 2014 04:13:59 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0440D1A1BD1 for ; Mon, 6 Oct 2014 04:13:58 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id E3605B7A2C2AB; Mon, 6 Oct 2014 11:13:54 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s96BDud5003461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Oct 2014 07:13:57 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 07:13:56 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Christian Groves , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3KfyS5OvwiZLQEuGEinmeFzmuZwZfrEAgAE5V4CAAARPgIAAQooAgAAv9zCAAEYvAIAAafzDgAaZvDOAAHn+gP////dQ Date: Mon, 6 Oct 2014 11:13:56 +0000 Message-ID: References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> <542C8452.1030206@nteczone.com> <542C8895.6080408@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4634D8@ESESSMB209.ericsson.se> <54321211.2010804@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D4692C9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4692C9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MjoHKCRwTvs1eNlCE1_nUEw_MsY Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2014 11:14:00 -0000 > Currently, there is no generic way to signal the datachannel usage in SDP= . > The ejzak draft defines SDP attributes for doing that, but the draft hasn= 't > taken off. [Raju] Right, ejzak draft meant to fill that gap. The plan is to propose th= e updated ejzak draft to MMUSIC. BR Raju From nobody Mon Oct 6 04:34:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E968A1A1BEC for ; Mon, 6 Oct 2014 04:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTYN4--GJEdq for ; Mon, 6 Oct 2014 04:34:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685E21A1BEB for ; Mon, 6 Oct 2014 04:34:27 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-1e-54327e412689 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BC.7C.21432.14E72345; Mon, 6 Oct 2014 13:34:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Mon, 6 Oct 2014 13:33:02 +0200 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , Christian Groves , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAYywg///wCgCAACI0IIAAhosAgAAFFYCAANFFoIAFyIGAgABUJqCAACcZAIAAJqsQ Date: Mon, 6 Oct 2014 11:33:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D469AA1@ESESSMB209.ericsson.se> References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> <542C8452.1030206@nteczone.com> <542C8895.6080408@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4634D8@ESESSMB209.ericsson.se> <54321211.2010804@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D4692C9@ESESSMB209.ericsson.se> 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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja5jnVGIwcqThhZf3jeyWExd/pjF omHjFVYHZo/WZ3tZPZYs+cnkseL8TJYA5igum5TUnMyy1CJ9uwSujI/PnQsWMVecuL2GvYHx MFMXIyeHhICJxMxVD6BsMYkL99azdTFycQgJHGWUWPjrOCuEs5hR4v7X10AOBwebgIVE9z9t kLiIwAJGib9bTrCDdAsL+Ej8OfkQzBYR8JVY1XuVEaKoiVHi5NwtjCAJFgEViXc7HzCD2LxA RZ9XvWGH2LCbVeLtvptgRZwCsRK9Hz+D2YxAN30/tQbsPmYBcYlbT+ZD3SogsWTPeWYIW1Ti 5eN/YNdJCChJTNuaBlGuI7Fg9yc2CFtbYtnC11B7BSVOznzCMoFRdBaSqbOQtMxC0jILScsC RpZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIHRc3DLb4MdjC+fOx5iFOBgVOLhTdhvGCLE mlhWXJl7iFGag0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi3dbRkWQr/1/Ru Pd325NuN1swI1ZWHE5NzU6q+Rgtu2iU54fzVeRMnV+e/+n+ns7NESfhG7qKck70aDgotOuvL l03STWQVDKmaWLNLn/nwvrvFJWeP2iptORDlnfWk8va7VXpXm3vVXX+3ap/4+Xvl5O5gv1Y2 mS8Mh6S3GO+P0GRK07+X2qjEUpyRaKjFXFScCAAbFkJUfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mQdB5feaIOmYFeoj1r6XwsbgmuQ Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 06 Oct 2014 11:34:29 -0000 Hi, >> Currently, there is no generic way to signal the datachannel usage in SD= P. >> The ejzak draft defines SDP attributes for doing that, but the draft=20 >> hasn't taken off. > [Raju] Right, ejzak draft meant to fill that gap. The plan is to propose = the updated ejzak draft to MMUSIC. Any estimate on when that will happen? It has been "planned" for quite a wh= ile... :) Regards, Christer From nobody Tue Oct 7 06:07:51 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921881A1BFF for ; Tue, 7 Oct 2014 06:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k8fm6dnNN2D for ; Tue, 7 Oct 2014 06:07:45 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBD01A1BFB for ; Tue, 7 Oct 2014 06:07:45 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id E14F21EB8414; Tue, 7 Oct 2014 15:07:43 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 15:07:43 +0200 From: "Stach, Thomas" To: Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] Offer/Answer sections in SDP drafts Thread-Index: AQHP3n6SslbBvuAGmkWAJLrBTe5s5ZwkkRUw Date: Tue, 7 Oct 2014 13:07:43 +0000 Message-ID: References: <542DB3F2.808@cisco.com> In-Reply-To: <542DB3F2.808@cisco.com> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jz_Olgd_eVq5OfGlqi2WAQ20elc Subject: Re: [MMUSIC] Offer/Answer sections in SDP drafts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 13:07:47 -0000 Fleming, my initial thoughts also leaned towards b)=20 However, things got a bit more complex since 3264 and its structure might n= ot be ideal anymore. With stuff like ICE, CapNeg or Bundle the subsequent offers are=20 different from the initial offer although there might be no intent to modif= y the existing session. Nevertheless, some specific procedures might be needed. E.g. ICE needed to deal with resolution of a race condition for the subsequ= ent fix-up offer. The following structure seems more appropriate=20 1 Initial offer/answer exchange=20 1.1. Generating the Initial Offer 1.2. Generating the Answer 1.3. Offerer Processing of the Answer 2. Subsequent offer/answer exchange 2.1. Generating the subsequent Offer 2.2. Generating the subsequent Answer 2.3. Offerer Processing of the subsequent Answer =20 3. Modifying the Session 3.1. Generating the modified Offer 3.2. Generating the Answer 3.3. Offerer Processing of the Answer=20 With this the answer to the question would be " a) Apply to the initial off= er only"=20 The answer to a subsequent offer is most likely the same or very similar as= for the initial offer. In that case 2.2./2.3. could be rather short and point to 1.2./1.3. for mo= st of the procedures. Nevertheless this would give space to cover all peculiarities of subsequent= offer/answer handling=20 and highlights what needs to be different.=20 I can also imagine that you can omit 2. completely, when it is not needed. Similar for the subsections under 3. Kind Regards/mit freundlichen Gr=FC=DFen Thomas Stach > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming > Andreasen > Sent: Donnerstag, 2. Oktober 2014 22:22 > To: mmusic > Subject: [MMUSIC] Offer/Answer sections in SDP drafts >=20 > Greetings >=20 > One of the things we have tried to emphasize for SDP related drafts is > the need to have well-defined offer/answer procedures, and as part of > that, we have been asking people to follow the structure of RFC 3264. > This means there needs to be the following O/A sections in SDP related > drafts (in the order shown): >=20 > 1. Generating the Initial Offer > 2. Generating the Answer > 3. Offerer Processing of the Answer > 4. Modifying the Session >=20 > As part of the bundle-11 draft review, a (general) question came up > around what actually goes in the "Generating the Answer" section. More > specifically, should this section > a) Apply to the initial offer only >=20 > b) Apply to the initial offer and subsequent offers for the parts > that apply in a general manner to both [parts that apply to subsequent > offers only would be covered by "Modifying the Session"] >=20 > c) Apply to all offers. >=20 > I believe the answer is b), however some feel the answer is c). One of > the issues I see with that is that you potentially end up depending on > text/rules from "Modifying the Session", however those procedures have > not been defined at that point in the document. This can of course be > solved with forward referencing (as is done in bundle-11), however it > makes it harder to follow IMO and I also do not believe this is what RFC > 3264 intended. >=20 > Comments on the above would be appreciated. >=20 > Thanks >=20 > -- Flemming >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Oct 7 06:26:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691431A3BA9 for ; Tue, 7 Oct 2014 06:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTZwDR8h8dIS for ; Tue, 7 Oct 2014 06:26:27 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 681651A6EE0 for ; Tue, 7 Oct 2014 06:26:26 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 6B63D23F044F for ; Tue, 7 Oct 2014 15:26:25 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 15:26:25 +0200 From: "Stach, Thomas" To: mmusic Thread-Topic: Text proposal resolving the ICE-"unexpected answer" issue Thread-Index: Ac/iMkpAw0V28GsDRgSeT8v4f4fMBA== Date: Tue, 7 Oct 2014 13:26:24 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E224DF2MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sryoZxZfbPiRXGpE_5mraDdrpj0 Subject: [MMUSIC] Text proposal resolving the ICE-"unexpected answer" issue X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 13:26:29 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E224DF2MCHP04MSXglobal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, at the last MMUSIC session I was asked to provide some text resolving the "= unexpected answer" issue that I brought up on the MMUSIC list. It took a while, but below is what I propose to include in draft-ietf-mmusi= c-ice-sip-sdp. Currently there thee section dealing with the initial SDP offer/answer exch= ange. 3. Sending the Initial Offer 4. Receiving the Initial Offer 5. Receipt of the Initial Answer Now, section 9 deals with subsequent SDP offer/answer exchanges, where the= new text needs to go in. It has subsections (9.1, 9.2) equivalent to 3 and 4 above, however, nothing= equivalent to 5. Thus, I think the existing 9.3 should be moved in new subsection 9.4 and th= e following text should be introduced: 9.3. Receiving the answer for a subsequent offer Some deployments of ICE include e.g. SDP-Modifying Signaling-only B2BUAs [R= FC7092] that modify the SDP body during the subsequent offer/answer exchang= e. With the B2BUA being ICE-unaware a subsequent answer might be manipulate= d and might not include SDP candidates although the initial answer did. An example of a situation where such an "unexpected" answer might be experi= enced appears when such aB2BUA introduces a media server during call hold u= sing 3rd party call-control procedures. Omitting further details how this i= s done this could result in an answer being received at the holding UA that= was constructed by the B2BUA. With the B2BUA being ICE-unaware that answer= would not include SDP candidates. Receiving an answer without ICE attributes in this situation might be unexp= ected, but would not necessarily impair the user experience. In addition to procedures for the expected answer, the following sections g= ive also some advice how to recover from the unexpected situation. 9.3.1 Procedures for All Implementations When receiving an answer within an existing session for a subsequent offer = as specified in 9.1.2.2, an agent MUST verify ICE support as specified in S= ection 5.1. 9.3.1.1 ICE restarts If ICE support is indicated in the SDP answer, the agent MUST perform ICE r= estart procedures as specified in section 9.4 (the existing section 9.3) be= low. If ICE support is no longer indicated in the SDP answer, the agent MUST fal= l-back to RFC 3264 procedures and SHOULD NOT drop the dialog just because o= f missing ICE support. If the agent sends a new offer later on it SHOULD pe= rform an ICE restart as specified in 9.1.1.1. 9.3.1.2 Existing Media Streams with ICE Running If ICE support is indicated in the SDP answer, the agent MUST continue ICE = procedures as specified in section 9.4.1.4 (the existing section 9.3.1.4) b= elow. If ICE support is no longer indicated in the SDP answer, the agent MUST abo= rt the ongoing ICE processing and fall-back to RFC 3264 procedures. The age= nt SHOULD NOT drop the dialog just because of missing ICE support. If the a= gent sends a new offer later on, it SHOULD perform an ICE restart as specif= ied in 9.1.1.1. 9.3.1.3 Existing Media Streams with ICE Completed If ICE support is indicated in the SDP answer and if the answer conforms to= 9.2.2.3, the agent MUST remain in the ICE Completed state. If ICE support is no longer indicated in the SDP answer, the agent MUST fal= l-back to RFC 3264 procedures and SHOULD NOT drop the dialog just because o= f this unexpected answer. Once the agent sends a new offer later on it MUST= perform an ICE restart. Existing 9.3 --> 9.4. Updating the Check and Valid Lists .... I'd like to get your feedback, if that proposal is reasonable. Regards Thomas --_000_F81CEE99482EFE438DAE2A652361EE121E224DF2MCHP04MSXglobal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All,

 

at the last MMUSIC session I was asked to provide so= me text resolving the "unexpected answer" issue that I brought up= on the MMUSIC list.

It took a while, but below is what I propose to incl= ude in draft-ietf-mmusic-ice-sip-sdp.

 

Currently there thee section dealing with the initia= l SDP offer/answer exchange.

3.  Sending the Initial Offer

4.  Receiving the Initial Offer

5.  Receipt of the Initial Answer

Now, section 9 deals with  subsequent SDP offer= /answer exchanges, where the new text needs to go in.

It has subsections (9.1, 9.2) equivalent to 3 and 4 = above, however, nothing equivalent to 5.

Thus, I think the existing 9.3 should be moved in ne= w subsection 9.4 and the following text should be introduced:

 

= 9.3.  Receiving the answer for a subsequent offer

 

Some deployments of ICE include e.g. SDP= -Modifying Signaling-only B2BUAs [RFC7092] that modify the SDP body during = the subsequent offer/answer exchange. With the B2BUA being ICE-unaware a subsequent answer might be manipulated and might not include= SDP candidates although the initial answer did. 

 

An example of a situation where such an = “unexpected” answer might be experienced appears when such aB2B= UA introduces a media server during call hold using 3rd party call-control procedures. Omitting further details how this is done this co= uld result in an answer being received at the holding UA that was construct= ed by the B2BUA. With the B2BUA being ICE-unaware that answer would not inc= lude SDP candidates.  

Receiving an answer without ICE attribut= es in this situation might be unexpected, but would not necessarily impair = the user experience.

In addition to procedures for the expect= ed answer, the following sections give also some advice how to recover from= the unexpected situation.

 

 

9.3.1 Procedures for = All Implementations

When receiving an answer within an exist= ing session for a subsequent offer as specified in 9.1.2.2, an agent MUST v= erify ICE support as specified in Section 5.1.

 

9.3.1.1 ICE restarts

 

If ICE support is indicated in the SDP a= nswer, the agent MUST perform ICE restart procedures as specified in sectio= n 9.4 (the existing section 9.3) below.

 

If ICE support is no longer indicated in= the SDP answer, the agent MUST fall-back to RFC 3264 procedures and SHOULD= NOT drop the dialog just because of missing ICE support. If the agent sends a new offer later on it SHOULD perform an ICE restart a= s specified in 9.1.1.1.

 

9.3.1.2 Existing Media = Streams with ICE Running

 

If ICE support is indicated in the SDP a= nswer, the agent MUST continue ICE procedures as specified in section 9.4.1= .4 (the existing section 9.3.1.4) below.

If ICE support is no longer indicated in= the SDP answer, the agent MUST abort the ongoing ICE processing and fall-b= ack to RFC 3264 procedures. The agent SHOULD NOT drop the dialog just because of missing ICE support. If the agent sends a new offer= later on, it SHOULD perform an ICE restart as specified in 9.1.1.1.

 

9.3.1.3 Existing Media = Streams with ICE Completed

 

If ICE support is indicated in the SDP a= nswer and if the answer conforms to 9.2.2.3, the agent MUST remain in the I= CE Completed state.

 

If ICE support is no longer indicated in= the SDP answer, the agent MUST fall-back to RFC 3264 procedures and SHOULD= NOT drop the dialog just because of this unexpected answer. Once the agent sends a new offer later on it MUST perform an ICE restart. =

 

 

Existing 9.3 =E0 9.4. = Updating the Check and Valid Lists

….

 

I’d like to get your feedback, if  that p= roposal is reasonable.

 

Regards

Thomas

--_000_F81CEE99482EFE438DAE2A652361EE121E224DF2MCHP04MSXglobal_-- From nobody Tue Oct 7 08:36:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5111ACDFE for ; Tue, 7 Oct 2014 08:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjOyKKd7shxd for ; Tue, 7 Oct 2014 08:35:57 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E26A01A6FAA for ; Tue, 7 Oct 2014 08:35:56 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 0C1D223F0533; Tue, 7 Oct 2014 17:35:56 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 17:35:55 +0200 From: "Stach, Thomas" To: Christer Holmberg , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5Kw== Date: Tue, 7 Oct 2014 15:35:55 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E224ECFMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/gkIbjXxeuDr35x_Lsqbv_6D5V-Q Cc: mmusic Subject: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 15:36:02 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E224ECFMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christer, Cullen, Harald, all BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. I can't find text in bundle-11 where the answerer would send its RTCP packe= ts if it accepted BUNDLE, but rejected RTCP-muxing. I see two options: 1. The answerer sends all RTCP packets to the shared RTP-port+1 of the nego= tiated shared address. 2. The answerer sends the RTCP packets to separate ports based on the uniqu= e addresses in the m-lines of the offer? The offerer on the other hand will only receive a shared address. I assume = it then has to send all its RTCP packets to the shared RTP-port+1 of the answerer. Is my understanding correct or am I completely off-track? Supposed I'm correct, then independent from the response, I'm asking if the= re really is a use case for that. In case 1, one would have to demux the RTP streams and RTCP streams from tw= o separate ports instead of a single port. How much implementation effort i= s saved in that case? In case 2 the RTCP handling at offerer and answerer is completely different= . In addition, you still need "a lot" of RTCP ports and take advantage of o= nly half of the BUNDLE benefits. Dr.-Ing. Thomas Stach Unify Austria Systems Engineering & Standardization Dietrichgasse 27 A-1030 Vienna Tel: +43 57008 4377 Fax: +43 570085 4377 mailto:thomas.stach@unify.com --_000_F81CEE99482EFE438DAE2A652361EE121E224ECFMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christer, Cullen, Harald, all

 

BUNDLE can be used separate from RFC5761 RTCP-Multip= lexing.

I can’t find text in bundle-11 where the answe= rer would send its RTCP packets if it accepted BUNDLE, but rejected RTCP-mu= xing.

I see two options:

1. The answerer sends all RTCP packets to the shared= RTP-port+1 of the negotiated shared address.

2. The answerer sends the RTCP packets to separate p= orts based on the unique addresses in the m-lines of the offer?<= /p>

 

The offerer on the other hand will only receive a sh= ared address. I assume it then has to send all its RTCP packets

to the shared RTP-port+1 of the answerer.

 

Is my understanding correct or am I completely off-t= rack?

 

Supposed I’m correct, then independent from th= e response, I’m asking if there really is a use case for that.

In case 1, one would have to demux the RTP streams a= nd RTCP streams from two separate ports instead of a single port. How much = implementation effort is saved in that case?

In case 2 the RTCP handling at offerer and answerer = is completely different. In addition, you still need “a lot“ of= RTCP ports and take advantage of only half of the BUNDLE benefits.

 

Dr.-Ing. Thomas Stach
Unify  Austria
Systems Engineering & Standardization
Dietrichgasse 27
A-1030 Vienna
Tel: +43 57008 4377
Fax: +43 570085 4377
mailto:thomas.stach@unify.com

 

--_000_F81CEE99482EFE438DAE2A652361EE121E224ECFMCHP04MSXglobal_-- From nobody Tue Oct 7 11:34:50 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188551A7113 for ; Tue, 7 Oct 2014 11:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yyQC9eU2GDH for ; Tue, 7 Oct 2014 11:34:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170A51A7026 for ; Tue, 7 Oct 2014 11:34:41 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-46-5434323fb675 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D9.59.02247.F3234345; Tue, 7 Oct 2014 20:34:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 20:34:39 +0200 From: Christer Holmberg To: "Stach, Thomas" , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHg Date: Tue, 7 Oct 2014 18:34:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> References: 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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D46CF08ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvja69kUmIwbHXhhYdk9ksjvV1sVlM Xf6YxeLkzm3MDiweVyZcYfWY8nsjq8eSJT+ZPLb3PGYJYInisklJzcksSy3St0vgytg3+T5r wXTbiobGc8wNjEtMuxg5OSQETCQuTX/GDGGLSVy4t56ti5GLQ0jgKKPE9QcHmSCcxYwSCw+9 Aari4GATsJDo/qcNEhcRaGeU+H/0FCtIN7OAjMSMs41MILawgIPE3APbWEBsEQFHicNvbjBD 2EYSt/s3sIPYLAIqEi9mdoDZvAK+EhfbV4PNERLwk7g1cStYnFPAX+LyJYj5jEDXfT+1hgli l7jErSfzmSCuFpBYsuc81AeiEi8f/2OFsJUkGpc8gbotX+LclEYWiF2CEidnPmGZwCg6C8mo WUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi4tz042M9FKLMpOLi/Pz 9PJSSzYxAuPy4JbfVjsYDz53PMQowMGoxMOr4GkcIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGBtddrQv//pDcGkPnzXXjYznLScSwx6evjPvqvWyI8eX LfFNPG3pU7Tqqch7waA1ZRsuJcx13JqUd7Fb3XuWQN/6qLOT6o/M7WI0aXSM5LxYv2hlLcOr KaoV2gbl1boTXi4Of/rmyqaIH3XsYvOeX5nyZ5bRnRm7Ds02PBszNeLsr5+hemu3V39SYinO SDTUYi4qTgQAQGocs6wCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/g7RAUaDl40h3obvmBR8Crkr-Y3o Cc: mmusic Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2014 18:34:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D46CF08ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, >BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. >I can't find text in bundle-11 where the answerer would send its RTCP pack= ets if it accepted BUNDLE, but rejected RTCP-muxing. >I see two options: >1. The answerer sends all RTCP packets to the shared RTP-port+1 of the neg= otiated shared address. >2. The answerer sends the RTCP packets to separate ports based on the uniq= ue addresses in the m-lines of the offer? Alternative 1) is correct. I guess we could add some text to clarify that. >The offerer on the other hand will only receive a shared address. I assume= it then has to send all its RTCP packets >to the shared RTP-port+1 of the answerer. Yes. >Is my understanding correct or am I completely off-track? Assuming my understanding is correct, your understanding is correct :) >Supposed I'm correct, then independent from the response, I'm asking if th= ere really is a use case for that. >In case 1, one would have to demux the RTP streams and RTCP streams from t= wo separate ports instead of a single port. How much implementation effort = >is saved in that case? I am not sure what you mean. Are you asking how much implementation effort = is saved if you don't have to de-mux RTP and RTCP? >In case 2 the RTCP handling at offerer and answerer is completely differen= t. In addition, you still need "a lot" of RTCP ports and take advantage of = only half >of the BUNDLE benefits. Correct. But, case 2 is not applicable (unless the endpoints choose not to = use BUNDLE to begin with, that is...). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D46CF08ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Thomas,

 

>BUNDLE can be used separate= from RFC5761 RTCP-Multiplexing.

>I can’t find text in = bundle-11 where the answerer would send its RTCP packets if it accepted BUN= DLE, but rejected RTCP-muxing.

>I see two options:

>1. The answerer sends all R= TCP packets to the shared RTP-port+1 of the negotiated shared address.<= o:p>

>2. The answerer sends the R= TCP packets to separate ports based on the unique addresses in the m-lines = of the offer?

 

Alternative 1) is correct. I gu= ess we could add some text to clarify that.

 

>The offerer on the other ha= nd will only receive a shared address. I assume it then has to send all its= RTCP packets

>to the shared RTP-port+= 1 of the answerer.

 

Yes.

 

>Is my understanding correct= or am I completely off-track?

 

Assuming my understanding is co= rrect, your understanding is correct :)

 

>Supposed I’m correct,= then independent from the response, I’m asking if there really is a = use case for that.

>In case 1, one would have t= o demux the RTP streams and RTCP streams from two separate ports instead of= a single port. How much implementation effort >is saved in that case?

 

I am not sure what you mean. Ar= e you asking how much implementation effort is saved if you don’t hav= e to de-mux RTP and RTCP?

 

>In case 2 the RTCP handling= at offerer and answerer is completely different. In addition, you still ne= ed “a lot“ of RTCP ports and take advantage of only half >of= the BUNDLE benefits.

 

Correct. But, case 2 is not app= licable (unless the endpoints choose not to use BUNDLE to begin with, that = is…).

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D46CF08ESESSMB209erics_-- From nobody Wed Oct 8 03:06:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F481A0171 for ; Wed, 8 Oct 2014 03:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 244Lu6pxXFyL for ; Wed, 8 Oct 2014 03:06:31 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0B03C1A0178 for ; Wed, 8 Oct 2014 03:06:27 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 81F691EB8538; Wed, 8 Oct 2014 12:06:26 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 12:06:26 +0200 From: "Stach, Thomas" To: Christer Holmberg , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHgABwyUoA= Date: Wed, 8 Oct 2014 10:06:25 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E227C60MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/F84mV3qe7M5nUVoM4A6qveAlYqk Cc: mmusic Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 10:06:35 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E227C60MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christer, From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 7. Oktober 2014 20:35 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, >BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. >I can't find text in bundle-11 where the answerer would send its RTCP pack= ets if it accepted BUNDLE, but rejected RTCP-muxing. >I see two options: >1. The answerer sends all RTCP packets to the shared RTP-port+1 of the neg= otiated shared address. >2. The answerer sends the RTCP packets to separate ports based on the uniq= ue addresses in the m-lines of the offer? Alternative 1) is correct. I guess we could add some text to clarify that. [TS] Yes, please. The current text is not sufficiently clear. >The offerer on the other hand will only receive a shared address. I assume= it then has to send all its RTCP packets >to the shared RTP-port+1 of the answerer. Yes. >Is my understanding correct or am I completely off-track? Assuming my understanding is correct, your understanding is correct :) >Supposed I'm correct, then independent from the response, I'm asking if th= ere really is a use case for that. >In case 1, one would have to demux the RTP streams and RTCP streams from t= wo separate ports instead of a single port. How much implementation effort = >is saved in that case? I am not sure what you mean. Are you asking how much implementation effort = is saved if you don't have to de-mux RTP and RTCP? [TS] Yes. I was questioning myself what benefit there is in not mandating = RTCP-mux. In the meantime I looked up again the discussion on "Q14" that led to havin= g rtcp-mux optional. I agree with the outcome. Thanks! >In case 2 the RTCP handling at offerer and answerer is completely differen= t. In addition, you still need "a lot" of RTCP ports and take advantage of = only half >of the BUNDLE benefits. Correct. But, case 2 is not applicable (unless the endpoints choose not to = use BUNDLE to begin with, that is...). Regards, Christer --_000_F81CEE99482EFE438DAE2A652361EE121E227C60MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Christer,

 

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thom= as,

 

>BUNDLE can be used separate from RFC5761 RTCP-Mu= ltiplexing.

>I can’t find text in bundle-11 where the a= nswerer would send its RTCP packets if it accepted BUNDLE, but rejected RTC= P-muxing.

>I see two options:

>1. The answerer sends all RTCP packets to the sh= ared RTP-port+1 of the negotiated shared address.

>2. The answerer sends the RTCP packets to separa= te ports based on the unique addresses in the m-lines of the offer?

 

Alternative 1) is correct. I guess we could add some= text to clarify that.

[TS] Yes, please= . The current text is not sufficiently clear.

 

>The offerer on the other hand will only receive = a shared address. I assume it then has to send all its RTCP packets

>to the shared RTP-port+1 of the answerer.

 

Yes.

 

>Is my understanding correct or am I completely o= ff-track?

 

Assuming my understanding is correct, your understan= ding is correct :)

 

>Supposed I’m correct, then independent fro= m the response, I’m asking if there really is a use case for that.

>In case 1, one would have to demux the RTP strea= ms and RTCP streams from two separate ports instead of a single port. How m= uch implementation effort >is saved in that case?

 

I am not sure what you mean. Are you asking how much= implementation effort is saved if you don’t have to de-mux RTP and R= TCP?

[TS] Yes.  = I was questioning myself what benefit there is in not mandating RTCP-mux.

In the meantime = I looked up again the discussion on “Q14“ that led to having rt= cp-mux optional. I agree with the outcome.

Thanks!

 

>In case 2 the RTCP handling at offerer and answe= rer is completely different. In addition, you still need “a lot“= ; of RTCP ports and take advantage of only half >of the BUNDLE benefits.=

 

Correct. But, case 2 is not applicable (unless the e= ndpoints choose not to use BUNDLE to begin with, that is…).

 

Regards,

 

Christer

 

--_000_F81CEE99482EFE438DAE2A652361EE121E227C60MCHP04MSXglobal_-- From nobody Wed Oct 8 04:36:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9DC1A02E3 for ; Wed, 8 Oct 2014 04:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moCe_fDu31gI for ; Wed, 8 Oct 2014 04:36:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EAC1A02DA for ; Wed, 8 Oct 2014 04:36:37 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-e3-543521c2de3d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.7F.02247.2C125345; Wed, 8 Oct 2014 13:36:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Wed, 8 Oct 2014 13:36:34 +0200 From: Christer Holmberg To: "Stach, Thomas" , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHgABwyUoAABzpZoA== Date: Wed, 8 Oct 2014 11:36:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46E6EF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D46E6EFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM+Jvje5hRdMQgytXOSw6JrNZHOvrYrOY uvwxi8XJnduYHVg8rky4wuox5fdGVo8lS34yeWzvecwSwBLFZZOSmpNZllqkb5fAlXHx0AXm gilTGCu+3znD0sA4sZGxi5GTQ0LAROJZ32wWCFtM4sK99WxdjFwcQgJHGSVenf7NBOEsZpSY 2nWLuYuRg4NNwEKi+582SFxEoJ1R4v/RU6wg3cwCMhIzzjYygdjCAg4Scw9sA5sqIuAocfjN DbBeEQEniXMvvUHCLAIqEg8XLwMr4RXwleh5PZ0FYtd1Ronl1y6ygyQ4Bfwl9sw4CHYpI9B1 30+tYYLYJS5x68l8JoirBSSW7DnPDGGLSrx8/I8VwlaU2Hm2nRmiPl/i9NWdUMsEJU7OfMIy gVF0FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFhfnphsZ6aUW ZSYXF+fn6eWllmxiBMbmwS2/rXYwHnzueIhRgINRiYd3wSyTECHWxLLiytxDjNIcLErivAvP zQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMi6Jimr/qSj6BsbhgunLmb9VL9xPTE5z0Ne Ijk2qa3wou6NW5fWzHp+a+qStpN6vuevzNY/Yqj5aWlhtaFOj25U0VnxpE8flKV3u3DGaR6/ dIxp6aPGJw73ruYkRRdvYpD3bmC4cE3+1VzZP7/lDgcn71DYcNRe1FLOWmSv/rysBtXHZyoS Q5RYijMSDbWYi4oTAZMB53WuAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZfAZ0HXlTeJRMlQmuYdoU4D6V_E Cc: mmusic Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 11:36:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D46E6EFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, I suggest something like this: In section 10.3.2.3: OLD TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer." NEW TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer. The ans= werer will, based on the port number of the selected offerer BUNDLE add= ress, use the next higher (odd) destination port number [RFC3550]= for sending RTCP packets associated with a bundled "m=3D" line towards the offerer," In section 10.3.2.4: OLD TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP." NEW TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP. The answerer will, based on the port number of th= e answerer BUNDLE address, use the next higher (odd) destination port number [RFC3550] for sending RTCP packets associated with a bundled "m=3D" line towards the answerer." Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 8. lokakuuta 2014 13:06 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Christer, From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 7. Oktober 2014 20:35 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, >BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. >I can't find text in bundle-11 where the answerer would send its RTCP pack= ets if it accepted BUNDLE, but rejected RTCP-muxing. >I see two options: >1. The answerer sends all RTCP packets to the shared RTP-port+1 of the neg= otiated shared address. >2. The answerer sends the RTCP packets to separate ports based on the uniq= ue addresses in the m-lines of the offer? Alternative 1) is correct. I guess we could add some text to clarify that. [TS] Yes, please. The current text is not sufficiently clear. >The offerer on the other hand will only receive a shared address. I assume= it then has to send all its RTCP packets >to the shared RTP-port+1 of the answerer. Yes. >Is my understanding correct or am I completely off-track? Assuming my understanding is correct, your understanding is correct :) >Supposed I'm correct, then independent from the response, I'm asking if th= ere really is a use case for that. >In case 1, one would have to demux the RTP streams and RTCP streams from t= wo separate ports instead of a single port. How much implementation effort = >is saved in that case? I am not sure what you mean. Are you asking how much implementation effort = is saved if you don't have to de-mux RTP and RTCP? [TS] Yes. I was questioning myself what benefit there is in not mandating = RTCP-mux. In the meantime I looked up again the discussion on "Q14" that led to havin= g rtcp-mux optional. I agree with the outcome. Thanks! >In case 2 the RTCP handling at offerer and answerer is completely differen= t. In addition, you still need "a lot" of RTCP ports and take advantage of = only half >of the BUNDLE benefits. Correct. But, case 2 is not applicable (unless the endpoints choose not to = use BUNDLE to begin with, that is...). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D46E6EFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Thomas,<= /span>

 

I suggest something li= ke this:

 

In section 10.3.2.3:

 

OLD TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within= the

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer.”=

 

NEW TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within= the

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer. The answerer will,<= /o:p>

   &nbs= p;            based = on the port number of the selected offerer BUNDLE address,

   &nbs= p;            use th= e next higher (odd) destination port number [RFC3550] for

sending RTCP packets associated with a bundled “m=3D” li= ne towards

the offerer,”

 

 

In section 10.3.2.4:

 

OLD TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP.&#= 8221;

 

NEW TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP. T= he answerer will, based on the port number of the answerer

BUNDLE address, use the next higher (odd) destination port number [R= FC3550]

for sending RTCP packets associated with a bundled “m=3D”= ; line towards the

answerer.”

 

Regards,

 

Christer

 

 

 

 

From: Stach, T= homas [mailto:thomas.stach@unify.com]
Sent: 8. lokakuuta 2014 13:06
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

 

Christer,

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thom= as,

 

>BUNDLE can be used separate from RFC5761 RTCP-Mu= ltiplexing.

>I can’t find text in bundle-11 where the a= nswerer would send its RTCP packets if it accepted BUNDLE, but rejected RTC= P-muxing.

>I see two options:

>1. The answerer sends all RTCP packets to the sh= ared RTP-port+1 of the negotiated shared address.

>2. The answerer sends the RTCP packets to separa= te ports based on the unique addresses in the m-lines of the offer?

 

Alternative 1) is correct. I guess we could add some= text to clarify that.

[TS] Yes, please= . The current text is not sufficiently clear.

 

>The offerer on the other hand will only receive = a shared address. I assume it then has to send all its RTCP packets

>to the shared RTP-port+1 of the answerer.

 

Yes.

 

>Is my understanding correct or am I completely o= ff-track?

 

Assuming my understanding is correct, your understan= ding is correct :)

 

>Supposed I’m correct, then independent fro= m the response, I’m asking if there really is a use case for that.

>In case 1, one would have to demux the RTP strea= ms and RTCP streams from two separate ports instead of a single port. How m= uch implementation effort >is saved in that case?

 

I am not sure what you mean. Are you asking how much= implementation effort is saved if you don’t have to de-mux RTP and R= TCP?

[TS] Yes.  = I was questioning myself what benefit there is in not mandating RTCP-mux.

In the meantime = I looked up again the discussion on “Q14“ that led to having rt= cp-mux optional. I agree with the outcome.

Thanks!

 

>In case 2 the RTCP handling at offerer and answe= rer is completely different. In addition, you still need “a lot“= ; of RTCP ports and take advantage of only half >of the BUNDLE benefits.=

 

Correct. But, case 2 is not applicable (unless the e= ndpoints choose not to use BUNDLE to begin with, that is…).

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D46E6EFESESSMB209erics_-- From nobody Wed Oct 8 06:21:05 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BE51A1A39 for ; Wed, 8 Oct 2014 06:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt09tEzJ0Eby for ; Wed, 8 Oct 2014 06:20:59 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2771A1A42 for ; Wed, 8 Oct 2014 06:20:57 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id ED2DF1EB8494; Wed, 8 Oct 2014 15:20:55 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 15:20:55 +0200 From: "Stach, Thomas" To: Christer Holmberg , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHgABwyUoAABzpZoAADjPnA Date: Wed, 8 Oct 2014 13:20:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D46E6EF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D46E6EF@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E227D6DMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/B6Qu2F_UjIz6u8XxPdnV5EzwQdU Cc: mmusic Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 13:21:03 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E227D6DMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable inline From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Mittwoch, 8. Oktober 2014 13:37 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, I suggest something like this: In section 10.3.2.3: OLD TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer." NEW TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer. The ans= werer will, based on the port number of the selected offerer BUNDLE add= ress, use the next higher (odd) destination port number [RFC3550]= for sending RTCP packets associated with a bundled "m=3D" line towards the offerer," [TS] I'd like to add something for receiving RCTP. With a slight re-wording= the new text would be If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=3D" line in the answer. Based on the port number of the selected offerer BUNDLE address, the answerer will send RTCP packets associated with any bundled "m=3D" lin= e to the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the answerer will receive RTCP packets associated with any bundled "m=3D" = line at the next higher (odd) destination port [RFC3550]. This means that the associated RTCP streams for bundled "m=3D" lines are bundled at the next higher (odd) destination port In section 10.3.2.4: OLD TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP." NEW TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP. The answerer will, based on the port number of th= e answerer BUNDLE address, use the next higher (odd) destination port number [RFC3550] for sending RTCP packets associated with a bundled "m=3D" line towards the answerer." [TS] Similar here If the answerer does not accept the usage of RTP/RTCP multiplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP and RTCP. Based on the port number of the selected offerer BUNDLE address, the offerer will receive RTCP packets associated with any bundled "m=3D" l= ine at the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the offerer will send RTCP packets associated with any bundled "m=3D" line to the next higher (odd) destination port [RFC3550]. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 8. lokakuuta 2014 13:06 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Christer, From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 7. Oktober 2014 20:35 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, >BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. >I can't find text in bundle-11 where the answerer would send its RTCP pack= ets if it accepted BUNDLE, but rejected RTCP-muxing. >I see two options: >1. The answerer sends all RTCP packets to the shared RTP-port+1 of the neg= otiated shared address. >2. The answerer sends the RTCP packets to separate ports based on the uniq= ue addresses in the m-lines of the offer? Alternative 1) is correct. I guess we could add some text to clarify that. [TS] Yes, please. The current text is not sufficiently clear. >The offerer on the other hand will only receive a shared address. I assume= it then has to send all its RTCP packets >to the shared RTP-port+1 of the answerer. Yes. >Is my understanding correct or am I completely off-track? Assuming my understanding is correct, your understanding is correct :) >Supposed I'm correct, then independent from the response, I'm asking if th= ere really is a use case for that. >In case 1, one would have to demux the RTP streams and RTCP streams from t= wo separate ports instead of a single port. How much implementation effort = >is saved in that case? I am not sure what you mean. Are you asking how much implementation effort = is saved if you don't have to de-mux RTP and RTCP? [TS] Yes. I was questioning myself what benefit there is in not mandating = RTCP-mux. In the meantime I looked up again the discussion on "Q14" that led to havin= g rtcp-mux optional. I agree with the outcome. Thanks! >In case 2 the RTCP handling at offerer and answerer is completely differen= t. In addition, you still need "a lot" of RTCP ports and take advantage of = only half >of the BUNDLE benefits. Correct. But, case 2 is not applicable (unless the endpoints choose not to = use BUNDLE to begin with, that is...). Regards, Christer --_000_F81CEE99482EFE438DAE2A652361EE121E227D6DMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

inline

 

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Mittwoch, 8. Oktober 2014 13:37
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thomas,<= /span>

 

I suggest something li= ke this:

 

In section 10.3.2.3:

 

OLD TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within t= he

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer.”=

 

NEW TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within t= he

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer. The answerer will,<= /o:p>

   &nbs= p;            based = on the port number of the selected offerer BUNDLE address,

   &nbs= p;            use th= e next higher (odd) destination port number [RFC3550] for

sending RTCP packets associated with a bundled “m=3D” line= towards

the offerer,”

[TS] I’d l= ike to add something for receiving RCTP. With a slight re-wording the new t= ext would be

If the answerer rejects usag= e of RTP/RTCP multiplexing within the

BUNDLE group, it MUST NOT as= sign an SDP 'rtcp-mux' or SDP 'rtcp'

attribute to any bundled "m=3D" line in the ans= wer.

 Based on the port number of the selected offerer BU= NDLE address,

 the answerer will send RTCP packets associated with= any bundled “m=3D” line

 to the next higher (odd) destination port [RFC3550]= .

 Based on the port number of the selected answerer B= UNDLE address,

 the answerer will receive RTCP packets associated w= ith any bundled “m=3D” line

 at the next higher (odd) destination port [RFC3550]= .

This means that the associated RTCP streams for bundled &= #8220;m=3D” lines

 are bundled at the next higher (odd) destination po= rt

 

 

In section 10.3.2.4:

 

OLD TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP.&#= 8221;

 

NEW TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP. T= he answerer will, based on the port number of the answerer

BUNDLE address, use the next higher (odd) destination port number [RFC= 3550]

for sending RTCP packets associated with a bundled “m=3D” = line towards the

answerer.”

 

[TS] Similar her= e

If the answerer does not acc= ept the usage of RTP/RTCP multiplexing

[Section 10.3.2.3], the offe= rer MUST use separate 5-tuples for RTP

and RTCP.=

Based on the port number of the selected offerer BUNDLE a= ddress,

 the offerer will receive RTCP packets associated wi= th any bundled “m=3D” line

 at the next higher (odd) destination port [RFC3550]= .

 Based on the port number of the selected answerer B= UNDLE address,

 the offerer will send RTCP packets associated with = any bundled “m=3D” line

 to the next higher (odd) destination port [RFC3550]= .

 

 

Regards,

 

Christer

 

 

 

 

From: Stach, T= homas [mailto:thomas.stach@unify.= com]
Sent: 8. lokakuuta 2014 13:06
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

 

Christer,

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thom= as,

 

>BUNDLE can be used separate from RFC5761 RTCP-Mu= ltiplexing.

>I can’t find text in bundle-11 where the a= nswerer would send its RTCP packets if it accepted BUNDLE, but rejected RTC= P-muxing.

>I see two options:

>1. The answerer sends all RTCP packets to the sh= ared RTP-port+1 of the negotiated shared address.

>2. The answerer sends the RTCP packets to separa= te ports based on the unique addresses in the m-lines of the offer?

 

Alternative 1) is correct. I guess we could add some= text to clarify that.

[TS] Yes, please= . The current text is not sufficiently clear.

 

>The offerer on the other hand will only receive = a shared address. I assume it then has to send all its RTCP packets

>to the shared RTP-port+1 of the answerer.

 

Yes.

 

>Is my understanding correct or am I completely o= ff-track?

 

Assuming my understanding is correct, your understan= ding is correct :)

 

>Supposed I’m correct, then independent fro= m the response, I’m asking if there really is a use case for that.

>In case 1, one would have to demux the RTP strea= ms and RTCP streams from two separate ports instead of a single port. How m= uch implementation effort >is saved in that case?

 

I am not sure what you mean. Are you asking how much= implementation effort is saved if you don’t have to de-mux RTP and R= TCP?

[TS] Yes.  = I was questioning myself what benefit there is in not mandating RTCP-mux.

In the meantime = I looked up again the discussion on “Q14“ that led to having rt= cp-mux optional. I agree with the outcome.

Thanks!

 

>In case 2 the RTCP handling at offerer and answe= rer is completely different. In addition, you still need “a lot“= ; of RTCP ports and take advantage of only half >of the BUNDLE benefits.=

 

Correct. But, case 2 is not applicable (unless the e= ndpoints choose not to use BUNDLE to begin with, that is…).

 

Regards,

 

Christer

 

--_000_F81CEE99482EFE438DAE2A652361EE121E227D6DMCHP04MSXglobal_-- From nobody Wed Oct 8 12:06:05 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF43E1A0451 for ; Wed, 8 Oct 2014 12:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYQgtVSMtO5d for ; Wed, 8 Oct 2014 12:05:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D491A0372 for ; Wed, 8 Oct 2014 12:05:57 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-71-54358b1224f6 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.21.02247.21B85345; Wed, 8 Oct 2014 21:05:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Wed, 8 Oct 2014 21:05:51 +0200 From: Christer Holmberg To: "Stach, Thomas" , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHgABwyUoAABzpZoAADjPnAAAyQalA= Date: Wed, 8 Oct 2014 19:05:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D46EFC7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D46E6EF@ESESSMB209.ericsson.se> 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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D46EFC7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7nK5Qt2mIQfstA4uOyWwWx/q62Cym Ln/MYnFy5zZmBxaPKxOusHpM+b2R1WPJkp9MHtt7HrMEsERx2aSk5mSWpRbp2yVwZXyZt4Sp 4OEHxorHqx4zNTC+vMzYxcjJISFgItG3rp8dwhaTuHBvPVsXIxeHkMARRom/V9azQjiLGSW+ /t3H0sXIwcEmYCHR/U8bJC4i0M4o8f/oKVaQbmYBGYkZZxuZQGxhAQeJuQe2sYDYIgKOEoff 3GCGsP0k3m1dDlbDIqAisW3SSTCbV8BX4sD1m1CbHzBJXO/9wwqyjFPAX2L+kViQGkag676f WsMEsUtc4taT+UwQVwtILNlznhnCFpV4+fgfK4StJLH28HYWiPp8iQPnm9ghdglKnJz5hGUC o+gsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tLs5NNzLSSy3K TC4uzs/Ty0st2cQIjM2DW35b7WA8+NzxEKMAB6MSD++CWSYhQqyJZcWVuYcYpTlYlMR5F56b FywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsdjqp+Sv481n7dmCQ5MuyMSwzn/KH1CR77XA 0UnaZFXyyZDJggJeKsH3S5Mva6gVJh3I4da36BQ4Ha06/+3LwCs1Mh//Xl1i9vSo3kGfStUl W3pmdvT2/l1ke+u5kZetqJrpLkWtEOXU3qWb3vzMU1JLP/iHyWfG7/ib1T98Mgvs7lddvfJM iaU4I9FQi7moOBEA6USCfq4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/X3KgtAuXedRlLR1lrhjEWE_HIBg Cc: mmusic Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 08 Oct 2014 19:06:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D46EFC7ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Do we really need text for both sending and receiving? If we say that an entity sends something towards port X, I think it is obvi= ous that the other endpoint will listen on port X. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 08 October 2014 16:21 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected inline From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Mittwoch, 8. Oktober 2014 13:37 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, I suggest something like this: In section 10.3.2.3: OLD TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer." NEW TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer. The ans= werer will, based on the port number of the selected offerer BUNDLE add= ress, use the next higher (odd) destination port number [RFC3550]= for sending RTCP packets associated with a bundled "m=3D" line towards the offerer," [TS] I'd like to add something for receiving RCTP. With a slight re-wording= the new text would be If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=3D" line in the answer. Based on the port number of the selected offerer BUNDLE address, the answerer will send RTCP packets associated with any bundled "m=3D" lin= e to the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the answerer will receive RTCP packets associated with any bundled "m=3D" = line at the next higher (odd) destination port [RFC3550]. This means that the associated RTCP streams for bundled "m=3D" lines are bundled at the next higher (odd) destination port In section 10.3.2.4: OLD TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP." NEW TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP. The answerer will, based on the port number of th= e answerer BUNDLE address, use the next higher (odd) destination port number [RFC3550] for sending RTCP packets associated with a bundled "m=3D" line towards the answerer." [TS] Similar here If the answerer does not accept the usage of RTP/RTCP multiplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP and RTCP. Based on the port number of the selected offerer BUNDLE address, the offerer will receive RTCP packets associated with any bundled "m=3D" l= ine at the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the offerer will send RTCP packets associated with any bundled "m=3D" line to the next higher (odd) destination port [RFC3550]. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 8. lokakuuta 2014 13:06 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Christer, From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 7. Oktober 2014 20:35 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, >BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. >I can't find text in bundle-11 where the answerer would send its RTCP pack= ets if it accepted BUNDLE, but rejected RTCP-muxing. >I see two options: >1. The answerer sends all RTCP packets to the shared RTP-port+1 of the neg= otiated shared address. >2. The answerer sends the RTCP packets to separate ports based on the uniq= ue addresses in the m-lines of the offer? Alternative 1) is correct. I guess we could add some text to clarify that. [TS] Yes, please. The current text is not sufficiently clear. >The offerer on the other hand will only receive a shared address. I assume= it then has to send all its RTCP packets >to the shared RTP-port+1 of the answerer. Yes. >Is my understanding correct or am I completely off-track? Assuming my understanding is correct, your understanding is correct :) >Supposed I'm correct, then independent from the response, I'm asking if th= ere really is a use case for that. >In case 1, one would have to demux the RTP streams and RTCP streams from t= wo separate ports instead of a single port. How much implementation effort = >is saved in that case? I am not sure what you mean. Are you asking how much implementation effort = is saved if you don't have to de-mux RTP and RTCP? [TS] Yes. I was questioning myself what benefit there is in not mandating = RTCP-mux. In the meantime I looked up again the discussion on "Q14" that led to havin= g rtcp-mux optional. I agree with the outcome. Thanks! >In case 2 the RTCP handling at offerer and answerer is completely differen= t. In addition, you still need "a lot" of RTCP ports and take advantage of = only half >of the BUNDLE benefits. Correct. But, case 2 is not applicable (unless the endpoints choose not to = use BUNDLE to begin with, that is...). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D46EFC7ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Do we really need text for both sending and receiving?

 

If we say that an entity sends something towards port X, I think it is= obvious that the other endpoint will listen on port X.

 

Regards,

 

Christer

 

From: Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: 08 October 2014 16:21
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

inline

&n= bsp;

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Mittwoch, 8. Oktober 2014 13:37
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thom= as,

&n= bsp;

I sugge= st something like this:

&n= bsp;

In sect= ion 10.3.2.3:

&n= bsp;

OLD TEX= T:

&n= bsp;

“If the answerer rejects usage of RTP/RTCP mult= iplexing within the

 &= nbsp;            &nb= sp; BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

 &= nbsp;            &nb= sp; attribute to any bundled "m=3D" line in the answer.”

&n= bsp;

NEW TEX= T:

&n= bsp;

“If the answerer rejects usage of RTP/RTCP mult= iplexing within the

 &= nbsp;            &nb= sp; BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

 &= nbsp;            &nb= sp; attribute to any bundled "m=3D" line in the answer. The answe= rer will,

 &= nbsp;           &nbs= p;  based on the port number of the selected offerer BUNDLE address,

 &= nbsp;           &nbs= p;  use the next higher (odd) destination port number [RFC3550] for

sending RTCP packets associated with a bundled “= ;m=3D” line towards

the offerer,”

[= TS] I’d like to add something for receiving RCTP. With a slight re-wo= rding the new text would be

If the answerer rejects usage o= f RTP/RTCP multiplexing within the

BUNDLE group, it MUST NOT assig= n an SDP 'rtcp-mux' or SDP 'rtcp'

attribute to any bundled "m=3D" line in the answer= .

 Based on the port number of the selected offerer BUNDL= E address,

 the answerer will send RTCP packets associated with an= y bundled “m=3D” line

 to the next higher (odd) destination port [RFC3550].

 Based on the port number of the selected answerer BUND= LE address,

 the answerer will receive RTCP packets associated with= any bundled “m=3D” line

 at the next higher (odd) destination port [RFC3550].

This means that the associated RTCP streams for bundled R= 20;m=3D” lines

 are bundled at the next higher (odd) destination port<= span style=3D"color:#1F497D">

 

&n= bsp;

In sect= ion 10.3.2.4:

&n= bsp;

OLD TEX= T:

&n= bsp;

 &= nbsp;           &nbs= p;  “If the answerer does not accept the usage of RTP/RTCP multi= plexing

 &= nbsp;            &nb= sp; [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP=

 &= nbsp;            &nb= sp; and RTCP.”

&n= bsp;

NEW TEX= T:

&n= bsp;

 &= nbsp;           &nbs= p;  “If the answerer does not accept the usage of RTP/RTCP multi= plexing

 &= nbsp;            &nb= sp; [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP=

 &= nbsp;            &nb= sp; and RTCP. The answerer will, based on the port number of the answerer

BUNDLE address, use the next higher (odd) destination= port number [RFC3550]

for sending RTCP packets associated with a bundled &#= 8220;m=3D” line towards the

answerer.”

&n= bsp;

[= TS] Similar here

If the answerer does not accept= the usage of RTP/RTCP multiplexing

[Section 10.3.2.3], the offerer= MUST use separate 5-tuples for RTP

and RTCP.

Based on the port number of the selected offerer BUNDLE addr= ess,

 the offerer will receive RTCP packets associated with = any bundled “m=3D” line

 at the next higher (odd) destination port [RFC3550].

 Based on the port number of the selected answerer BUND= LE address,

 the offerer will send RTCP packets associated with any= bundled “m=3D” line

 to the next higher (odd) destination port [RFC3550].

 

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From: Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: 8. lokakuuta 2014 13:06
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

&n= bsp;

Christe= r,

&n= bsp;

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thomas,<= /span>

 

>BUNDLE can be used separate= from RFC5761 RTCP-Multiplexing.

>I can’t find text in = bundle-11 where the answerer would send its RTCP packets if it accepted BUN= DLE, but rejected RTCP-muxing.

>I see two options:

>1. The answerer sends all R= TCP packets to the shared RTP-port+1 of the negotiated shared address.<= o:p>

>2. The answerer sends the R= TCP packets to separate ports based on the unique addresses in the m-lines = of the offer?

 

Alternative 1) is correct. I gu= ess we could add some text to clarify that.

[= TS] Yes, please. The current text is not sufficiently clear.=

 

>The offerer on the other ha= nd will only receive a shared address. I assume it then has to send all its= RTCP packets

>to the shared RTP-port+= 1 of the answerer.

 

Yes.

 

>Is my understanding correct= or am I completely off-track?

 

Assuming my understanding is co= rrect, your understanding is correct :)

 

>Supposed I’m correct,= then independent from the response, I’m asking if there really is a = use case for that.

>In case 1, one would have t= o demux the RTP streams and RTCP streams from two separate ports instead of= a single port. How much implementation effort >is saved in that case?

 

I am not sure what you mean. Ar= e you asking how much implementation effort is saved if you don’t hav= e to de-mux RTP and RTCP?

[= TS] Yes.  I was questioning myself what benefit there is in not mandat= ing RTCP-mux.

I= n the meantime I looked up again the discussion on “Q14“ that l= ed to having rtcp-mux optional. I agree with the outcome.=

T= hanks!

 

>In case 2 the RTCP handling= at offerer and answerer is completely different. In addition, you still ne= ed “a lot“ of RTCP ports and take advantage of only half >of= the BUNDLE benefits.

 

Correct. But, case 2 is not app= licable (unless the endpoints choose not to use BUNDLE to begin with, that = is…).

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D46EFC7ESESSMB209erics_-- From nobody Thu Oct 9 06:08:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DDA1ACED1 for ; Thu, 9 Oct 2014 06:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWu2Kh9Ht63J for ; Thu, 9 Oct 2014 06:08:34 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6821ACE55 for ; Thu, 9 Oct 2014 06:05:01 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id D4C0123F04BE; Thu, 9 Oct 2014 15:04:59 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 15:04:59 +0200 From: "Stach, Thomas" To: Christer Holmberg , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHgABwyUoAABzpZoAADjPnAAAyQalAAJauvUA== Date: Thu, 9 Oct 2014 13:04:58 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D46E6EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D46EFC7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D46EFC7@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E229112MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/29lunMM2diz-yGka3Wa-yvgnzNM Cc: mmusic Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 13:08:42 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E229112MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, of course you are right that parts the proposed text is somewhat redundant = and I would not insist on having the longer text. It's just that things that appear obvious to some are not always clear to o= thers. I would leave the decision up to you. Independent from that, there are throughout the document quite a few other = occurrences of redundant text that could be scrutinized for necessity as we= ll. E.g. in 8.2 The generic rules and procedures defined in [RFC3264] and [RFC5888] also apply to the BUNDLE extension. For example, if an offer is rejected by the answerer, the previously negotiated SDP parameters and characteristics (including those associated with a BUNDLE group) apply. Hence, if an offerer generates an offer in which the offerer wants to create a BUNDLE group, and the answerer rejects the offer, the BUNDLE group is not created. The first sentence is probably ok, but the remainder just repeats 3264/5888= . I could point you to other such examples if you want me to. Regards Thomas From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Mittwoch, 8. Oktober 2014 21:06 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi, Do we really need text for both sending and receiving? If we say that an entity sends something towards port X, I think it is obvi= ous that the other endpoint will listen on port X. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 08 October 2014 16:21 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected inline From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Mittwoch, 8. Oktober 2014 13:37 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, I suggest something like this: In section 10.3.2.3: OLD TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer." NEW TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer. The ans= werer will, based on the port number of the selected offerer BUNDLE add= ress, use the next higher (odd) destination port number [RFC3550]= for sending RTCP packets associated with a bundled "m=3D" line towards the offerer," [TS] I'd like to add something for receiving RCTP. With a slight re-wording= the new text would be If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=3D" line in the answer. Based on the port number of the selected offerer BUNDLE address, the answerer will send RTCP packets associated with any bundled "m=3D" lin= e to the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the answerer will receive RTCP packets associated with any bundled "m=3D" = line at the next higher (odd) destination port [RFC3550]. This means that the associated RTCP streams for bundled "m=3D" lines are bundled at the next higher (odd) destination port In section 10.3.2.4: OLD TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP." NEW TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP. The answerer will, based on the port number of th= e answerer BUNDLE address, use the next higher (odd) destination port number [RFC3550] for sending RTCP packets associated with a bundled "m=3D" line towards the answerer." [TS] Similar here If the answerer does not accept the usage of RTP/RTCP multiplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP and RTCP. Based on the port number of the selected offerer BUNDLE address, the offerer will receive RTCP packets associated with any bundled "m=3D" l= ine at the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the offerer will send RTCP packets associated with any bundled "m=3D" line to the next higher (odd) destination port [RFC3550]. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 8. lokakuuta 2014 13:06 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Christer, From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 7. Oktober 2014 20:35 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, >BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. >I can't find text in bundle-11 where the answerer would send its RTCP pack= ets if it accepted BUNDLE, but rejected RTCP-muxing. >I see two options: >1. The answerer sends all RTCP packets to the shared RTP-port+1 of the neg= otiated shared address. >2. The answerer sends the RTCP packets to separate ports based on the uniq= ue addresses in the m-lines of the offer? Alternative 1) is correct. I guess we could add some text to clarify that. [TS] Yes, please. The current text is not sufficiently clear. >The offerer on the other hand will only receive a shared address. I assume= it then has to send all its RTCP packets >to the shared RTP-port+1 of the answerer. Yes. >Is my understanding correct or am I completely off-track? Assuming my understanding is correct, your understanding is correct :) >Supposed I'm correct, then independent from the response, I'm asking if th= ere really is a use case for that. >In case 1, one would have to demux the RTP streams and RTCP streams from t= wo separate ports instead of a single port. How much implementation effort = >is saved in that case? I am not sure what you mean. Are you asking how much implementation effort = is saved if you don't have to de-mux RTP and RTCP? [TS] Yes. I was questioning myself what benefit there is in not mandating = RTCP-mux. In the meantime I looked up again the discussion on "Q14" that led to havin= g rtcp-mux optional. I agree with the outcome. Thanks! >In case 2 the RTCP handling at offerer and answerer is completely differen= t. In addition, you still need "a lot" of RTCP ports and take advantage of = only half >of the BUNDLE benefits. Correct. But, case 2 is not applicable (unless the endpoints choose not to = use BUNDLE to begin with, that is...). Regards, Christer --_000_F81CEE99482EFE438DAE2A652361EE121E229112MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well,

of course you are righ= t that parts the proposed text is somewhat redundant and I would not insist= on having the longer text.

It’s just that t= hings that appear obvious to some are not always clear to others.

I would leave the deci= sion up to you.

 

Independent from that,= there are throughout the document quite a few other occurrences of redunda= nt text that could be scrutinized for necessity as well.<= /p>

E.g. in 8.2=

   The generic rules and procedures defined in [= RFC3264] and [RFC5888]

   also apply to the BUNDLE extension.  For= example, if an offer is

   rejected by the answerer, the previously nego= tiated SDP parameters

   and characteristics (including those associat= ed with a BUNDLE group)

   apply.  Hence, if an offerer generates a= n offer in which the offerer

   wants to create a BUNDLE group, and the answe= rer rejects the offer,

   the BUNDLE group is not created.

The first sentence is = probably ok, but the remainder just repeats 3264/5888.

 

I could point you to o= ther such examples if you want me to.

 

Regards

Thomas

 

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Mittwoch, 8. Oktober 2014 21:06
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi,

&n= bsp;

Do we r= eally need text for both sending and receiving?

&n= bsp;

If we s= ay that an entity sends something towards port X, I think it is obvious tha= t the other endpoint will listen on port X.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

 

From: Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: 08 October 2014 16:21
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

inline

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Mittwoch, 8. Oktober 2014 13:37
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thomas,<= /span>

 

I suggest something li= ke this:

 

In section 10.3.2.3:

 

OLD TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within t= he

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer.”=

 

NEW TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within t= he

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer. The answerer will,<= /o:p>

   &nbs= p;            based = on the port number of the selected offerer BUNDLE address,

   &nbs= p;            use th= e next higher (odd) destination port number [RFC3550] for

sending RTCP packets associated with a bundled “m=3D” line= towards

the offerer,”

[TS] I’d l= ike to add something for receiving RCTP. With a slight re-wording the new t= ext would be

If the answerer rejects usage of RTP/RTCP mult= iplexing within the

BUNDLE group, it MUST NOT assign an SDP 'rtcp-= mux' or SDP 'rtcp'

= attribute to any bundled "m=3D" line in the answer.

=  Based on the port number of the selected offerer BUNDLE address,

=  the answerer will send RTCP packets associated with any bundled ̶= 0;m=3D” line

=  to the next higher (odd) destination port [RFC3550].

=  Based on the port number of the selected answerer BUNDLE address,

=  the answerer will receive RTCP packets associated with any bundled &#= 8220;m=3D” line

=  at the next higher (odd) destination port [RFC3550].

= This means that the associated RTCP streams for bundled “m=3D” = lines

=  are bundled at the next higher (odd) destination port

 

 

In section 10.3.2.4:

 

OLD TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP.&#= 8221;

 

NEW TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP. T= he answerer will, based on the port number of the answerer

BUNDLE address, use the next higher (odd) destination port number [RFC= 3550]

for sending RTCP packets associated with a bundled “m=3D” = line towards the

answerer.”

 

[TS] Similar her= e

If the answerer does not accept the usage of R= TP/RTCP multiplexing

[Section 10.3.2.3], the offerer MUST use separ= ate 5-tuples for RTP

and RTCP.

= Based on the port number of the selected offerer BUNDLE address,

=  the offerer will receive RTCP packets associated with any bundled = 220;m=3D” line

=  at the next higher (odd) destination port [RFC3550].

=  Based on the port number of the selected answerer BUNDLE address,

=  the offerer will send RTCP packets associated with any bundled “= ;m=3D” line

=  to the next higher (odd) destination port [RFC3550].

 

 

Regards,

 

Christer

 

 

 

 

From: Stach, T= homas [mailto:thomas.stach@unify.= com]
Sent: 8. lokakuuta 2014 13:06
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

 

Christer,

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thom= as,

 

>BUNDLE can be used separate from RFC5761 RTCP-Mu= ltiplexing.

>I can’t find text in bundle-11 where the a= nswerer would send its RTCP packets if it accepted BUNDLE, but rejected RTC= P-muxing.

>I see two options:

>1. The answerer sends all RTCP packets to the sh= ared RTP-port+1 of the negotiated shared address.

>2. The answerer sends the RTCP packets to separa= te ports based on the unique addresses in the m-lines of the offer?

 

Alternative 1) is correct. I guess we could add some= text to clarify that.

[TS] Yes, please= . The current text is not sufficiently clear.

 

>The offerer on the other hand will only receive = a shared address. I assume it then has to send all its RTCP packets

>to the shared RTP-port+1 of the answerer.

 

Yes.

 

>Is my understanding correct or am I completely o= ff-track?

 

Assuming my understanding is correct, your understan= ding is correct :)

 

>Supposed I’m correct, then independent fro= m the response, I’m asking if there really is a use case for that.

>In case 1, one would have to demux the RTP strea= ms and RTCP streams from two separate ports instead of a single port. How m= uch implementation effort >is saved in that case?

 

I am not sure what you mean. Are you asking how much= implementation effort is saved if you don’t have to de-mux RTP and R= TCP?

[TS] Yes.  = I was questioning myself what benefit there is in not mandating RTCP-mux.

In the meantime = I looked up again the discussion on “Q14“ that led to having rt= cp-mux optional. I agree with the outcome.

Thanks!

 

>In case 2 the RTCP handling at offerer and answe= rer is completely different. In addition, you still need “a lot“= ; of RTCP ports and take advantage of only half >of the BUNDLE benefits.=

 

Correct. But, case 2 is not applicable (unless the e= ndpoints choose not to use BUNDLE to begin with, that is…).

 

Regards,

 

Christer

 

--_000_F81CEE99482EFE438DAE2A652361EE121E229112MCHP04MSXglobal_-- From nobody Thu Oct 9 07:03:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2D01ACECC for ; Thu, 9 Oct 2014 07:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BOioMtAtU6B for ; Thu, 9 Oct 2014 07:03:07 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1E21A1B37 for ; Thu, 9 Oct 2014 07:02:05 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-68-5436955bed0f Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 97.61.02247.B5596345; Thu, 9 Oct 2014 16:02:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 16:02:03 +0200 From: Christer Holmberg To: "Stach, Thomas" , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHgABwyUoAABzpZoAADjPnAAAyQalAAJauvUAAB6NUA Date: Thu, 9 Oct 2014 14:02:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D470CFF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D46E6EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D46EFC7@ESESSMB209.ericsson.se> 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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D470CFFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM+JvjW7MVLMQg5lnuS06JrNZHOvrYrOY uvwxi8XJnduYHVg8rky4wuox5fdGVo8lS34yeWzvecwSwBLFZZOSmpNZllqkb5fAlbFtokbB 3AVMFVv3drM1MK79w9jFyMkhIWAi0briKguELSZx4d56ti5GLg4hgaOMEveX7GOBcBYzSry6 vxDI4eBgE7CQ6P6nDRIXEWhnlPh/9BQrSDezgIzEjLONTCC2sICDxNwD28Cmigg4Shx+c4MZ wo6S+LDmO1gNi4CKxP5de5lAZvIK+Ep82eIDsesls8Tno7PYQWo4Bfwlbh8+DXYpI9B130+t YYLYJS5x68l8JoirBSSW7DnPDGGLSrx8/I8VwlaU+PhqHyPIfGaBfInnq21AwrwCghInZz5h mcAoOgvJpFkIVbOQVEGU6Egs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uLc9ONjPRS izKTi4vz8/TyUks2MQKj8uCW31Y7GA8+dzzEKMDBqMTDm6BiFiLEmlhWXJl7iFGag0VJnHfh uXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhXPhDsNLVryLe8s7hE6ra15/ZNrdk7t7ze Jbnt+577jA5TDphfLt7kuWai8Mswj/t+oVra5me+sn/piWx5rv34qUnhfK5VKjfPfZ+/cNda 4wfx/yfrn5y/+eQS/tuFL0POtB/6wJ32tev1i8MOrlN3rLDZG+Kn+/Rejfe32YbFcr0321YL WpsYK7EUZyQaajEXFScCAK8pQrWrAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3Xh90TrNu2dqTRlEBN-MJHcNoQc Cc: mmusic Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 14:03:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D470CFFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In previous reviews, I have been asked to add the examples you are referrin= g to. I have spent very much time on editorial fixes, and re-structures of the wh= ole document, to make it more readable etc. If something is difficult to un= derstand, we should of course fix that, but I'd really like people to also = focus on the technical content. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 9. lokakuuta 2014 16:05 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Well, of course you are right that parts the proposed text is somewhat redundant = and I would not insist on having the longer text. It's just that things that appear obvious to some are not always clear to o= thers. I would leave the decision up to you. Independent from that, there are throughout the document quite a few other = occurrences of redundant text that could be scrutinized for necessity as we= ll. E.g. in 8.2 The generic rules and procedures defined in [RFC3264] and [RFC5888] also apply to the BUNDLE extension. For example, if an offer is rejected by the answerer, the previously negotiated SDP parameters and characteristics (including those associated with a BUNDLE group) apply. Hence, if an offerer generates an offer in which the offerer wants to create a BUNDLE group, and the answerer rejects the offer, the BUNDLE group is not created. The first sentence is probably ok, but the remainder just repeats 3264/5888= . I could point you to other such examples if you want me to. Regards Thomas From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Mittwoch, 8. Oktober 2014 21:06 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi, Do we really need text for both sending and receiving? If we say that an entity sends something towards port X, I think it is obvi= ous that the other endpoint will listen on port X. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 08 October 2014 16:21 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected inline From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Mittwoch, 8. Oktober 2014 13:37 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, I suggest something like this: In section 10.3.2.3: OLD TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer." NEW TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer. The ans= werer will, based on the port number of the selected offerer BUNDLE add= ress, use the next higher (odd) destination port number [RFC3550]= for sending RTCP packets associated with a bundled "m=3D" line towards the offerer," [TS] I'd like to add something for receiving RCTP. With a slight re-wording= the new text would be If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=3D" line in the answer. Based on the port number of the selected offerer BUNDLE address, the answerer will send RTCP packets associated with any bundled "m=3D" lin= e to the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the answerer will receive RTCP packets associated with any bundled "m=3D" = line at the next higher (odd) destination port [RFC3550]. This means that the associated RTCP streams for bundled "m=3D" lines are bundled at the next higher (odd) destination port In section 10.3.2.4: OLD TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP." NEW TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP. The answerer will, based on the port number of th= e answerer BUNDLE address, use the next higher (odd) destination port number [RFC3550] for sending RTCP packets associated with a bundled "m=3D" line towards the answerer." [TS] Similar here If the answerer does not accept the usage of RTP/RTCP multiplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP and RTCP. Based on the port number of the selected offerer BUNDLE address, the offerer will receive RTCP packets associated with any bundled "m=3D" l= ine at the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the offerer will send RTCP packets associated with any bundled "m=3D" line to the next higher (odd) destination port [RFC3550]. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 8. lokakuuta 2014 13:06 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Christer, From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 7. Oktober 2014 20:35 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, >BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. >I can't find text in bundle-11 where the answerer would send its RTCP pack= ets if it accepted BUNDLE, but rejected RTCP-muxing. >I see two options: >1. The answerer sends all RTCP packets to the shared RTP-port+1 of the neg= otiated shared address. >2. The answerer sends the RTCP packets to separate ports based on the uniq= ue addresses in the m-lines of the offer? Alternative 1) is correct. I guess we could add some text to clarify that. [TS] Yes, please. The current text is not sufficiently clear. >The offerer on the other hand will only receive a shared address. I assume= it then has to send all its RTCP packets >to the shared RTP-port+1 of the answerer. Yes. >Is my understanding correct or am I completely off-track? Assuming my understanding is correct, your understanding is correct :) >Supposed I'm correct, then independent from the response, I'm asking if th= ere really is a use case for that. >In case 1, one would have to demux the RTP streams and RTCP streams from t= wo separate ports instead of a single port. How much implementation effort = >is saved in that case? I am not sure what you mean. Are you asking how much implementation effort = is saved if you don't have to de-mux RTP and RTCP? [TS] Yes. I was questioning myself what benefit there is in not mandating = RTCP-mux. In the meantime I looked up again the discussion on "Q14" that led to havin= g rtcp-mux optional. I agree with the outcome. Thanks! >In case 2 the RTCP handling at offerer and answerer is completely differen= t. In addition, you still need "a lot" of RTCP ports and take advantage of = only half >of the BUNDLE benefits. Correct. But, case 2 is not applicable (unless the endpoints choose not to = use BUNDLE to begin with, that is...). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D470CFFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

In previous reviews, I= have been asked to add the examples you are referring to.

 

I have spent very much= time on editorial fixes, and re-structures of the whole document, to make = it more readable etc. If something is difficult to understand, we should of= course fix that, but I’d really like people to also focus on the technical content.

 

Regards,

 

Christer

 

 

 

From: Stach, T= homas [mailto:thomas.stach@unify.com]
Sent: 9. lokakuuta 2014 16:05
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Well,

of course you are righ= t that parts the proposed text is somewhat redundant and I would not insist= on having the longer text.

It’s just that t= hings that appear obvious to some are not always clear to others.

I would leave the deci= sion up to you.

 

Independent from that,= there are throughout the document quite a few other occurrences of redunda= nt text that could be scrutinized for necessity as well.<= /p>

E.g. in 8.2=

   The generic rules and procedures defined in [= RFC3264] and [RFC5888]

   also apply to the BUNDLE extension.  For= example, if an offer is

   rejected by the answerer, the previously nego= tiated SDP parameters

   and characteristics (including those associat= ed with a BUNDLE group)

   apply.  Hence, if an offerer generates a= n offer in which the offerer

   wants to create a BUNDLE group, and the answe= rer rejects the offer,

   the BUNDLE group is not created.

The first sentence is = probably ok, but the remainder just repeats 3264/5888.

 

I could point you to o= ther such examples if you want me to.

 

Regards

Thomas

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Mittwoch, 8. Oktober 2014 21:06
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi,

&n= bsp;

Do we r= eally need text for both sending and receiving?

&n= bsp;

If we s= ay that an entity sends something towards port X, I think it is obvious tha= t the other endpoint will listen on port X.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

 

From: Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: 08 October 2014 16:21
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

inline

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Mittwoch, 8. Oktober 2014 13:37
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thomas,<= /span>

 

I suggest something li= ke this:

 

In section 10.3.2.3:

 

OLD TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within= the

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer.”=

 

NEW TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within= the

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer. The answerer will,<= /o:p>

   &nbs= p;            based = on the port number of the selected offerer BUNDLE address,

   &nbs= p;            use th= e next higher (odd) destination port number [RFC3550] for

sending RTCP packets associated with a bundled “m=3D” li= ne towards

the offerer,”

[TS] I’d l= ike to add something for receiving RCTP. With a slight re-wording the new t= ext would be

If the answerer rejects usage of RTP/RTCP mult= iplexing within the

BUNDLE group, it MUST NOT assign an SDP 'rtcp-= mux' or SDP 'rtcp'

= attribute to any bundled "m=3D" line in the answer.

=  Based on the port number of the selected offerer BUNDLE address,

=  the answerer will send RTCP packets associated with any bundled ̶= 0;m=3D” line

=  to the next higher (odd) destination port [RFC3550].

=  Based on the port number of the selected answerer BUNDLE address,

=  the answerer will receive RTCP packets associated with any bundled &#= 8220;m=3D” line

=  at the next higher (odd) destination port [RFC3550].

= This means that the associated RTCP streams for bundled “m=3D” = lines

=  are bundled at the next higher (odd) destination port

 

 

In section 10.3.2.4:

 

OLD TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP.&#= 8221;

 

NEW TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP. T= he answerer will, based on the port number of the answerer

BUNDLE address, use the next higher (odd) destination port number [R= FC3550]

for sending RTCP packets associated with a bundled “m=3D”= ; line towards the

answerer.”

 

[TS] Similar her= e

If the answerer does not accept the usage of R= TP/RTCP multiplexing

[Section 10.3.2.3], the offerer MUST use separ= ate 5-tuples for RTP

and RTCP.

= Based on the port number of the selected offerer BUNDLE address,

=  the offerer will receive RTCP packets associated with any bundled = 220;m=3D” line

=  at the next higher (odd) destination port [RFC3550].

=  Based on the port number of the selected answerer BUNDLE address,

=  the offerer will send RTCP packets associated with any bundled “= ;m=3D” line

=  to the next higher (odd) destination port [RFC3550].

 

 

Regards,

 

Christer

 

 

 

 

From: Stach, T= homas [mailto:thomas.stach@unify.= com]
Sent: 8. lokakuuta 2014 13:06
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

 

Christer,

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thom= as,

 

>BUNDLE can be used separate from RFC5761 RTCP-Mu= ltiplexing.

>I can’t find text in bundle-11 where the a= nswerer would send its RTCP packets if it accepted BUNDLE, but rejected RTC= P-muxing.

>I see two options:

>1. The answerer sends all RTCP packets to the sh= ared RTP-port+1 of the negotiated shared address.

>2. The answerer sends the RTCP packets to separa= te ports based on the unique addresses in the m-lines of the offer?

 

Alternative 1) is correct. I guess we could add some= text to clarify that.

[TS] Yes, please= . The current text is not sufficiently clear.

 

>The offerer on the other hand will only receive = a shared address. I assume it then has to send all its RTCP packets

>to the shared RTP-port+1 of the answerer.

 

Yes.

 

>Is my understanding correct or am I completely o= ff-track?

 

Assuming my understanding is correct, your understan= ding is correct :)

 

>Supposed I’m correct, then independent fro= m the response, I’m asking if there really is a use case for that.

>In case 1, one would have to demux the RTP strea= ms and RTCP streams from two separate ports instead of a single port. How m= uch implementation effort >is saved in that case?

 

I am not sure what you mean. Are you asking how much= implementation effort is saved if you don’t have to de-mux RTP and R= TCP?

[TS] Yes.  = I was questioning myself what benefit there is in not mandating RTCP-mux.

In the meantime = I looked up again the discussion on “Q14“ that led to having rt= cp-mux optional. I agree with the outcome.

Thanks!

 

>In case 2 the RTCP handling at offerer and answe= rer is completely different. In addition, you still need “a lot“= ; of RTCP ports and take advantage of only half >of the BUNDLE benefits.=

 

Correct. But, case 2 is not applicable (unless the e= ndpoints choose not to use BUNDLE to begin with, that is…).

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D470CFFESESSMB209erics_-- From nobody Thu Oct 9 07:52:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59EC1ACF88 for ; Thu, 9 Oct 2014 07:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00ERZ04jqnVY for ; Thu, 9 Oct 2014 07:52:32 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 352981ACEC7 for ; Thu, 9 Oct 2014 07:52:30 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 18A641EB8576; Thu, 9 Oct 2014 16:52:29 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 16:52:28 +0200 From: "Stach, Thomas" To: Christer Holmberg , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHgABwyUoAABzpZoAADjPnAAAyQalAAJauvUAAB6NUAAADyd2A= Date: Thu, 9 Oct 2014 14:52:27 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D46CF08@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D46E6EF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D46EFC7@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D470CFF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D470CFF@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E2291E9MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rMZqmTuXtp3SQsOdghVz3LxmZVU Cc: mmusic Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 14:52:37 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E2291E9MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok understood. I can imagine the amount of time that you already spent. I will postpone further editorial comments. Regards Thomas From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Donnerstag, 9. Oktober 2014 16:02 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi, In previous reviews, I have been asked to add the examples you are referrin= g to. I have spent very much time on editorial fixes, and re-structures of the wh= ole document, to make it more readable etc. If something is difficult to un= derstand, we should of course fix that, but I'd really like people to also = focus on the technical content. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 9. lokakuuta 2014 16:05 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Well, of course you are right that parts the proposed text is somewhat redundant = and I would not insist on having the longer text. It's just that things that appear obvious to some are not always clear to o= thers. I would leave the decision up to you. Independent from that, there are throughout the document quite a few other = occurrences of redundant text that could be scrutinized for necessity as we= ll. E.g. in 8.2 The generic rules and procedures defined in [RFC3264] and [RFC5888] also apply to the BUNDLE extension. For example, if an offer is rejected by the answerer, the previously negotiated SDP parameters and characteristics (including those associated with a BUNDLE group) apply. Hence, if an offerer generates an offer in which the offerer wants to create a BUNDLE group, and the answerer rejects the offer, the BUNDLE group is not created. The first sentence is probably ok, but the remainder just repeats 3264/5888= . I could point you to other such examples if you want me to. Regards Thomas From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Mittwoch, 8. Oktober 2014 21:06 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi, Do we really need text for both sending and receiving? If we say that an entity sends something towards port X, I think it is obvi= ous that the other endpoint will listen on port X. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 08 October 2014 16:21 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected inline From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Mittwoch, 8. Oktober 2014 13:37 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, I suggest something like this: In section 10.3.2.3: OLD TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer." NEW TEXT: "If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP '= rtcp' attribute to any bundled "m=3D" line in the answer. The ans= werer will, based on the port number of the selected offerer BUNDLE add= ress, use the next higher (odd) destination port number [RFC3550]= for sending RTCP packets associated with a bundled "m=3D" line towards the offerer," [TS] I'd like to add something for receiving RCTP. With a slight re-wording= the new text would be If the answerer rejects usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=3D" line in the answer. Based on the port number of the selected offerer BUNDLE address, the answerer will send RTCP packets associated with any bundled "m=3D" lin= e to the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the answerer will receive RTCP packets associated with any bundled "m=3D" = line at the next higher (odd) destination port [RFC3550]. This means that the associated RTCP streams for bundled "m=3D" lines are bundled at the next higher (odd) destination port In section 10.3.2.4: OLD TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP." NEW TEXT: "If the answerer does not accept the usage of RTP/RTCP mult= iplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples = for RTP and RTCP. The answerer will, based on the port number of th= e answerer BUNDLE address, use the next higher (odd) destination port number [RFC3550] for sending RTCP packets associated with a bundled "m=3D" line towards the answerer." [TS] Similar here If the answerer does not accept the usage of RTP/RTCP multiplexing [Section 10.3.2.3], the offerer MUST use separate 5-tuples for RTP and RTCP. Based on the port number of the selected offerer BUNDLE address, the offerer will receive RTCP packets associated with any bundled "m=3D" l= ine at the next higher (odd) destination port [RFC3550]. Based on the port number of the selected answerer BUNDLE address, the offerer will send RTCP packets associated with any bundled "m=3D" line to the next higher (odd) destination port [RFC3550]. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 8. lokakuuta 2014 13:06 To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Christer, From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Dienstag, 7. Oktober 2014 20:35 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected Hi Thomas, >BUNDLE can be used separate from RFC5761 RTCP-Multiplexing. >I can't find text in bundle-11 where the answerer would send its RTCP pack= ets if it accepted BUNDLE, but rejected RTCP-muxing. >I see two options: >1. The answerer sends all RTCP packets to the shared RTP-port+1 of the neg= otiated shared address. >2. The answerer sends the RTCP packets to separate ports based on the uniq= ue addresses in the m-lines of the offer? Alternative 1) is correct. I guess we could add some text to clarify that. [TS] Yes, please. The current text is not sufficiently clear. >The offerer on the other hand will only receive a shared address. I assume= it then has to send all its RTCP packets >to the shared RTP-port+1 of the answerer. Yes. >Is my understanding correct or am I completely off-track? Assuming my understanding is correct, your understanding is correct :) >Supposed I'm correct, then independent from the response, I'm asking if th= ere really is a use case for that. >In case 1, one would have to demux the RTP streams and RTCP streams from t= wo separate ports instead of a single port. How much implementation effort = >is saved in that case? I am not sure what you mean. Are you asking how much implementation effort = is saved if you don't have to de-mux RTP and RTCP? [TS] Yes. I was questioning myself what benefit there is in not mandating = RTCP-mux. In the meantime I looked up again the discussion on "Q14" that led to havin= g rtcp-mux optional. I agree with the outcome. Thanks! >In case 2 the RTCP handling at offerer and answerer is completely differen= t. In addition, you still need "a lot" of RTCP ports and take advantage of = only half >of the BUNDLE benefits. Correct. But, case 2 is not applicable (unless the endpoints choose not to = use BUNDLE to begin with, that is...). Regards, Christer --_000_F81CEE99482EFE438DAE2A652361EE121E2291E9MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok understood.

I can imagine the amou= nt of time that you already spent.

I will postpone furthe= r editorial comments.

 

Regards

Thomas

 

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Donnerstag, 9. Oktober 2014 16:02
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi,<= /p>

 

In previous reviews, I= have been asked to add the examples you are referring to.

 

I have spent very much= time on editorial fixes, and re-structures of the whole document, to make = it more readable etc. If something is difficult to understand, we should of= course fix that, but I’d really like people to also focus on the technical content.

 

Regards,

 

Christer

 

 

 

From: Stach, T= homas [mailto:thomas.stach@unify.= com]
Sent: 9. lokakuuta 2014 16:05
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Well,

of course you are righ= t that parts the proposed text is somewhat redundant and I would not insist= on having the longer text.

It’s just that t= hings that appear obvious to some are not always clear to others.

I would leave the deci= sion up to you.

 

Independent from that,= there are throughout the document quite a few other occurrences of redunda= nt text that could be scrutinized for necessity as well.<= /p>

E.g. in 8.2=

   The generic rules and procedures defined in [= RFC3264] and [RFC5888]

   also apply to the BUNDLE extension.  For= example, if an offer is

   rejected by the answerer, the previously nego= tiated SDP parameters

   and characteristics (including those associat= ed with a BUNDLE group)

   apply.  Hence, if an offerer generates a= n offer in which the offerer

   wants to create a BUNDLE group, and the answe= rer rejects the offer,

   the BUNDLE group is not created.

The first sentence is = probably ok, but the remainder just repeats 3264/5888.

 

I could point you to o= ther such examples if you want me to.

 

Regards

Thomas

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Mittwoch, 8. Oktober 2014 21:06
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi,

&n= bsp;

Do we r= eally need text for both sending and receiving?

&n= bsp;

If we s= ay that an entity sends something towards port X, I think it is obvious tha= t the other endpoint will listen on port X.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

 

From: Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: 08 October 2014 16:21
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

inline

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Mittwoch, 8. Oktober 2014 13:37
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thomas,<= /span>

 

I suggest something li= ke this:

 

In section 10.3.2.3:

 

OLD TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within t= he

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer.”=

 

NEW TEXT:

 

“If the answerer rejects usage of RTP/RTCP multiplexing within t= he

    &nb= sp;           BUNDLE grou= p, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'

    &nb= sp;           attribute t= o any bundled "m=3D" line in the answer. The answerer will,<= /o:p>

   &nbs= p;            based = on the port number of the selected offerer BUNDLE address,

   &nbs= p;            use th= e next higher (odd) destination port number [RFC3550] for

sending RTCP packets associated with a bundled “m=3D” line= towards

the offerer,”

[TS] I’d l= ike to add something for receiving RCTP. With a slight re-wording the new t= ext would be

If the answerer rejects usage of RTP/RTCP mult= iplexing within the

BUNDLE group, it MUST NOT assign an SDP 'rtcp-= mux' or SDP 'rtcp'

= attribute to any bundled "m=3D" line in the answer.

=  Based on the port number of the selected offerer BUNDLE address,

=  the answerer will send RTCP packets associated with any bundled ̶= 0;m=3D” line

=  to the next higher (odd) destination port [RFC3550].

=  Based on the port number of the selected answerer BUNDLE address,

=  the answerer will receive RTCP packets associated with any bundled &#= 8220;m=3D” line

=  at the next higher (odd) destination port [RFC3550].

= This means that the associated RTCP streams for bundled “m=3D” = lines

=  are bundled at the next higher (odd) destination port

 

 

In section 10.3.2.4:

 

OLD TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP.&#= 8221;

 

NEW TEXT:

 

   &nbs= p;            “= ;If the answerer does not accept the usage of RTP/RTCP multiplexing

    &nb= sp;           [Section 10= .3.2.3], the offerer MUST use separate 5-tuples for RTP

    &nb= sp;           and RTCP. T= he answerer will, based on the port number of the answerer

BUNDLE address, use the next higher (odd) destination port number [RFC= 3550]

for sending RTCP packets associated with a bundled “m=3D” = line towards the

answerer.”

 

[TS] Similar her= e

If the answerer does not accept the usage of R= TP/RTCP multiplexing

[Section 10.3.2.3], the offerer MUST use separ= ate 5-tuples for RTP

and RTCP.

= Based on the port number of the selected offerer BUNDLE address,

=  the offerer will receive RTCP packets associated with any bundled = 220;m=3D” line

=  at the next higher (odd) destination port [RFC3550].

=  Based on the port number of the selected answerer BUNDLE address,

=  the offerer will send RTCP packets associated with any bundled “= ;m=3D” line

=  to the next higher (odd) destination port [RFC3550].

 

 

Regards,

 

Christer

 

 

 

 

From: Stach, T= homas [mailto:thomas.stach@unify.= com]
Sent: 8. lokakuuta 2014 13:06
To: Christer Holmberg; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

 

Christer,

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected<= /o:p>

 

Hi Thom= as,

 

>BUNDLE can be used separate from RFC5761 RTCP-Mu= ltiplexing.

>I can’t find text in bundle-11 where the a= nswerer would send its RTCP packets if it accepted BUNDLE, but rejected RTC= P-muxing.

>I see two options:

>1. The answerer sends all RTCP packets to the sh= ared RTP-port+1 of the negotiated shared address.

>2. The answerer sends the RTCP packets to separa= te ports based on the unique addresses in the m-lines of the offer?

 

Alternative 1) is correct. I guess we could add some= text to clarify that.

[TS] Yes, please= . The current text is not sufficiently clear.

 

>The offerer on the other hand will only receive = a shared address. I assume it then has to send all its RTCP packets

>to the shared RTP-port+1 of the answerer.

 

Yes.

 

>Is my understanding correct or am I completely o= ff-track?

 

Assuming my understanding is correct, your understan= ding is correct :)

 

>Supposed I’m correct, then independent fro= m the response, I’m asking if there really is a use case for that.

>In case 1, one would have to demux the RTP strea= ms and RTCP streams from two separate ports instead of a single port. How m= uch implementation effort >is saved in that case?

 

I am not sure what you mean. Are you asking how much= implementation effort is saved if you don’t have to de-mux RTP and R= TCP?

[TS] Yes.  = I was questioning myself what benefit there is in not mandating RTCP-mux.

In the meantime = I looked up again the discussion on “Q14“ that led to having rt= cp-mux optional. I agree with the outcome.

Thanks!

 

>In case 2 the RTCP handling at offerer and answe= rer is completely different. In addition, you still need “a lot“= ; of RTCP ports and take advantage of only half >of the BUNDLE benefits.=

 

Correct. But, case 2 is not applicable (unless the e= ndpoints choose not to use BUNDLE to begin with, that is…).

 

Regards,

 

Christer

 

--_000_F81CEE99482EFE438DAE2A652361EE121E2291E9MCHP04MSXglobal_-- From nobody Thu Oct 9 08:08:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF551A1B07 for ; Thu, 9 Oct 2014 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 490Lh7VY_4vO for ; Thu, 9 Oct 2014 08:08:14 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id DEADA1A1AFE for ; Thu, 9 Oct 2014 08:08:13 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 17C8323F04BB; Thu, 9 Oct 2014 17:08:13 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 17:08:12 +0200 From: "Stach, Thomas" To: Christer Holmberg , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: Bundle Address Synchronization (BAS) Thread-Index: Ac/j0tcu2NruXxDsTEC0KS+v/a6o+A== Date: Thu, 9 Oct 2014 15:08:11 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E229227MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/r_Qh_8j-FnxScYK1zQlJJ1V_D4Q Cc: mmusic Subject: [MMUSIC] bundle-11: Bundle Address Synchronization (BAS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 15:08:16 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E229227MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christer, Cullen, Harald, all Bundle Address Synchronization (BAS) is motivated by almost the same argume= nts that led to the ICE updated offer/answer in 5245. Now, at IETF 90 the updated offer/answer procedures for ICE were discussed = and the consensus was to change the existing behavior to: " you do it (i.e. the updated offer/answer) or don't do it, but you indicat= e in the o/a if you're going to do it. Basically want to have option to nev= er do the updated O/A exchange, with an indication in the signaling that yo= u will not be doing it. Of course can always initiate a new O/A exchange wh= enever you want to." I think the same discussion and obviously its result also applies to BUNDL= E and BAS. Otherwise, if you use BUNDLE together with ICE, the updated offer/answer cy= cle is back. If the WG agrees, this would require some additional parameter/attribute in= the offer that indicates if BAS will be performed or not. Some common approach for the updated offer/answer issue might also be justi= fied. An obvious thought would be if re-using the same "thing" for ICE and BUNDL= E would be appropriate. ... and for CapNeg albeit its lack of deployment Thoughts Regards Thomas --_000_F81CEE99482EFE438DAE2A652361EE121E229227MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christer, Cullen, Harald, all

 

Bundle Address Synchronization (BAS) is motivated by= almost the same arguments that led to the ICE updated offer/answer in 5245= .

 

Now, at IETF 90 the updated offer/answer procedures = for ICE were discussed and the consensus was to change the existing behavio= r to:

“ you do it (i.e. the updated offer/answer) or= don’t do it, but you indicate in the o/a if you’re going to do= it. Basically want to have option to never do the updated O/A exchange, wi= th an indication in the signaling that you will not be doing it. Of course can always initiate a new O/A exchange whenever you= want to.”

 

I think the same discussion and obviously  its = result also applies to BUNDLE and BAS.

Otherwise, if you use BUNDLE together with ICE, the = updated offer/answer cycle is back.

If the WG agrees, this would require some additional= parameter/attribute in the offer that indicates if BAS will be performed o= r not.

 

Some common approach for the updated offer/answer is= sue might also be justified.

An obvious thought  would be if re-using the sa= me “thing” for ICE and BUNDLE would be appropriate.

... and for CapNeg albeit its lack of deployment

Thoughts

 

Regards

Thomas

 

--_000_F81CEE99482EFE438DAE2A652361EE121E229227MCHP04MSXglobal_-- From nobody Thu Oct 9 11:41:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF661A02C2 for ; Thu, 9 Oct 2014 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3Uw4e_5biXK for ; Thu, 9 Oct 2014 11:41:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D956C1A014E for ; Thu, 9 Oct 2014 11:41:22 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-25-5436d6d041d4 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.AB.24955.0D6D6345; Thu, 9 Oct 2014 20:41:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 20:41:20 +0200 From: Christer Holmberg To: "Stach, Thomas" , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: Bundle Address Synchronization (BAS) Thread-Index: Ac/j0tcu2NruXxDsTEC0KS+v/a6o+AAHL98Q Date: Thu, 9 Oct 2014 18:41:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47124E@ESESSMB209.ericsson.se> References: 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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D47124EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+Jvje6Fa2YhBtvXGFh0TGazONbXxWYx dfljFouTO7cxO7B4XJlwhdVjyu+NrB5Llvxk8tje85glgCWKyyYlNSezLLVI3y6BK2P//8Ps BfucK14vmsXewNhr3cXIySEhYCJxu2sXM4QtJnHh3nq2LkYuDiGBo4wSb65/ZYJwFjNKXH67 jLGLkYODTcBCovufNkhcRKCdUeL/0VOsIN3MAjISM842MoHYwgK2EmdXtTGD1IsI2Elsf5gL EhYRMJLYvvU3C4jNIqAi8bTrDFgrr4CvxOkVtxlBbCEBP4kVLxeBtXIK+Et8es0DEmYEuu37 qTVMEJvEJW49mc8EcbOAxJI956HuF5V4+fgfK4StJNG45AnUZfkSPWvOMUKsEpQ4OfMJywRG 0VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFqclJtuZKyXWpSZ XFycn6eXl1qyiREYkwe3/FbdwXj5jeMhRgEORiUe3gQVsxAh1sSy4srcQ4zSHCxK4rwLz80L FhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCo2C+XpJdc8Lhv+qHN88M5qnIPts/Yk3zmz4/b ydNENqS+CJ1h8+yX6O59DTOUvm6PTt6XbLH0UvmBlts7Lh0sqCniWiNw/WmQ/4fpL24pC4gv 2STLzpCzeR/vrdpkzynBT1nWlmw9cqz4D9fjhf+fNUbvaVxkzHv1iWtOoa4H6+uCpQ2eaUm5 SizFGYmGWsxFxYkAxcOs6aoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1gCB4VfzuVDEwYPpXJW8U0U_NuU Cc: mmusic Subject: Re: [MMUSIC] bundle-11: Bundle Address Synchronization (BAS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 18:41:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D47124EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >Bundle Address Synchronization (BAS) is motivated by almost the same >argu= ments that led to the ICE updated offer/answer in 5245. > >Now, at IETF 90 the updated offer/answer procedures for ICE were discussed= >and the consensus was to change the existing behavior to: >" you do it (i.e. the updated offer/answer) or don't do it, but you indica= te in >the o/a if you're going to do it. Basically want to have option to n= ever do the >updated O/A exchange, with an indication in the signaling that= you will not >be doing it. Of course can always initiate a new O/A exchang= e whenever you >want to." Actually, that consensus is still to be confirmed on the list... >I think the same discussion and obviously its result also applies to BUND= LE >and BAS. >Otherwise, if you use BUNDLE together with ICE, the updated offer/answer >= cycle is back. >If the WG agrees, this would require some additional parameter/attribute i= n >the offer that indicates if BAS will be performed or not. > >Some common approach for the updated offer/answer issue might also be >jus= tified. >An obvious thought would be if re-using the same "thing" for ICE and >BUN= DLE would be appropriate. >... and for CapNeg albeit its lack of deployment In general, I prefer a negotiation model, rather than the sender indicating= that it is going to do something - without the receiver being able to impa= ct that. Because, in case of the updated offer (no matter whether it's ICE or BAS), = it is often the receiver (or some intermediary) - not the sender - that kno= ws whether it's needed or not. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D47124EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

>Bundle Address Synchronization (BAS) is motivated = by almost the same >arguments that led to the ICE upda= ted offer/answer in 5245.

> 

>Now, at IETF 90 the updated offer/answer procedure= s for ICE were discussed >and the consensus was to change th= e existing behavior to:

>“ you do it (i.e. the updated offer/answer) = or don’t do it, but you indicate in >the o/a if you’re going to d= o it. Basically want to have option to never do the >updated O/A exchange, with an indi= cation in the signaling that you will not >be doing it. Of course can always = initiate a new O/A exchange whenever you >want to.”<= /p>

&n= bsp;

Actuall= y, that consensus is still to be confirmed on the list…

&n= bsp;

>I think the same discussion and obviously  it= s result also applies to BUNDLE >and BAS.

>Otherwise, if you use BUNDLE together with ICE, th= e updated offer/answer >cycle is back. <= /p>

>If the WG agrees, this would require some addition= al parameter/attribute in >the offer that indicates if BAS wi= ll be performed or not.

> 

>Some common approach for the updated offer/answer = issue might also be >justified.

>An obvious thought  would be if re-using the = same “thing” for ICE and >BUNDLE would be appropriate. =

>... and for CapNeg albeit its lack of deployment

&n= bsp;

In gene= ral, I prefer a negotiation model, rather than the sender indicating that i= t is going to do something – without the receiver being able to impac= t that.

&n= bsp;

Because= , in case of the updated offer (no matter whether it’s ICE or BAS), i= t is often the receiver (or some intermediary) – not the sender - tha= t knows whether it’s needed or not.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

--_000_7594FB04B1934943A5C02806D1A2204B1D47124EESESSMB209erics_-- From nobody Thu Oct 9 11:47:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96AF1A0356; Thu, 9 Oct 2014 11:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOzVFvSxkLKt; Thu, 9 Oct 2014 11:47:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E871A0313; Thu, 9 Oct 2014 11:47:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141009184705.20752.81026.idtracker@ietfa.amsl.com> Date: Thu, 09 Oct 2014 11:47:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/J8HGwPDQPujSrs8glDZy5aWPzsg Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 18:47:07 -0000 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 : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-12.txt Pages : 46 Date : 2014-10-09 Abstract: This specification defines a new SDP Grouping Framework extension, 'BUNDLE'. The extension can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple SDP media descriptions ("m="). This is referred to as bundled media. Both endpoints can negotiate the use of bundle and to support that negotiations, this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 to allows an answerer to assign a non-zero port value to an "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer contained a zero port value. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new RTP SDES item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 9 12:35:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF551A7020 for ; Thu, 9 Oct 2014 12:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kROHnvL9wZu6 for ; Thu, 9 Oct 2014 12:35:15 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 820311A7029 for ; Thu, 9 Oct 2014 12:35:14 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id A754823F046E; Thu, 9 Oct 2014 21:35:13 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 21:35:13 +0200 From: "Stach, Thomas" To: Christer Holmberg , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: Bundle Address Synchronization (BAS) Thread-Index: Ac/j0tcu2NruXxDsTEC0KS+v/a6o+AAHL98QAAFETAA= Date: Thu, 9 Oct 2014 19:35:13 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D47124E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47124E@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E229362MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/9OYD61HXgHqGZXxkW_9lqiN_FeA Cc: mmusic Subject: Re: [MMUSIC] bundle-11: Bundle Address Synchronization (BAS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 19:35:18 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E229362MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Donnerstag, 9. Oktober 2014 20:41 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: Bundle Address Synchronization (BAS) Hi, >Bundle Address Synchronization (BAS) is motivated by almost the same >argu= ments that led to the ICE updated offer/answer in 5245. > >Now, at IETF 90 the updated offer/answer procedures for ICE were discussed= >and the consensus was to change the existing behavior to: >" you do it (i.e. the updated offer/answer) or don't do it, but you indica= te in >the o/a if you're going to do it. Basically want to have option to n= ever do the >updated O/A exchange, with an indication in the signaling that= you will not >be doing it. Of course can always initiate a new O/A exchang= e whenever you >want to." Actually, that consensus is still to be confirmed on the list... [TS] Well, according to the minutes my understanding is that the chairs alr= eady declared consensus. But that's chair's business where I don't want to interfere. >I think the same discussion and obviously its result also applies to BUND= LE >and BAS. >Otherwise, if you use BUNDLE together with ICE, the updated offer/answer >= cycle is back. >If the WG agrees, this would require some additional parameter/attribute i= n >the offer that indicates if BAS will be performed or not. > >Some common approach for the updated offer/answer issue might also be >jus= tified. >An obvious thought would be if re-using the same "thing" for ICE and >BUN= DLE would be appropriate. >... and for CapNeg albeit its lack of deployment In general, I prefer a negotiation model, rather than the sender indicating= that it is going to do something - without the receiver being able to impa= ct that. [TS] I wouldn't necessarily object to having such a negotiation but it adds= complexity. Apart from the additional complexity, the question to answer in that model = however is: "What is the fallback if negotiation fails?" Is it "do the extra offer/answer" or "omit the additional offer/answer"? My preference would be omitting. Therefore, I can live quite well with the = IETF 90 outcome. Others might prefer doing the extra offer/answer. Because, in case of the updated offer (no matter whether it's ICE or BAS), = it is often the receiver (or some intermediary) - not the sender - that kno= ws whether it's needed or not. [TS] Well, the receiver is free to send a new offer anytime. However, I hav= e issues with intermediaries that interfere in such a negotiation. Consider the case where you have two of them and both have different prefer= ences. Regards Thomas Regards, Christer --_000_F81CEE99482EFE438DAE2A652361EE121E229362MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Donnerstag, 9. Oktober 2014 20:41
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: Bundle Address Synchronization (BAS)

 

Hi,

&n= bsp;

>Bundle Addr= ess Synchronization (BAS) is motivated by almost the same >arguments that led to the ICE upda= ted offer/answer in 5245.

> =

>Now, at IET= F 90 the updated offer/answer procedures for ICE were discussed >and the consensus was to change th= e existing behavior to:

>“ you= do it (i.e. the updated offer/answer) or don’t do it, but you indica= te in >the o/a if you’re going to d= o it. Basically want to have option to never do the >updated O/A exchange, with an indi= cation in the signaling that you will not >be doing it. Of course can always = initiate a new O/A exchange whenever you >want to.”

 

Actually, that consens= us is still to be confirmed on the list…

[TS] Well, accor= ding to the minutes my understanding is that the chairs already declared co= nsensus.

But that’s= chair’s business where I don’t want to interfere.

 

>I think the= same discussion and obviously  its result also applies to BUNDLE >and BAS.

>Otherwise, = if you use BUNDLE together with ICE, the updated offer/answer >cycle is back.

>If the WG a= grees, this would require some additional parameter/attribute in >the offer that indicates if BAS wi= ll be performed or not.

> =

>Some common= approach for the updated offer/answer issue might also be >justified.

>An obvious = thought  would be if re-using the same “thing” for ICE and >BUNDLE would be appropriate. =

>... and for= CapNeg albeit its lack of deployment

 

In general, I prefer a= negotiation model, rather than the sender indicating that it is going to d= o something – without the receiver being able to impact that.

[TS] I wouldn= 217;t necessarily object to having such a negotiation but it adds complexit= y.

Apart from the a= dditional complexity, the question to answer in that model however is: R= 20;What is the fallback if negotiation fails?”<= /b>

Is it “do = the extra offer/answer” or “omit the additional offer/answer= 221;?

My preference wo= uld be omitting. Therefore, I can live quite well with the IETF 90 outcome.=

Others might pre= fer doing the extra offer/answer.

 

Because, in case of th= e updated offer (no matter whether it’s ICE or BAS), it is often the = receiver (or some intermediary) – not the sender - that knows whether= it’s needed or not.

[TS] Well, the r= eceiver is free to send a new offer anytime. However, I have issues with in= termediaries that interfere in such a negotiation.

Consider the cas= e where you have two of them and both have different preferences.

 

Regards

Thomas

 

Regards,

 

Christer

--_000_F81CEE99482EFE438DAE2A652361EE121E229362MCHP04MSXglobal_-- From nobody Thu Oct 9 12:50:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547221A1A14 for ; Thu, 9 Oct 2014 12:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVaoaUm7pjKm for ; Thu, 9 Oct 2014 12:50:12 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5930C1A0396 for ; Thu, 9 Oct 2014 12:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13950; q=dns/txt; s=iport; t=1412884212; x=1414093812; h=message-id:date:from:mime-version:to:cc:subject; bh=t9psc93JNDHjCyLVFHZN0mGCP5vtEoi7/BRjLXu6tdw=; b=NKn0MIjxQOK4DKnf8nNvK13Blaadn++88VIzkFPJXGLMmT2f1Sp786Pf x5PDECHHOuYzIIFgoxJ9ReHqqHPXIDjKvyy7TTvLN4xYCZGWkMLYgaopM ZAlkQnuajJ5OjfxpxQrL7i2ayBniQqpyd1yQCMaSXrIEec9wYYIRAyHqB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8LAD/mNlStJV2P/2dsb2JhbABggw5TUwWIYa5/AQEBBQEFbpI/h0uBCxYBe4QnWwE8FhgDAgECAUsNAQcBAQWINQgFwwQBF4YgiiQQhEIFljuHEIEuPIMKgnKOK4N/IS+CSgEBAQ X-IronPort-AV: E=Sophos; i="5.04,686,1406592000"; d="scan'208,217"; a="85549065" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP; 09 Oct 2014 19:50:11 +0000 Received: from [10.98.149.205] (bxb-fandreas-88112.cisco.com [10.98.149.205]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s99JoAPo023077; Thu, 9 Oct 2014 19:50:10 GMT Message-ID: <5436E6F2.2010202@cisco.com> Date: Thu, 09 Oct 2014 15:50:10 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------010805090109080302020901" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/K-aCk2Ken7OpwMN5V-_0opbDkJQ Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , "mmusic-chairs@tools.ietf.org" Subject: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 09 Oct 2014 19:50:14 -0000 This is a multi-part message in MIME format. --------------010805090109080302020901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for draft-ietf-mmusic-sdp-bundle-negotiation-12 as Proposed Standard. Please review and provide any comments you may have on the document by Friday, October 24, 2014. 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 : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-12.txt Pages : 46 Date : 2014-10-09 Abstract: This specification defines a new SDP Grouping Framework extension, 'BUNDLE'. The extension can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple SDP media descriptions ("m="). This is referred to as bundled media. Both endpoints can negotiate the use of bundle and to support that negotiations, this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 to allows an answerer to assign a non-zero port value to an "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer contained a zero port value. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new RTP SDES item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --------------010805090109080302020901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is to announce a 2 week Working Group Last Call for

        draft-ietf-mmusic-sdp-bundle-negotiation-12    

as Proposed Standard. Please review and provide any comments you may have on the document by Friday, October 24, 2014. 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           : Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
        Authors         : Christer Holmberg
                          Harald Tveit Alvestrand
                          Cullen Jennings
	Filename        : draft-ietf-mmusic-sdp-bundle-negotiation-12.txt
	Pages           : 46
	Date            : 2014-10-09

Abstract:
   This specification defines a new SDP Grouping Framework extension,
   'BUNDLE'.  The extension can be used with the Session Description
   Protocol (SDP) Offer/Answer mechanism to negotiate the usage of a
   single 5-tuple for sending and receiving media associated with
   multiple SDP media descriptions ("m=").  This is referred to as
   bundled media.

   Both endpoints can negotiate the use of bundle and to support that
   negotiations, this specification defines a new SDP attribute,
   'bundle-only', which can be used to request that specific media is
   only used if bundled.  This specification also updates sections 5.1,
   8.1 and 8.2 of RFC 3264 to allows an answerer to assign a non-zero
   port value to an "m=" line in an SDP answer, even if the "m=" line in
   the associated SDP offer contained a zero port value.

   There are multiple ways to correlate the bundled RTP packets with the
   appropriate media descriptions.  This specification defines a new RTP
   SDES item and a new RTP header extension that provides an additional
   way to do this correlation by using them to carry a value that
   associates the RTP/RTCP packets with a specific media description.


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
--------------010805090109080302020901-- From nobody Fri Oct 10 03:18:25 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2ED1A897A for ; Fri, 10 Oct 2014 03:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lXTHIIe6UQr for ; Fri, 10 Oct 2014 03:18:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D301A8984 for ; Fri, 10 Oct 2014 03:18:20 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-2a-5437b26af3ac Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B3.A1.24955.A62B7345; Fri, 10 Oct 2014 12:18:18 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.174.1; Fri, 10 Oct 2014 12:18:18 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 459421102AD; Fri, 10 Oct 2014 13:18:18 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2AC584E98A; Fri, 10 Oct 2014 13:20:17 +0300 (EEST) Received: from aris-mbp-2.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D822E4E695; Fri, 10 Oct 2014 13:20:16 +0300 (EEST) Message-ID: <5437B23D.4020502@ericsson.com> Date: Fri, 10 Oct 2014 13:17:33 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW7WJvMQg/szjC3eX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfH2xGWWgumcFTdvr2BuYFzO3sXIySEhYCKx 4s0uVghbTOLCvfVsILaQwFFGiS1nc7sYuYDsDYwSR1o6GCGcvYwSPz8/YYZw1jFKTNn3lB3O OT1vKlg/r4C2xJRj91lAbBYBVYnFdxcxgdhsArYSq1/dBIpzcIgKJEsc/+MDUS4ocXLmE7By EQEZib2bNjOD2MxAY2bfmQXWKiygLvGwp4cFIm4hMXP+eUYIW15i+9s5zBAvqElcPbeJGeIF VYmr/14xTmAUnoVkxSwk7bOQtC9gZF7FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERjgB7f8 Vt3BePmN4yFGAQ5GJR7eBbbmIUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgdH86bNZ/4K7dm+9cXYr95crz3/qqIdkpaYWHXyWJbIy0uBzqELo15nHbU+p /jj+pEUyoF36JP+ZXYnLfgnyypg/mVAWH3sn/f/3jxvXbGmolL6RFOsrOadjJueC+WxLbO/e ivPLr/8uZjV/veBK25JoazbpJNb3RQ6v38/m3SAkcnda0c/n+m1KLMUZiYZazEXFiQBcFebr UQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vEuhc5rKDLUQuDp_tdI9IkvYLJs Cc: Flemming Andreasen Subject: [MMUSIC] The RFC Style Guide (RFC 7322) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 10:18:23 -0000 Hi all, Please note that a new RFC style guide, RFC 7322, has been published (see below and https://tools.ietf.org/html/rfc7322). Draft authors, in order to process your documents smoothly through the system, please make sure that all your drafts follow the updated guidelines. Thanks, Ari & Flemming --- Subject: The RFC Style Guide (RFC 7322) Date: Fri, 26 Sep 2014 11:56:13 -0700 From: RFC Editor > Greetings, > > RFC 7322, "RFC Style Guide", has been published. This document > obsoletes RFC 2223 and other style information previously provided. > Please review the complete set of style guidelines impacting the RFC > series that is available here: > > http://www.rfc-editor.org/styleguide.html > > With the publication of the new RFC Style Guide, the RFC Editor will > be enforcing the guidance set forth in RFC 7322. This applies to > documents currently in process, including those in AUTH48. The > documents will be updated and authors will be notified of that the > updates are ready for review. Please be sure to review the udpates > carefully. > > Thank you, > RFC Editor Team > > From nobody Fri Oct 10 13:47:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1B1AD1DB for ; Fri, 10 Oct 2014 13:47:07 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaEUt68K-efn for ; Fri, 10 Oct 2014 13:47:06 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1D91AD1A6 for ; Fri, 10 Oct 2014 13:47:05 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id d1so3165607wiv.12 for ; Fri, 10 Oct 2014 13:47:04 -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=SdCn6/3N50kb5dXoz41kvwvTWP0DWTcYC0UP4LiToLY=; b=uzWtOKGnr2Jc9af08Q9TUwL8Sf69AMxMI4fazDxw8sAZ+CLwi0trD3iLN/+QFUcjcu dznA1lYddpLNLxengx2xFzkMhzNVxmXBB3g47xQH2E1jMjC8rzQfQbW/Ay+5t6Uai4ev beDEhpcBDfOIDvSsxlcIkUsBqjF91OlCMBTlEFSfZq/n7xJffZlou45DZVW2QGNsns9x ywu53liz+AxCXomlEafnmJ+9LkJAeWaASr5KZ4UD31tzQEofHofJGmpzAHv4iY2qyaJf eYKA7uVDK3e40HzXgq3KhS5NUHXznflS6phRir1e8zgN1z30VHmOzH63+pnIc3AspphD 8b8w== MIME-Version: 1.0 X-Received: by 10.180.188.102 with SMTP id fz6mr6884408wic.61.1412974024504; Fri, 10 Oct 2014 13:47:04 -0700 (PDT) Received: by 10.194.60.134 with HTTP; Fri, 10 Oct 2014 13:47:04 -0700 (PDT) Date: Fri, 10 Oct 2014 13:47:04 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=001a11c37b9acebc0b050517a60a Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/frd8lZORGMBsI3eXRtDNsmQGwfc Subject: [MMUSIC] New Draft: draft-nandakumar-mmusic-proto-iana-registration-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 20:47:07 -0000 --001a11c37b9acebc0b050517a60a Content-Type: text/plain; charset=UTF-8 Hello All We submitted a new draft to register IANA SDP proto attributes to capture RTP over TCP transport with TLS and SAVP(F ) variants. Link: http://tools.ietf.org/html/draft-nandakumar-mmusic-proto-iana-registration-00 Please let us know your thoughts. Cheers Suhas --001a11c37b9acebc0b050517a60a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 We submitted a new dra= ft to register IANA SDP proto attributes to capture RTP over TCP transport = with TLS and SAVP(F ) variants.


Please let us know your thoughts.
<= div>
Cheers
Suhas =C2=A0
--001a11c37b9acebc0b050517a60a-- From nobody Fri Oct 10 14:47:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00801A87ED for ; Fri, 10 Oct 2014 14:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BDqcWEH5vaf for ; Fri, 10 Oct 2014 14:47:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504EF1A884F for ; Fri, 10 Oct 2014 14:47:24 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-c2-543853eaaaa8 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.77.24955.AE358345; Fri, 10 Oct 2014 23:47:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 23:47:21 +0200 From: Christer Holmberg To: "Stach, Thomas" , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: Bundle Address Synchronization (BAS) Thread-Index: Ac/j0tcu2NruXxDsTEC0KS+v/a6o+AAHL98QAAFETAAAN7eEAA== Date: Fri, 10 Oct 2014 21:47:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D475A98@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47124E@ESESSMB209.ericsson.se> 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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D475A98ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvje6rYIsQg1V75Sw6JrNZHOvrYrOY uvwxi8XJnduYHVg8rky4wuox5fdGVo8lS34yeWzvecwSwBLFZZOSmpNZllqkb5fAlfH0cz9r wQWzitdr7jI3MF7X72Lk5JAQMJFoPHuMDcIWk7hwbz2QzcUhJHCUUWLV362MEM4SRoknjedZ uxg5ONgELCS6/2mDxEUE2hkl/h89xQrSzSwgIzHjbCMTiC0sYCtxdlUbM0i9iICdxPaHuSBh EQEniYUzZ4EtYxFQlTjyvYEFxOYV8JU4eHAqK8Su64wSUw4cBZvJKeAvsffMerCZjEDXfT+1 hglil7jErSfzmSCuFpBYsuc8M4QtKvHy8T9WCFtJYsX2S4wQ9fkSlxpeMEIsE5Q4OfMJywRG 0VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFqclJtuZKyXWpSZ XFycn6eXl1qyiREYlwe3/FbdwXj5jeMhRgEORiUe3gW25iFCrIllxZW5hxilOViUxHkXnpsX LCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRd+fKxZOfev67/i140sxpAUdWJxpNudDkGZ3t PK9O68/8v57H33gyWF5MfPHh6ayf6+LiNijIiZ/YxfaT9XrAnA/75u/7JFAgcWdC4bJ7PhXt 1/es3vJ9cd2ijUzyOvfW3r6ptNixJ+iDifhb/W0bJ/nVyfR6nZZ9HamQd821MK850WKehBZH jxJLcUaioRZzUXEiAAPpbbqsAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vYGycWbV-p-zZ0kBSEkBsjWbLvE Cc: mmusic Subject: Re: [MMUSIC] bundle-11: Bundle Address Synchronization (BAS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 10 Oct 2014 21:47:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D475A98ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In general, I prefer a negotiation model, rather than the sender indicating= that it is going to do something - without the receiver being able to impa= ct that. [TS] I wouldn't necessarily object to having such a negotiation but it adds= complexity. Apart from the additional complexity, the question to answer in that model = however is: "What is the fallback if negotiation fails?" Is it "do the extra offer/answer" or "omit the additional offer/answer"? My preference would be omitting. Therefore, I can live quite well with the = IETF 90 outcome. Others might prefer doing the extra offer/answer. Because, in case of the updated offer (no matter whether it's ICE or BAS), = it is often the receiver (or some intermediary) - not the sender - that kno= ws whether it's needed or not. [TS] Well, the receiver is free to send a new offer anytime. However, I hav= e issues with intermediaries that interfere in such a negotiation. Consider the case where you have two of them and both have different prefer= ences. It is the receiver, not the sender, that possible needs the second offer. S= o, while I agree a negotiation may not be needed, I think we should at leas= t let the receiver decided whether the offerer should send it or not. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D475A98ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

In gene= ral, I prefer a negotiation model, rather than the sender indicating that i= t is going to do something – without the receiver being able to impac= t that.

[= TS] I wouldn’t necessarily object to having such a negotiation but it= adds complexity.

A= part from the additional complexity, the question to answer in that model h= owever is: “What is the fallback if negotiation fails?”

I= s it “do the extra offer/answer” or “omit the additional = offer/answer”?

M= y preference would be omitting. Therefore, I can live quite well with the I= ETF 90 outcome.

O= thers might prefer doing the extra offer/answer.<= /p>

&n= bsp;

Because= , in case of the updated offer (no matter whether it’s ICE or BAS), i= t is often the receiver (or some intermediary) – not the sender - tha= t knows whether it’s needed or not.

[= TS] Well, the receiver is free to send a new offer anytime. However, I have= issues with intermediaries that interfere in such a negotiation.

C= onsider the case where you have two of them and both have different prefere= nces.

<= o:p> 

It is= the receiver, not the sender, that possible needs the second offer. So, wh= ile I agree a negotiation may not be needed, I think we should at least let= the receiver decided whether the offerer should send it or not.

=  

Regar= ds,

=  

Chris= ter

--_000_7594FB04B1934943A5C02806D1A2204B1D475A98ESESSMB209erics_-- From nobody Fri Oct 10 22:56:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8151A1AE0 for ; Fri, 10 Oct 2014 22:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPktAMULIYue for ; Fri, 10 Oct 2014 22:55:59 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E20F1A1AB3 for ; Fri, 10 Oct 2014 22:55:59 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so5418807wgh.16 for ; Fri, 10 Oct 2014 22:55:58 -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=GP/5iSXJDdnfK+lral4Kq47YfdzIvlzIAGqmHuZUQ4A=; b=GonZ3jLLJIp+838bWVVM0iIw//TjABMKaDBDrU6AvEQQiBlhvI1hfFGUJWpkkc+r5l InauMG72dIJ1dmSpZoQx6Ga+SgylyWULKfyqygQt0qzVdcUeOa7guLuK7Rt78Qr/AnTr B+6p4UcS/7Cf+EzFzh0caoO/CYxPkDrQKuJRAV9T5YCjbTgGNsatXpWYyyhE5jzhKTCS TvgpNd7IfCjNKx0kKjy6FzGjTBmvwLiWeu1XMFP5gQVxpB0VUn9W6NbPtsuNJ7F3Gd54 C0v4/G9Zgnyw4QGNamIVD0BWbIMHCrX6MQE8m16Ijgsg8AJmuEzJ4g3Xs+FOtO3b0mF4 wEJg== MIME-Version: 1.0 X-Received: by 10.180.91.52 with SMTP id cb20mr8619897wib.61.1413006958201; Fri, 10 Oct 2014 22:55:58 -0700 (PDT) Received: by 10.194.60.134 with HTTP; Fri, 10 Oct 2014 22:55:58 -0700 (PDT) Date: Fri, 10 Oct 2014 22:55:58 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=f46d0438eeafcf101505051f517c Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/AmX783XBLim1TLvMf4rGwrMcCwQ Subject: [MMUSIC] SDP Attributes Multiplexing - WGLC and the way forward X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 05:56:01 -0000 --f46d0438eeafcf101505051f517c Content-Type: text/plain; charset=UTF-8 Hello All Given that we are very close to get the SDP Attributes Mux draft to WGLC, the following is a proposal on how we can deal with the new attributes that might get added between now and the time the draft gets published. The proposal: - Around or Soon after IETF91 , I plan to check for the WGLC status of the draft and freeze analysis of new SDP attributes that might get added till the draft gets published - Once the draft gets published, a new draft (similar to this) will be published to analyzing the multiplexing behavior of the SDP attributes that were added to fill in the above gap. The main idea here is to avoid chasing to-be-proposed and/or new SDP attributes, which might block the progress of this draft. Please let me know your thoughts on the same. Cheers Suhas --f46d0438eeafcf101505051f517c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0Given that we are very = close to get the SDP Attributes Mux draft to WGLC, the following is a propo= sal on how we can deal with the new attributes that might get added between= now and the time the draft gets published.


The proposal:
=C2=A0- Around or Soon after IETF91 , I pl= an to check for the WGLC status of the draft and freeze analysis of new SDP= attributes that might get added till the draft gets published
- Once the draft gets published, a new draft (similar to this)= will be published to analyzing the multiplexing behavior of the SDP attrib= utes that were added to fill in the above gap.

The= main idea here is to avoid chasing to-be-proposed and/or new SDP attribute= s, which might block the progress of this draft.

P= lease let me know your thoughts on the same.

Cheer= s
Suhas

--f46d0438eeafcf101505051f517c-- From nobody Sat Oct 11 06:25:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E011A1BEA for ; Sat, 11 Oct 2014 06:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXOzg5k-4Jwq for ; Sat, 11 Oct 2014 06:25:27 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC66B1A1BE6 for ; Sat, 11 Oct 2014 06:25:25 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-03v.sys.comcast.net with comcast id 1pR91p00T4tLnxL01pRRJ6; Sat, 11 Oct 2014 13:25:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-02v.sys.comcast.net with comcast id 1pRQ1p00G3Ge9ey01pRRuV; Sat, 11 Oct 2014 13:25:25 +0000 Message-ID: <54392FC4.7070300@alum.mit.edu> Date: Sat, 11 Oct 2014 09:25:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413033925; bh=9/RYOqo+Jfunb+wpaIJhAUfxKG73xj5mx4kZGatOZjE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bOffZJiKM2N0WLgx0QJnp82UoWGEim5sHQVQFqiStVWxVKXWb2iRQnokpQeaU8jbR wD+UJHKvsdgFhVUJgvLnY0zb9IAwa/RmpfMCH5lyiQHXcUqs7IneT6zcKAkh6D9nGD Nn6JPHZLImdMn+ZXVgdjXbt5qRcVSkojKaJvghIE9Kn22vADpv1rBF9cqclReBTPkC w6F15Zy/nPVgf0W2S9be+gATb2WC7W6Oh7UmjJmGXQyWWN76HnvET0uWJMnkcmjZYL ulYCVtVWxY+IMVE2yrETVg+phFrO+xYYE+liyE3uZbqvoyLyebSw0G9PcYRYk9NXJY IerfQWxN0c1AA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vE8B37KLOKNERQ0g-H2OALhLKGg Subject: Re: [MMUSIC] SDP Attributes Multiplexing - WGLC and the way forward X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 11 Oct 2014 13:25:29 -0000 On 10/11/14 1:55 AM, Suhas Nandakumar wrote: > Hello All > > Given that we are very close to get the SDP Attributes Mux draft to > WGLC, the following is a proposal on how we can deal with the new > attributes that might get added between now and the time the draft gets > published. > > > The proposal: > - Around or Soon after IETF91 , I plan to check for the WGLC status of > the draft and freeze analysis of new SDP attributes that might get added > till the draft gets published Sounds good. > - Once the draft gets published, a new draft (similar to this) will be > published to analyzing the multiplexing behavior of the SDP attributes > that were added to fill in the above gap. Rather than that, I suggest that then any drafts held get an SDP review, and that it push back on those drafts to add the multiplexing behavior to those drafts before they are approved. Thanks, Paul > The main idea here is to avoid chasing to-be-proposed and/or new SDP > attributes, which might block the progress of this draft. > > Please let me know your thoughts on the same. > > Cheers > Suhas > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Sat Oct 11 20:49:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F241A8848 for ; Sat, 11 Oct 2014 20:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqcvJDwHNUls for ; Sat, 11 Oct 2014 20:49:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183D11A8847 for ; Sat, 11 Oct 2014 20:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1512; q=dns/txt; s=iport; t=1413085778; x=1414295378; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=md7EK2kPo/x01BVVvoU145g4ATz2slQdqlpt+EwJ3Do=; b=mWLEXefgbK+Co6FtpO0Pp6BUHdd15DPvv15q6j8/mhmFXqja7ZmVhkO4 5/mYQySu5yCD3tFJ6PkL8tWXXvpg4LtqTNKfbgiXuKON4O096RAUEe8w3 OD91ZWBoyPpUA5CBFfXtjgsdqk5FtSB6UkfmbiDd2q9JyQHrX6Ezk4AX3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAIH5OVStJA2N/2dsb2JhbABagmsjU1zKcQqGeVQCgQUWAX2EAwEBAwEBAQE3NAsFCwIBCDYQIQYLJQIEDgWIKgMJCAEMuUMNhmkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI4TgX8zB4MtgR4FkXmJQYIRgS6DRooHQoJWg36Dd2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,703,1406592000"; d="scan'208";a="362583509" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2014 03:49:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9C3nbWt007353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 Oct 2014 03:49:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sat, 11 Oct 2014 22:49:37 -0500 From: "Ali C. Begen (abegen)" To: Suhas Nandakumar Thread-Topic: [MMUSIC] SDP Attributes Multiplexing - WGLC and the way forward Thread-Index: AQHP5RgQwUB+r9CkdEeHVHywdpquwpwsKLYA Date: Sun, 12 Oct 2014 03:49:36 +0000 Message-ID: <7892CF7E-A651-4516-8B39-5176A44E1BC2@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.170] Content-Type: text/plain; charset="us-ascii" Content-ID: <864E9DA181E81D499C8001D817DB399C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Fb1PAWc6v54F-PG0q2OwWgfbZi4 Cc: mmusic WG Subject: Re: [MMUSIC] SDP Attributes Multiplexing - WGLC and the way forward X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 12 Oct 2014 03:49:39 -0000 I am soon planning to submit a draft that will seek making the changes we n= eed in the IANA registries for the 4566bis. I am keeping this draft separat= e from the 4566bis as the bis document has seen substantial changes recentl= y and needs a through review, and we need the IANA updates sooner. I am hoping this IANA update draft will progress quite smoothly and can be = processed along yours. On Oct 11, 2014, at 8:55 AM, Suhas Nandakumar wrote: > Hello All >=20 > Given that we are very close to get the SDP Attributes Mux draft to WGLC= , the following is a proposal on how we can deal with the new attributes th= at might get added between now and the time the draft gets published. >=20 >=20 > The proposal: > - Around or Soon after IETF91 , I plan to check for the WGLC status of t= he draft and freeze analysis of new SDP attributes that might get added til= l the draft gets published >=20 > - Once the draft gets published, a new draft (similar to this) will be pu= blished to analyzing the multiplexing behavior of the SDP attributes that w= ere added to fill in the above gap. >=20 > The main idea here is to avoid chasing to-be-proposed and/or new SDP attr= ibutes, which might block the progress of this draft. >=20 > Please let me know your thoughts on the same. >=20 > Cheers > Suhas >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Oct 13 01:31:54 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF1D1A0043 for ; Mon, 13 Oct 2014 01:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdyoJxsUlWG1 for ; Mon, 13 Oct 2014 01:31:52 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7F71A02A0 for ; Mon, 13 Oct 2014 01:31:52 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 72FE91EB848A; Mon, 13 Oct 2014 10:31:51 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 10:31:48 +0200 From: "Stach, Thomas" To: Christer Holmberg , Harald Alvestrand , "Cullen Jennings (fluffy)" Thread-Topic: bundle-11: Bundle Address Synchronization (BAS) Thread-Index: Ac/j0tcu2NruXxDsTEC0KS+v/a6o+AAHL98QAAFETAAAN7eEAAB5Wg4w Date: Mon, 13 Oct 2014 08:31:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D47124E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D475A98@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D475A98@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E22A5CDMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/StwVW2fl7NUCDqDqS888e_kGUhI Cc: mmusic Subject: Re: [MMUSIC] bundle-11: Bundle Address Synchronization (BAS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2014 08:31:54 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E22A5CDMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable inline From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Freitag, 10. Oktober 2014 23:47 To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy) Cc: mmusic Subject: RE: bundle-11: Bundle Address Synchronization (BAS) Hi, In general, I prefer a negotiation model, rather than the sender indicating= that it is going to do something - without the receiver being able to impa= ct that. [TS] I wouldn't necessarily object to having such a negotiation but it adds= complexity. Apart from the additional complexity, the question to answer in that model = however is: "What is the fallback if negotiation fails?" Is it "do the extra offer/answer" or "omit the additional offer/answer"? My preference would be omitting. Therefore, I can live quite well with the = IETF 90 outcome. Others might prefer doing the extra offer/answer. Because, in case of the updated offer (no matter whether it's ICE or BAS), = it is often the receiver (or some intermediary) - not the sender - that kno= ws whether it's needed or not. [TS] Well, the receiver is free to send a new offer anytime. However, I hav= e issues with intermediaries that interfere in such a negotiation. Consider the case where you have two of them and both have different prefer= ences. It is the receiver, not the sender, that possible needs the second offer. S= o, while I agree a negotiation may not be needed, I think we should at leas= t let the receiver decided whether the offerer should send it or not. [TS] I think it is crucial having this aligned for BUNDLE and ICE. However, for ICE the consensus on updated offer/answer handling was differe= nt and I think it is the better approach. Both sides, sender and receiver, might have their reasons why they want to = send the update or omit the update. Prescribing what the other end must do can easily conflict with these reaso= ns and lead to unwanted side effects. Thus I still prefer this approach as discussed in IETF90 "The offerer/sende= r says what is does". The sender can then react as it needs. Regards Thomas Regards, Christer --_000_F81CEE99482EFE438DAE2A652361EE121E22A5CDMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

inline

 

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Freitag, 10. Oktober 2014 23:47
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: Bundle Address Synchronization (BAS)

 

Hi,

 

In general, I prefer a= negotiation model, rather than the sender indicating that it is going to d= o something – without the receiver being able to impact that.

[TS] I wouldn’t = necessarily object to having such a negotiation but it adds complexity.

Apart from the additio= nal complexity, the question to answer in that model however is: “Wha= t is the fallback if negotiation fails?”

Is it “do the ex= tra offer/answer” or “omit the additional offer/answer”?

My preference would be= omitting. Therefore, I can live quite well with the IETF 90 outcome.<= /o:p>

Others might prefer do= ing the extra offer/answer.

 

Because, in case of th= e updated offer (no matter whether it’s ICE or BAS), it is often the = receiver (or some intermediary) – not the sender - that knows whether= it’s needed or not.

[TS] Well, the receive= r is free to send a new offer anytime. However, I have issues with intermed= iaries that interfere in such a negotiation.

Consider the case wher= e you have two of them and both have different preferences.

 

It is the receiver, = not the sender, that possible needs the second offer. So, while I agree a n= egotiation may not be needed, I think we should at least let the receiver d= ecided whether the offerer should send it or not.

[TS] I think it = is crucial having this aligned for BUNDLE and ICE.

However, for ICE= the consensus on updated offer/answer handling was different and I think i= t is the better approach.

Both sides, send= er and receiver, might have their reasons why they want to send the update = or omit the update.

Prescribing what= the other end must do can easily conflict with these reasons and lead to u= nwanted side effects.

Thus I still pre= fer this approach as discussed in IETF90 “The offerer/sender  sa= ys what is does”. The sender can then react as it needs.

Regards

Thomas

 

Regards,<= /span>

 

Christer<= /span>

--_000_F81CEE99482EFE438DAE2A652361EE121E22A5CDMCHP04MSXglobal_-- From nobody Tue Oct 14 01:15:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9971A6FCB for ; Tue, 14 Oct 2014 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tKeKhoRoFNO for ; Tue, 14 Oct 2014 01:15:20 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C158D1A6FCD for ; Tue, 14 Oct 2014 01:15:16 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-02-543cdb92eb9b Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.78.24955.29BDC345; Tue, 14 Oct 2014 10:15:14 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.174.1; Tue, 14 Oct 2014 10:15:14 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4DA001102AD for ; Tue, 14 Oct 2014 11:15:14 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 748C54E98A for ; Tue, 14 Oct 2014 11:17:18 +0300 (EEST) Received: from aris-mbp-2.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 33F944E695 for ; Tue, 14 Oct 2014 11:17:18 +0300 (EEST) Message-ID: <543CDB90.7050509@ericsson.com> Date: Tue, 14 Oct 2014 11:15:12 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvje6k2zYhBouPGVlMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGee+TGcsuMdW8WDrPJYGxhWsXYycHBICJhKreidA2WISF+6t Z+ti5OIQEjjKKHFvXTMzhLOBUeLto6lQzmVGiYcvP7NCOEcYJT6sucII59w4d4MRZBivgLbE 01UrwGwWAVWJdztbWUBsNgFbidWvbgLZHByiAskSx//4QJQLSpyc+QSsRERARmLvps3MILaw gJTEhd+z2EFsZgELiZnzzzNC2PIS29/OYYa4W03i6rlNYLYQ0Kqr/14xTmAUmoVk7Cwk7bOQ tC9gZF7FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERi4B7f8Vt3BePmN4yFGAQ5GJR7eBc02 IUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFLfQZ/7rv9 MbMYPn1dsbLE/wrPm5Sqh8ppfVOu6nKtOPMo+eVy11Lne+6FaWvWvJnFlz95Scyv2ospJxbm 8aVurHNcftHiSp36zAkh1wwDykS3b1x58Ja+8p31ulzf5vswnbiqmLVUlDf+45XrCh/WWWn9 Xql38iCH64TT5xYYvf/7s+RYYftNJZbijERDLeai4kQAzgiwwD0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2FmDLAfhUhQAhlmCZyxmKNmFYxc Subject: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 08:15:25 -0000 Hi all, At the Toronto meeting we discussed whether we should change the behavior with ICE updated offer. Currently, based on RFC 5245, when ICE has finished, there is a new offer/answer with the selected candidate, *if* they are different from the "default candidates", i.e., the ones in original o/a m- and c-lines. Based on the discussion there was strong desire to have an option of not doing the updated o/a at all by indicating this in the original o/a. On the other hand, for some, the updated o/a was seen as a requirement for getting correct behavior from the network in certain scenarios (e.g., with SIP-aware middle boxes). I would like to hear from people, who have issues making the updated o/a optional, how bad the change would be and is there a way we could make this work also in those scenarios? Cheers, Ari From nobody Tue Oct 14 01:44:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CAC1A00F0 for ; Tue, 14 Oct 2014 01:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5wXgM7UgAP1 for ; Tue, 14 Oct 2014 01:44:03 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609001A0035 for ; Tue, 14 Oct 2014 01:44:03 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-2f-543ce2510377 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F3.C0.04387.152EC345; Tue, 14 Oct 2014 10:44:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 10:44:01 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTA Date: Tue, 14 Oct 2014 08:44:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> In-Reply-To: <543CDB90.7050509@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW7gI5sQg9kX5C2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNmzrrAU/OKvWL72PWMD40ueLkZODgkBE4nV7R8ZIWwxiQv3 1rN1MXJxCAkcZZQ43rqAHcJZwijR1dgI5HBwsAlYSHT/0wZpEBGIlPjZ940JJCwsoC4x5Z4C RFhDYsG1L4wgYREBI4kP3QEgYRYBVYkf/3Yxg4R5BXwlFpyxAgkLCWhLHHrdzgJicwroSFw7 2MAEYjMCXfP91Bowm1lAXOLWk/lMEFcKSCzZc54ZwhaVePn4HyuErSTxY8MlFoh6PYkbU6ew QdjaEssWvgar5xUQlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ6aUWZSYX F+fn6eWllmxiBEbDwS2/rXYwHnzueIhRgINRiYd3QbNNiBBrYllxZe4hRmkOFiVx3oXn5gUL CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYKx5oJWw+PvRDc7GXy+eXjlxc/zrhwEOnGu7XjYH Mp58Nb9sx9WPHt0Py2wuzSjuV1p3tGLycReZ1ncbtKMDNrDXclw6/8Eg1fH7OqPJyWyb59dd ZrDoEN0xY8scnQshkgV5oZNfvXuXarm7KuZcRPMX7k0/t+6e8NI15pjJpMSZ6g+kf+QY3JNU YinOSDTUYi4qTgQAmUgXDmcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9sdM Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 08:44:05 -0000 Hi, ISSUES: ---------- I think not doing the updated o/a (in case the SDP is not aligned with the = selected candidates) would cause serious problems in environments where you= have intermediaries etc that depend on correct SDP information, e.g. to op= en gates etc. SOLUTION SUGGESTION: --------------------------------- I DO understand that there are cases where the second o/a is not needed, ev= en if the SDP is not aligned with the selected candidates (as the endpoints= will get the information about selected candidates from the STUN messages)= . However, I don't think we can assume that the offerer knows when that is = the case.=20 So, if people don't want to keep the current rules, one alternative would t= o indicate in the ANSWER whether the second offer is needed or not.=20 Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen Sent: 14. lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated offer Hi all, At the Toronto meeting we discussed whether we should change the behavior w= ith ICE updated offer. Currently, based on RFC 5245, when ICE has finished,= there is a new offer/answer with the selected candidate, *if* they are different from the "default candidates", i.e., the ones in or= iginal o/a m- and c-lines. Based on the discussion there was strong desire to have an option of not do= ing the updated o/a at all by indicating this in the original o/a. On the o= ther hand, for some, the updated o/a was seen as a requirement for getting = correct behavior from the network in certain scenarios (e.g., with SIP-awar= e middle boxes). I would like to hear from people, who have issues making the updated o/a op= tional, how bad the change would be and is there a way we could make this w= ork also in those scenarios? Cheers, Ari _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Oct 14 07:33:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F361A8880 for ; Tue, 14 Oct 2014 07:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKOnvF9zm4Gy for ; Tue, 14 Oct 2014 07:33:32 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109901A88C4 for ; Tue, 14 Oct 2014 07:32:59 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so10929465wgh.4 for ; Tue, 14 Oct 2014 07:32:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KcifdQi+uYqGBrQEUxDdvnCukgnbNszIyLfR8XnUaug=; b=ahDGi4yxWr0J8+XdaGkOtAjteUoTKRGwh1T4ZvCwZWiPOnBZm0L6lH1kPP8yYNNrP0 pvk20nWVz0UKu8LjXDRON/ymSh8h5eqWASMaQMcpLVOhvVkOtGwXMfJKnWmqeCZWtrCI z6dZ1/RxPJloWQcAXnNaHFcG3c1ojw0SL+eHcwFLzM8545xRwwp49RwObXFZCA6lvKS0 X1E8PYfWguhFadMTl7mRQMgiwvagxfF1ycWe5ZQv1Vdvr9zlgrFtU4onzR6866/FzDBJ o4xFjxGkTAzmPcr+ToMsEzDHtoZ6DD6LaqB7iSKq11kiIcJvAHQ9k25mgA065QsSYNaQ CWPw== X-Gm-Message-State: ALoCoQniw9onVnqGUZIDLFRfoqE0DUbiOZ/e3jF2B89qAsAj6370BQHIrVmXQcdrN04Kke6hT8ax X-Received: by 10.180.198.234 with SMTP id jf10mr4526179wic.68.1413297177461; Tue, 14 Oct 2014 07:32:57 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id td9sm15933731wic.15.2014.10.14.07.32.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 07:32:56 -0700 (PDT) Message-ID: <543D341A.3040006@jitsi.org> Date: Tue, 14 Oct 2014 16:32:58 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/B34qQwkyJW1gz5QrERzol5tS508 Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 14:33:39 -0000 On 14.10.14, 10:44, Christer Holmberg wrote: > Hi, > > ISSUES: ---------- > > I think not doing the updated o/a (in case the SDP is not aligned > with the selected candidates) would cause serious problems in > environments where you have intermediaries etc that depend on correct > SDP information, e.g. to open gates etc. Opening gates needs to happen from the first O/A though. Right? Otherwise ICE checks are not going to succeed. > SOLUTION SUGGESTION: --------------------------------- > > I DO understand that there are cases where the second o/a is not > needed, even if the SDP is not aligned with the selected candidates > (as the endpoints will get the information about selected candidates > from the STUN messages). However, I don't think we can assume that > the offerer knows when that is the case. > > So, if people don't want to keep the current rules, one alternative > would to indicate in the ANSWER whether the second offer is needed or > not. I don't really mind this (especially if the default is: don't send an update) ... but, I'd also like to understand the exact use case where this is necessary. The only one I can think of is a middle box that introduces relayed candidates. I don't find this to be a compelling arguments since that relay can simply timeout if necessary. I must be missing something obviously so ... looking forward to hearing examples Emil > > Regards, > > Christer > > > > -----Original Message----- From: mmusic > [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Keränen Sent: 14. > lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated offer > > Hi all, > > At the Toronto meeting we discussed whether we should change the > behavior with ICE updated offer. Currently, based on RFC 5245, when > ICE has finished, there is a new offer/answer with the selected > candidate, *if* they are different from the "default candidates", > i.e., the ones in original o/a m- and c-lines. > > Based on the discussion there was strong desire to have an option of > not doing the updated o/a at all by indicating this in the original > o/a. On the other hand, for some, the updated o/a was seen as a > requirement for getting correct behavior from the network in certain > scenarios (e.g., with SIP-aware middle boxes). > > I would like to hear from people, who have issues making the updated > o/a optional, how bad the change would be and is there a way we could > make this work also in those scenarios? > > > Cheers, Ari > > _______________________________________________ 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 > -- https://jitsi.org From nobody Tue Oct 14 08:19:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8F11A88F3 for ; Tue, 14 Oct 2014 08:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHqTfqVyftGw for ; Tue, 14 Oct 2014 08:19:14 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7A11A8791 for ; Tue, 14 Oct 2014 08:19:13 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so10438137wid.10 for ; Tue, 14 Oct 2014 08:19:12 -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=YEXq4wYhHOymO4AJmcsgqPAMGWMeQkmcp7a3HAQl/f8=; b=QGOlPDp8B5joGucHEZgKW+khZqHPPaN/mVDwN4+mDJEpHkZyeVeAAE32Q88gDT6/sl V2S3shEvG2iAuKZuweJjjhPS9YjwQcd6dYWrYfStpQMKCbNPdw/sDxNTOCBncX086WUm UuNnp5Qm0xijPFWzXoo3Pki0GwXJ/MI5VZYdU3txnD6CK748pkfe1xAnXEyEnPNITjPc aG7TqHbMW7ymC0tOx2DGqONmHCA1uEgQb7F/iReNeec0pOXhD/MVF2hpsSXzMVNc0y0S 4auzZC8oB0bMNGuK5Vh7n4jmwHeqiQ7MJ9tYyQ7uubWRgTw/QQqtt+tGtMCpg/d8cfCh QXEw== MIME-Version: 1.0 X-Received: by 10.180.9.65 with SMTP id x1mr6121422wia.30.1413299952002; Tue, 14 Oct 2014 08:19:12 -0700 (PDT) Received: by 10.194.60.134 with HTTP; Tue, 14 Oct 2014 08:19:11 -0700 (PDT) In-Reply-To: <543D341A.3040006@jitsi.org> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> Date: Tue, 14 Oct 2014 08:19:11 -0700 Message-ID: From: Suhas Nandakumar To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c245ca99ac2205056389b0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5ZNIRde15peknIQEX98JYoiCZFM Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Christer Holmberg Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:19:17 -0000 --001a11c245ca99ac2205056389b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable just trying to understand : What happens in the cases where the network interface has totally changed , say going from WiFi only to 3G only or something .. Don't we need to initiate new ICE checks and thus an update .. Thanks Suhas On Tue, Oct 14, 2014 at 7:32 AM, Emil Ivov wrote: > > > On 14.10.14, 10:44, Christer Holmberg wrote: > >> Hi, >> >> ISSUES: ---------- >> >> I think not doing the updated o/a (in case the SDP is not aligned >> with the selected candidates) would cause serious problems in >> environments where you have intermediaries etc that depend on correct >> SDP information, e.g. to open gates etc. >> > > Opening gates needs to happen from the first O/A though. Right? Otherwise > ICE checks are not going to succeed. > > SOLUTION SUGGESTION: --------------------------------- >> >> I DO understand that there are cases where the second o/a is not >> needed, even if the SDP is not aligned with the selected candidates >> (as the endpoints will get the information about selected candidates >> from the STUN messages). However, I don't think we can assume that >> the offerer knows when that is the case. >> >> So, if people don't want to keep the current rules, one alternative >> would to indicate in the ANSWER whether the second offer is needed or >> not. >> > > I don't really mind this (especially if the default is: don't send an > update) ... but, I'd also like to understand the exact use case where thi= s > is necessary. The only one I can think of is a middle box that introduces > relayed candidates. I don't find this to be a compelling arguments since > that relay can simply timeout if necessary. > > I must be missing something obviously so ... looking forward to hearing > examples > > Emil > > > >> Regards, >> >> Christer >> >> >> >> -----Original Message----- From: mmusic >> [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4nen Sent: 14. >> lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated offer >> >> Hi all, >> >> At the Toronto meeting we discussed whether we should change the >> behavior with ICE updated offer. Currently, based on RFC 5245, when >> ICE has finished, there is a new offer/answer with the selected >> candidate, *if* they are different from the "default candidates", >> i.e., the ones in original o/a m- and c-lines. >> >> Based on the discussion there was strong desire to have an option of >> not doing the updated o/a at all by indicating this in the original >> o/a. On the other hand, for some, the updated o/a was seen as a >> requirement for getting correct behavior from the network in certain >> scenarios (e.g., with SIP-aware middle boxes). >> >> I would like to hear from people, who have issues making the updated >> o/a optional, how bad the change would be and is there a way we could >> make this work also in those scenarios? >> >> >> Cheers, Ari >> >> _______________________________________________ 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 >> >> > -- > https://jitsi.org > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11c245ca99ac2205056389b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
just trying to understand :

What happen= s in the cases where the network interface has totally changed , say going = from WiFi only to 3G only or something ..
Don't we need to in= itiate new ICE checks and thus an update ..

Thanks=
Suhas

On Tue, Oct 14, 2014 at 7:32 AM, Emil Ivov <= ;emcho@jitsi.org&g= t; wrote:


On 14.10.14, 10:44, Christer Holmberg wrote:
Hi,

ISSUES: ----------

I think not doing the updated o/a (in case the SDP is not aligned
with the selected candidates) would cause serious problems in
environments where you have intermediaries etc that depend on correct
SDP information, e.g. to open gates etc.

 Opening gates needs to happen from the first O/A though. Right? Otherwise I= CE checks are not going to succeed.

SOLUTION SUGGESTION: ---------------------------------

I DO understand that there are cases where the second o/a is not
needed, even if the SDP is not aligned with the selected candidates
(as the endpoints will get the information about selected candidates
from the STUN messages). However, I don't think we can assume that
the offerer knows when that is the case.

So, if people don't want to keep the current rules, one alternative
would to indicate in the ANSWER whether the second offer is needed or
not.

 I don't really mind this (especially if the default is: don't send = an update) ... but, I'd also like to understand the exact use case wher= e this is necessary. The only one I can think of is a middle box that intro= duces relayed candidates. I don't find this to be a compelling argument= s since that relay can simply timeout if necessary.

I must be missing something obviously so ... looking forward to hearing exa= mples

Emil



Regards,

Christer



-----Original Message----- From: mmusic
[mailto:mmusic= -bounces@ietf.org] On Behalf Of Ari Ker=C3=A4nen Sent: 14.
lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated offer

Hi all,

At the Toronto meeting we discussed whether we should change the
behavior with ICE updated offer. Currently, based on RFC 5245, when
ICE has finished, there is a new offer/answer with the selected
candidate, *if* they are different from the "default candidates",=
i.e., the ones in original o/a m- and c-lines.

Based on the discussion there was strong desire to have an option of
not doing the updated o/a at all by indicating this in the original
o/a. On the other hand, for some, the updated o/a was seen as a
requirement for getting correct behavior from the network in certain
scenarios (e.g., with SIP-aware middle boxes).

I would like to hear from people, who have issues making the updated
o/a optional, how bad the change would be and is there a way we could
make this work also in those scenarios?


Cheers, Ari

_______________________________________________ mmusic mailing list<= br> mmusic@ietf.org ht= tps://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________ mmusic mailing list<= br> mmusic@ietf.org ht= tps://www.ietf.org/mailman/listinfo/mmusic


 --
https://jitsi.org


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

--001a11c245ca99ac2205056389b0-- From nobody Tue Oct 14 08:24:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B638F1A8901 for ; Tue, 14 Oct 2014 08:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9DqNuGmIR1l for ; Tue, 14 Oct 2014 08:24:04 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id AF75C1A8904 for ; Tue, 14 Oct 2014 08:24:03 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id A3DCF1EB8678; Tue, 14 Oct 2014 17:24:02 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 17:24:02 +0200 From: "Stach, Thomas" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGuF9H8nwjukqj+Vm4R8Q5spwvtaZQ Date: Tue, 14 Oct 2014 15:24:01 +0000 Message-ID: References: <543CDB90.7050509@ericsson.com> In-Reply-To: <543CDB90.7050509@ericsson.com> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mMyN9hzyrGOqIVdCpp1N1OllNSg Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:24:05 -0000 Ari,=20 although you haven't asked for issues _due_ to the ICE updated offer. There is an old, expired draft that elaborates on that: https://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02=20 It shows that e.g. certain 3PCC-based calls flows, that are used quite freq= uently in enterprise deployments, just don't work together with the ICE upd= ated offer. That's another reason for the desire for not doing the update. A possible, but admittedly ugly remedy for those that need it for their mid= dle boxes:=20 If the offerer indicates that it doesn't perform the ICE updated offer, the= middle box can send a trigger that starts the ICE updated offer once the d= ialog is confirmed. This triggers could e.g. be an offerless INVITE since i= t results in a new SDP offer/answer exchange. Unfortunately, RFC5245 requires an ICE restart in this case and, of course,= this behaviour needs to be maintained. Now, in order to let the middle box learn the actually used transport addre= sses, the restart would need to be suppressed, e.g. via a flag in that offe= rless INVITE, which then triggers the ICE agent to perform procedures for I= CE updated offers instead. Regards Thomas > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: Dienstag, 14. Oktober 2014 10:15 > To: mmusic > Subject: [MMUSIC] ICE updated offer >=20 > Hi all, >=20 > At the Toronto meeting we discussed whether we should change the > behavior with ICE updated offer. Currently, based on RFC 5245, when ICE > has finished, there is a new offer/answer with the selected candidate, > *if* they are different from the "default candidates", i.e., the ones in > original o/a m- and c-lines. >=20 > Based on the discussion there was strong desire to have an option of not > doing the updated o/a at all by indicating this in the original o/a. On > the other hand, for some, the updated o/a was seen as a requirement for > getting correct behavior from the network in certain scenarios (e.g., > with SIP-aware middle boxes). >=20 > I would like to hear from people, who have issues making the updated o/a > optional, how bad the change would be and is there a way we could make > this work also in those scenarios? >=20 >=20 > Cheers, > Ari >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Oct 14 08:24:15 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0071A8931 for ; Tue, 14 Oct 2014 08:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGADf2VAKXX0 for ; Tue, 14 Oct 2014 08:24:06 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557C51A8901 for ; Tue, 14 Oct 2014 08:24:06 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so10451648wid.10 for ; Tue, 14 Oct 2014 08:24:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=91Y2rn5Gr8lgLtoJ0q9XMsXr6vtHx79qRJA2ccWsgOc=; b=lbVE+0PcRqggytgDb8nAGnlKos/xCEJ4Tw6R7x7YTjMm3HDhhZLHvtmXMCt9gzfaDY Z+8c5rf6VyuFprwOGFmcGALYhQKmbhY9dzzOiN/CSV3lC+qaO0g/U7JDfOZmDkX/tD1K cKjjciAa83XaG4UzS16adMQ2ILEbtSzwKwLv9ZMWCqAFvRAbe90hVCshBeVau5gHKX+P WVlSMy8/GBST6VVDfIH6SSCmhu8M5al0ks+l9tm9u4xx4+TX3ugInk+smqBJLZ2qsxIj uU57ZUHi98tXZt3yGvnnr4/r59pA5FQbXOnkKRD4eJqWeR96HFAQS8WDQBBRvMHOyMT3 tUCA== X-Gm-Message-State: ALoCoQlp1UAZqaQM29ZoZmOELkdUscvMX6C2KfTE9L6EWyj0L5Qk0UkUAnb/302G7CM+//SXeAom X-Received: by 10.180.10.231 with SMTP id l7mr6156492wib.1.1413300244589; Tue, 14 Oct 2014 08:24:04 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id cy10sm20562895wjb.21.2014.10.14.08.24.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 08:24:03 -0700 (PDT) Message-ID: <543D4015.6000601@jitsi.org> Date: Tue, 14 Oct 2014 17:24:05 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Suhas Nandakumar References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-RR9vH_OjoUHhrde-MRn3uXljQs Cc: =?UTF-8?B?QXJpIEtl?= =?UTF-8?B?csOkbmVu?= , mmusic , Christer Holmberg Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:24:10 -0000 On 14.10.14, 17:19, Suhas Nandakumar wrote: > just trying to understand : > > What happens in the cases where the network interface has totally > changed , say going from WiFi only to 3G only or something .. > Don't we need to initiate new ICE checks and thus an update .. Sure. This would be an ICE restart. But what we are discussing here is the mandatory Offer/Answer update that occurs at the end of ICE processing when ICE has resulted in using a pair that is different from the one that was originally default. Emil > Thanks > Suhas > > On Tue, Oct 14, 2014 at 7:32 AM, Emil Ivov > wrote: > > > > On 14.10.14, 10:44, Christer Holmberg wrote: > > Hi, > > ISSUES: ---------- > > I think not doing the updated o/a (in case the SDP is not aligned > with the selected candidates) would cause serious problems in > environments where you have intermediaries etc that depend on > correct > SDP information, e.g. to open gates etc. > > > Opening gates needs to happen from the first O/A though. Right? > Otherwise ICE checks are not going to succeed. > > SOLUTION SUGGESTION: ------------------------------__--- > > I DO understand that there are cases where the second o/a is not > needed, even if the SDP is not aligned with the selected candidates > (as the endpoints will get the information about selected candidates > from the STUN messages). However, I don't think we can assume that > the offerer knows when that is the case. > > So, if people don't want to keep the current rules, one alternative > would to indicate in the ANSWER whether the second offer is > needed or > not. > > > I don't really mind this (especially if the default is: don't send > an update) ... but, I'd also like to understand the exact use case > where this is necessary. The only one I can think of is a middle box > that introduces relayed candidates. I don't find this to be a > compelling arguments since that relay can simply timeout if necessary. > > I must be missing something obviously so ... looking forward to > hearing examples > > Emil > > > > Regards, > > Christer > > > > -----Original Message----- From: mmusic > [mailto:mmusic-bounces@ietf.__org > ] On Behalf Of Ari Keränen Sent: 14. > lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated offer > > Hi all, > > At the Toronto meeting we discussed whether we should change the > behavior with ICE updated offer. Currently, based on RFC 5245, when > ICE has finished, there is a new offer/answer with the selected > candidate, *if* they are different from the "default candidates", > i.e., the ones in original o/a m- and c-lines. > > Based on the discussion there was strong desire to have an option of > not doing the updated o/a at all by indicating this in the original > o/a. On the other hand, for some, the updated o/a was seen as a > requirement for getting correct behavior from the network in certain > scenarios (e.g., with SIP-aware middle boxes). > > I would like to hear from people, who have issues making the updated > o/a optional, how bad the change would be and is there a way we > could > make this work also in those scenarios? > > > Cheers, Ari > > _________________________________________________ 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 > > > > -- > https://jitsi.org > > > _________________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/__listinfo/mmusic > > > -- https://jitsi.org From nobody Tue Oct 14 08:25:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3CB1A88E5 for ; Tue, 14 Oct 2014 08:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipsTrqeV2cqb for ; Tue, 14 Oct 2014 08:24:54 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3804A1A88DC for ; Tue, 14 Oct 2014 08:24:54 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id a13so14984466igq.16 for ; Tue, 14 Oct 2014 08:24:53 -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=naw19C0KUXrXUIncuh70SUfap1uiVjuSY5EPsNyEh4E=; b=c80/jukoEaEswKzJA+ekNWNZkX09kjjidyzXf6bYrdx7NLEx7zpFUmV5XnhrDsNobJ x6jLGkbBM2Wj8/oOtq5XyXeI6beTsKXVjVoTgXMe417OheNMlvjSmx+V1FtPv8GpgMUb sthsKPQH5R5dUFdXAPweT4TOCynSjrugDX4yf7f44KtNZGjbiDnLB7xMki0gJvxs80HE HeP8SlLAZ/N936a7biU9WImmgA6qiKyUwSVczY8tzZ6LRhoFJFpjtL2RzboKwzwLk9My +5YPmbtd32glxsbI+Fyyhr+/7a/pYizF1NqBZrNgWLgo8XVFRPtOU3Z9GpXt+IV715pN 4quw== MIME-Version: 1.0 X-Received: by 10.42.228.4 with SMTP id jc4mr1308994icb.96.1413300293642; Tue, 14 Oct 2014 08:24:53 -0700 (PDT) Received: by 10.50.20.231 with HTTP; Tue, 14 Oct 2014 08:24:53 -0700 (PDT) Received: by 10.50.20.231 with HTTP; Tue, 14 Oct 2014 08:24:53 -0700 (PDT) In-Reply-To: References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> Date: Tue, 14 Oct 2014 18:24:53 +0300 Message-ID: From: Varun Singh To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=001a11c3a8baf6af730505639d1d Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xckwFWV6NCN1GZhcrrmARo650Is Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Christer Holmberg Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:24:59 -0000 --001a11c3a8baf6af730505639d1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14 Oct 2014 18:19, "Suhas Nandakumar" wrote: > > just trying to understand : > > What happens in the cases where the network interface has totally changed , say going from WiFi only to 3G only or something .. > Don't we need to initiate new ICE checks and thus an update .. > I suppose it depends on when the interfaces become available: I think the endpoint would trickle the candidates if the ice is ongoing. If ice has frozen its candidates, then it would require an ice restart? > Thanks > Suhas > > On Tue, Oct 14, 2014 at 7:32 AM, Emil Ivov wrote: >> >> >> >> On 14.10.14, 10:44, Christer Holmberg wrote: >>> >>> Hi, >>> >>> ISSUES: ---------- >>> >>> I think not doing the updated o/a (in case the SDP is not aligned >>> with the selected candidates) would cause serious problems in >>> environments where you have intermediaries etc that depend on correct >>> SDP information, e.g. to open gates etc. >> >> >> Opening gates needs to happen from the first O/A though. Right? Otherwise ICE checks are not going to succeed. >> >>> SOLUTION SUGGESTION: --------------------------------- >>> >>> I DO understand that there are cases where the second o/a is not >>> needed, even if the SDP is not aligned with the selected candidates >>> (as the endpoints will get the information about selected candidates >>> from the STUN messages). However, I don't think we can assume that >>> the offerer knows when that is the case. >>> >>> So, if people don't want to keep the current rules, one alternative >>> would to indicate in the ANSWER whether the second offer is needed or >>> not. >> >> >> I don't really mind this (especially if the default is: don't send an update) ... but, I'd also like to understand the exact use case where this is necessary. The only one I can think of is a middle box that introduces relayed candidates. I don't find this to be a compelling arguments since that relay can simply timeout if necessary. >> >> I must be missing something obviously so ... looking forward to hearing examples >> >> Emil >> >> >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> -----Original Message----- From: mmusic >>> [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4nen Sent: 14= . >>> lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated offer >>> >>> Hi all, >>> >>> At the Toronto meeting we discussed whether we should change the >>> behavior with ICE updated offer. Currently, based on RFC 5245, when >>> ICE has finished, there is a new offer/answer with the selected >>> candidate, *if* they are different from the "default candidates", >>> i.e., the ones in original o/a m- and c-lines. >>> >>> Based on the discussion there was strong desire to have an option of >>> not doing the updated o/a at all by indicating this in the original >>> o/a. On the other hand, for some, the updated o/a was seen as a >>> requirement for getting correct behavior from the network in certain >>> scenarios (e.g., with SIP-aware middle boxes). >>> >>> I would like to hear from people, who have issues making the updated >>> o/a optional, how bad the change would be and is there a way we could >>> make this work also in those scenarios? >>> >>> >>> Cheers, Ari >>> >>> _______________________________________________ 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 >>> >> >> -- >> https://jitsi.org >> >> >> _______________________________________________ >> 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 > --001a11c3a8baf6af730505639d1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 14 Oct 2014 18:19, "Suhas Nandakumar" <suhasietf@gmail.com> wrote:
>
> just trying to understand :
>
> What happens in the cases where the network interface has totally chan= ged , say going from WiFi only to 3G only or something ..
> Don't we need to initiate new ICE checks and thus an update ..
>
I suppose it depends on when the interfaces become available:

I think the endpoint would trickle the candidates if the ice= is ongoing. If ice has frozen its candidates, then it would require an ice= restart?

> Thanks
> Suhas
>
> On Tue, Oct 14, 2014 at 7:32 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>>
>>
>> On 14.10.14, 10:44, Christer Holmberg wrote:
>>>
>>> Hi,
>>>
>>> ISSUES: ----------
>>>
>>> I think not doing the updated o/a (in case the SDP is not alig= ned
>>> with the selected candidates) would cause serious problems in<= br> >>> environments where you have intermediaries etc that depend on = correct
>>> SDP information, e.g. to open gates etc.
>>
>>
>> Opening gates needs to happen from the first O/A though. Right? Ot= herwise ICE checks are not going to succeed.
>>
>>> SOLUTION SUGGESTION: ---------------------------------
>>>
>>> I DO understand that there are cases where the second o/a is n= ot
>>> needed, even if the SDP is not aligned with the selected candi= dates
>>> (as the endpoints will get the information about selected cand= idates
>>> from the STUN messages). However, I don't think we can ass= ume that
>>> the offerer knows when that is the case.
>>>
>>> So, if people don't want to keep the current rules, one al= ternative
>>> would to indicate in the ANSWER whether the second offer is ne= eded or
>>> not.
>>
>>
>> I don't really mind this (especially if the default is: don= 9;t send an update) ... but, I'd also like to understand the exact use = case where this is necessary. The only one I can think of is a middle box t= hat introduces relayed candidates. I don't find this to be a compelling= arguments since that relay can simply timeout if necessary.
>>
>> I must be missing something obviously so ... looking forward to he= aring examples
>>
>> Emil
>>
>>
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> -----Original Message----- From: mmusic
>>> [mailto:mmusic-boun= ces@ietf.org] On Behalf Of Ari Ker=C3=A4nen Sent: 14.
>>> lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated = offer
>>>
>>> Hi all,
>>>
>>> At the Toronto meeting we discussed whether we should change t= he
>>> behavior with ICE updated offer. Currently, based on RFC 5245,= when
>>> ICE has finished, there is a new offer/answer with the selecte= d
>>> candidate, *if* they are different from the "default cand= idates",
>>> i.e., the ones in original o/a m- and c-lines.
>>>
>>> Based on the discussion there was strong desire to have an opt= ion of
>>> not doing the updated o/a at all by indicating this in the ori= ginal
>>> o/a. On the other hand, for some, the updated o/a was seen as = a
>>> requirement for getting correct behavior from the network in c= ertain
>>> scenarios (e.g., with SIP-aware middle boxes).
>>>
>>> I would like to hear from people, who have issues making the u= pdated
>>> o/a optional, how bad the change would be and is there a way w= e could
>>> make this work also in those scenarios?
>>>
>>>
>>> Cheers, Ari
>>>
>>> _______________________________________________ mmusic mailing= list
>>> mmusic@ietf.org https://www.ietf.org/mail= man/listinfo/mmusic
>>>
>>> _______________________________________________ mmusic mailing= list
>>> mmusic@ietf.org https://www.ietf.org/mail= man/listinfo/mmusic
>>>
>>
>> --
>> https://jitsi.org
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic
>

--001a11c3a8baf6af730505639d1d-- From nobody Tue Oct 14 08:27:48 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A81A8943 for ; Tue, 14 Oct 2014 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJuzh_WbRh3F for ; Tue, 14 Oct 2014 08:27:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF491A893E for ; Tue, 14 Oct 2014 08:27:40 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-7e-543d40ea3be9 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.00.04081.AE04D345; Tue, 14 Oct 2014 17:27:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 17:27:38 +0200 From: Christer Holmberg To: Emil Ivov , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTAgABCdgCAAC5W8A== Date: Tue, 14 Oct 2014 15:27:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47C432@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> In-Reply-To: <543D341A.3040006@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje4rB9sQg5Ov9S3W7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlbHi/mSWgimSFXdXLmVvYNwk0sXIySEhYCKx b95xZghbTOLCvfVsILaQwFFGicWr6iHsJYwSM7dZdzFycLAJWEh0/9MGCYsIlEm0XNjMBBIW FlCXmHJPASKsIbHg2hdGCNtJ4m5jJzNICYuAqsS7txkgYV4BX4mDL7YClXABDe9jlFjw5i0T SIJTQFNi8+qnYDYj0DXfT60Bs5kFxCVuPZnPBHGlgMSSPeehLhaVePn4HyuErSSx6PZnqHo9 iRtTp7BB2NoSyxa+ZoZYLChxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03MtJL LcpMLi7Oz9PLSy3ZxAiMj4NbfhvsYHz53PEQowAHoxIP74JmmxAh1sSy4srcQ4zSHCxK4rwL z80LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBYa7S1PqNHU7KuwiT0qp/qW4+zpR0pa3hm 60d5nxS5Nos51nW9a/C7PY8+XN2dtdjYyPPkK+PJew7eWHxra0VyvLNUVmV86iZeCYeznY43 Xl1e9bJk5psXj5QZHWe9qtk3SSHWLj9Uf5/TxD9ujsYvZ20xM1t37uDHb5+bPsuUZyi2uXit YQtUYinOSDTUYi4qTgQAiNryyHACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nKPIit139XRwOhC6yl-WhcChYLU Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:27:45 -0000 Hi, >> ISSUES:=20 >> ---------- >> >> I think not doing the updated o/a (in case the SDP is not aligned with=20 >> the selected candidates) would cause serious problems in environments=20 >> where you have intermediaries etc that depend on correct SDP=20 >> information, e.g. to open gates etc. > > Opening gates needs to happen from the first O/A though. Right?=20 > Otherwise ICE checks are not going to succeed. Correct. Depending on policy, you may open gates in order to allow STUN req= uests associated with all candidates to pass, perhaps with limited bandwidt= h. >> SOLUTION SUGGESTION: --------------------------------- >> >> I DO understand that there are cases where the second o/a is not=20 >> needed, even if the SDP is not aligned with the selected candidates=20 >> (as the endpoints will get the information about selected candidates=20 >> from the STUN messages). However, I don't think we can assume that the=20 >> offerer knows when that is the case. >> >> So, if people don't want to keep the current rules, one alternative=20 >> would to indicate in the ANSWER whether the second offer is needed or=20 >> not. > > I don't really mind this (especially if the default is: don't send an > update) ... but, I'd also like to understand the exact use case where thi= s is=20 > necessary. The only one I can think of is a middle box that introduces=20 > relayed candidates. I don't find this to be a compelling arguments since = that > relay can simply timeout if necessary. Perhaps there could be some timeout logic (and for some functions there are= ), but that is not how much of the existing deployments work today. They re= ly on the controller setting the gates, bandwidth, etc, based on SDP inform= ation. Regards, Christer > -----Original Message----- From: mmusic=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen Sent: 14. > lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated offer > > Hi all, > > At the Toronto meeting we discussed whether we should change the=20 > behavior with ICE updated offer. Currently, based on RFC 5245, when=20 > ICE has finished, there is a new offer/answer with the selected=20 > candidate, *if* they are different from the "default candidates",=20 > i.e., the ones in original o/a m- and c-lines. > > Based on the discussion there was strong desire to have an option of=20 > not doing the updated o/a at all by indicating this in the original=20 > o/a. On the other hand, for some, the updated o/a was seen as a=20 > requirement for getting correct behavior from the network in certain=20 > scenarios (e.g., with SIP-aware middle boxes). > > I would like to hear from people, who have issues making the updated=20 > o/a optional, how bad the change would be and is there a way we could=20 > make this work also in those scenarios? > > > Cheers, Ari > > _______________________________________________ mmusic mailing list=20 > mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list=20 > mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic > -- https://jitsi.org From nobody Tue Oct 14 08:28:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA40A1A88D0 for ; Tue, 14 Oct 2014 08:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdZ1nYJPnwnz for ; Tue, 14 Oct 2014 08:28:43 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C481A8935 for ; Tue, 14 Oct 2014 08:28:42 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-3b-543d4128833a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.8A.21334.8214D345; Tue, 14 Oct 2014 17:28:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 17:28:40 +0200 From: Christer Holmberg To: Emil Ivov , Suhas Nandakumar Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTAgABCdgCAAAzqgIAAAV6AgAAi1LA= Date: Tue, 14 Oct 2014 15:28:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47C44C@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> <543D4015.6000601@jitsi.org> In-Reply-To: <543D4015.6000601@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvja6Go22Iwcy3RhZrdk5gsZi6/DGL xc65HcwOzB47Z91l91iy5CeTx/83gQHMUVw2Kak5mWWpRfp2CVwZLddmsRV80q943aXZwHhF r4uRg0NCwETixDGXLkZOIFNM4sK99WxdjFwcQgJHGSXurTnBDuEsYZSYs+0yK0gDm4CFRPc/ bZAGEQF3iR/bbjKC2MwC4RIPfqxmBykRFlCXmHJPAaJEQ2LBtS+MELafxJNLM1hBbBYBVYkL M2+BxXkFfCW6zm9khlj1hVHi/fvNYAlOAU2JjpvnwBoYgY77fmoNE8QucYlbT+YzQRwtILFk z3lmCFtU4uXjf6wQtpLEotufmUDuYQaas36XPkSrosSU7ofsEHsFJU7OfMIygVFsFpKpsxA6 ZiHpmIWkYwEjyypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwEg6uOW37g7G1a8dDzEKcDAq 8fAuaLYJEWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjHp1 E3pDpzFsPDqlzm/KrPtXL1b/8mmqyD723t5wqvO2e1KL2GMlA5XuvUm4qis2IXL50YJnHDs3 zbO0+vumVfLGscUnnh6epRO/R0T7hMxr0+AfUoqfvitNdpPSY2pfsCUu2E+ZO+XQ3bzDvxZq 1ubZ7jcML/M7XLTq+q9e39331nwPmbox8JESS3FGoqEWc1FxIgB+znJghQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2QE4oBVHixxVIrHbQODX1f9SwtI Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:28:45 -0000 DQo+PiBqdXN0IHRyeWluZyB0byB1bmRlcnN0YW5kIDoNCj4+DQo+PiBXaGF0IGhhcHBlbnMgaW4g dGhlIGNhc2VzIHdoZXJlIHRoZSBuZXR3b3JrIGludGVyZmFjZSBoYXMgdG90YWxseSANCj4+IGNo YW5nZWQgLCBzYXkgZ29pbmcgZnJvbSBXaUZpIG9ubHkgdG8gM0cgb25seSBvciBzb21ldGhpbmcg Li4NCj4+IERvbid0IHdlIG5lZWQgdG8gaW5pdGlhdGUgbmV3IElDRSBjaGVja3MgYW5kIHRodXMg YW4gdXBkYXRlIC4uDQo+DQo+U3VyZS4gVGhpcyB3b3VsZCBiZSBhbiBJQ0UgcmVzdGFydC4gQnV0 IHdoYXQgd2UgYXJlIGRpc2N1c3NpbmcgaGVyZSBpcyB0aGUgPm1hbmRhdG9yeSBPZmZlci9BbnN3 ZXIgdXBkYXRlIHRoYXQgb2NjdXJzIGF0IHRoZSBlbmQgb2YgSUNFIHByb2Nlc3NpbmcgPndoZW4g SUNFIGhhcyByZXN1bHRlZCBpbiB1c2luZyBhIHBhaXIgdGhhdCBpcyBkaWZmZXJlbnQgZnJvbSB0 aGUgb25lIHRoYXQgd2FzID5vcmlnaW5hbGx5IGRlZmF1bHQuDQoNCkNvcnJlY3QuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg0KPiBPbiBUdWUsIE9jdCAxNCwgMjAxNCBhdCA3OjMyIEFNLCBF bWlsIEl2b3YgPGVtY2hvQGppdHNpLm9yZyANCj4gPG1haWx0bzplbWNob0BqaXRzaS5vcmc+PiB3 cm90ZToNCj4NCj4NCj4NCj4gICAgIE9uIDE0LjEwLjE0LCAxMDo0NCwgQ2hyaXN0ZXIgSG9sbWJl cmcgd3JvdGU6DQo+DQo+ICAgICAgICAgSGksDQo+DQo+ICAgICAgICAgSVNTVUVTOiAtLS0tLS0t LS0tDQo+DQo+ICAgICAgICAgSSB0aGluayBub3QgZG9pbmcgdGhlIHVwZGF0ZWQgby9hIChpbiBj YXNlIHRoZSBTRFAgaXMgbm90IGFsaWduZWQNCj4gICAgICAgICB3aXRoIHRoZSBzZWxlY3RlZCBj YW5kaWRhdGVzKSB3b3VsZCBjYXVzZSBzZXJpb3VzIHByb2JsZW1zIGluDQo+ICAgICAgICAgZW52 aXJvbm1lbnRzIHdoZXJlIHlvdSBoYXZlIGludGVybWVkaWFyaWVzIGV0YyB0aGF0IGRlcGVuZCBv bg0KPiAgICAgICAgIGNvcnJlY3QNCj4gICAgICAgICBTRFAgaW5mb3JtYXRpb24sIGUuZy4gdG8g b3BlbiBnYXRlcyBldGMuDQo+DQo+DQo+ICAgICBPcGVuaW5nIGdhdGVzIG5lZWRzIHRvIGhhcHBl biBmcm9tIHRoZSBmaXJzdCBPL0EgdGhvdWdoLiBSaWdodD8NCj4gICAgIE90aGVyd2lzZSBJQ0Ug Y2hlY2tzIGFyZSBub3QgZ29pbmcgdG8gc3VjY2VlZC4NCj4NCj4gICAgICAgICBTT0xVVElPTiBT VUdHRVNUSU9OOiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1fXy0tLQ0KPg0KPiAgICAg ICAgIEkgRE8gdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB0aGUgc2Vjb25k IG8vYSBpcyBub3QNCj4gICAgICAgICBuZWVkZWQsIGV2ZW4gaWYgdGhlIFNEUCBpcyBub3QgYWxp Z25lZCB3aXRoIHRoZSBzZWxlY3RlZCBjYW5kaWRhdGVzDQo+ICAgICAgICAgKGFzIHRoZSBlbmRw b2ludHMgd2lsbCBnZXQgdGhlIGluZm9ybWF0aW9uIGFib3V0IHNlbGVjdGVkIGNhbmRpZGF0ZXMN Cj4gICAgICAgICBmcm9tIHRoZSBTVFVOIG1lc3NhZ2VzKS4gSG93ZXZlciwgSSBkb24ndCB0aGlu ayB3ZSBjYW4gYXNzdW1lIHRoYXQNCj4gICAgICAgICB0aGUgb2ZmZXJlciBrbm93cyB3aGVuIHRo YXQgaXMgdGhlIGNhc2UuDQo+DQo+ICAgICAgICAgU28sIGlmIHBlb3BsZSBkb24ndCB3YW50IHRv IGtlZXAgdGhlIGN1cnJlbnQgcnVsZXMsIG9uZSBhbHRlcm5hdGl2ZQ0KPiAgICAgICAgIHdvdWxk IHRvIGluZGljYXRlIGluIHRoZSBBTlNXRVIgd2hldGhlciB0aGUgc2Vjb25kIG9mZmVyIGlzDQo+ ICAgICAgICAgbmVlZGVkIG9yDQo+ICAgICAgICAgbm90Lg0KPg0KPg0KPiAgICAgSSBkb24ndCBy ZWFsbHkgbWluZCB0aGlzIChlc3BlY2lhbGx5IGlmIHRoZSBkZWZhdWx0IGlzOiBkb24ndCBzZW5k DQo+ICAgICBhbiB1cGRhdGUpIC4uLiBidXQsIEknZCBhbHNvIGxpa2UgdG8gdW5kZXJzdGFuZCB0 aGUgZXhhY3QgdXNlIGNhc2UNCj4gICAgIHdoZXJlIHRoaXMgaXMgbmVjZXNzYXJ5LiBUaGUgb25s eSBvbmUgSSBjYW4gdGhpbmsgb2YgaXMgYSBtaWRkbGUgYm94DQo+ICAgICB0aGF0IGludHJvZHVj ZXMgcmVsYXllZCBjYW5kaWRhdGVzLiBJIGRvbid0IGZpbmQgdGhpcyB0byBiZSBhDQo+ICAgICBj b21wZWxsaW5nIGFyZ3VtZW50cyBzaW5jZSB0aGF0IHJlbGF5IGNhbiBzaW1wbHkgdGltZW91dCBp ZiBuZWNlc3NhcnkuDQo+DQo+ICAgICBJIG11c3QgYmUgbWlzc2luZyBzb21ldGhpbmcgb2J2aW91 c2x5IHNvIC4uLiBsb29raW5nIGZvcndhcmQgdG8NCj4gICAgIGhlYXJpbmcgZXhhbXBsZXMNCj4N Cj4gICAgIEVtaWwNCj4NCj4NCj4NCj4gICAgICAgICBSZWdhcmRzLA0KPg0KPiAgICAgICAgIENo cmlzdGVyDQo+DQo+DQo+DQo+ICAgICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJv bTogbW11c2ljDQo+ICAgICAgICAgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLl9fb3JnDQo+ ICAgICAgICAgPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBB cmkgS2Vyw6RuZW4gU2VudDogMTQuDQo+ICAgICAgICAgbG9rYWt1dXRhIDIwMTQgMTE6MTUgVG86 IG1tdXNpYyBTdWJqZWN0OiBbTU1VU0lDXSBJQ0UgdXBkYXRlZCANCj4gb2ZmZXINCj4NCj4gICAg ICAgICBIaSBhbGwsDQo+DQo+ICAgICAgICAgQXQgdGhlIFRvcm9udG8gbWVldGluZyB3ZSBkaXNj dXNzZWQgd2hldGhlciB3ZSBzaG91bGQgY2hhbmdlIHRoZQ0KPiAgICAgICAgIGJlaGF2aW9yIHdp dGggSUNFIHVwZGF0ZWQgb2ZmZXIuIEN1cnJlbnRseSwgYmFzZWQgb24gUkZDIDUyNDUsIHdoZW4N Cj4gICAgICAgICBJQ0UgaGFzIGZpbmlzaGVkLCB0aGVyZSBpcyBhIG5ldyBvZmZlci9hbnN3ZXIg d2l0aCB0aGUgc2VsZWN0ZWQNCj4gICAgICAgICBjYW5kaWRhdGUsICppZiogdGhleSBhcmUgZGlm ZmVyZW50IGZyb20gdGhlICJkZWZhdWx0IGNhbmRpZGF0ZXMiLA0KPiAgICAgICAgIGkuZS4sIHRo ZSBvbmVzIGluIG9yaWdpbmFsIG8vYSBtLSBhbmQgYy1saW5lcy4NCj4NCj4gICAgICAgICBCYXNl ZCBvbiB0aGUgZGlzY3Vzc2lvbiB0aGVyZSB3YXMgc3Ryb25nIGRlc2lyZSB0byBoYXZlIGFuIG9w dGlvbiBvZg0KPiAgICAgICAgIG5vdCBkb2luZyB0aGUgdXBkYXRlZCBvL2EgYXQgYWxsIGJ5IGlu ZGljYXRpbmcgdGhpcyBpbiB0aGUgb3JpZ2luYWwNCj4gICAgICAgICBvL2EuIE9uIHRoZSBvdGhl ciBoYW5kLCBmb3Igc29tZSwgdGhlIHVwZGF0ZWQgby9hIHdhcyBzZWVuIGFzIGENCj4gICAgICAg ICByZXF1aXJlbWVudCBmb3IgZ2V0dGluZyBjb3JyZWN0IGJlaGF2aW9yIGZyb20gdGhlIG5ldHdv cmsgaW4gY2VydGFpbg0KPiAgICAgICAgIHNjZW5hcmlvcyAoZS5nLiwgd2l0aCBTSVAtYXdhcmUg bWlkZGxlIGJveGVzKS4NCj4NCj4gICAgICAgICBJIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9tIHBl b3BsZSwgd2hvIGhhdmUgaXNzdWVzIG1ha2luZyB0aGUgdXBkYXRlZA0KPiAgICAgICAgIG8vYSBv cHRpb25hbCwgaG93IGJhZCB0aGUgY2hhbmdlIHdvdWxkIGJlIGFuZCBpcyB0aGVyZSBhIHdheSB3 ZQ0KPiAgICAgICAgIGNvdWxkDQo+ICAgICAgICAgbWFrZSB0aGlzIHdvcmsgYWxzbyBpbiB0aG9z ZSBzY2VuYXJpb3M/DQo+DQo+DQo+ICAgICAgICAgQ2hlZXJzLCBBcmkNCj4NCj4gICAgICAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIG1tdXNpYyBt YWlsaW5nDQo+ICAgICAgICAgbGlzdA0KPiAgICAgICAgIG1tdXNpY0BpZXRmLm9yZyA8bWFpbHRv Om1tdXNpY0BpZXRmLm9yZz4NCj4gICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L19fbGlzdGluZm8vbW11c2ljDQo+ICAgICAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljPg0KPg0KPiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gbW11c2ljIG1haWxpbmcNCj4gICAgICAgICBsaXN0 DQo+ICAgICAgICAgbW11c2ljQGlldGYub3JnIDxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KPiAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0aW5mby9tbXVzaWMNCj4g ICAgICAgICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM+DQo+ DQo+DQo+ICAgICAtLQ0KPiAgICAgaHR0cHM6Ly9qaXRzaS5vcmcNCj4NCj4NCj4gICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgIG1tdXNp YyBtYWlsaW5nIGxpc3QNCj4gICAgIG1tdXNpY0BpZXRmLm9yZyA8bWFpbHRvOm1tdXNpY0BpZXRm Lm9yZz4NCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0aW5mby9tbXVz aWMNCj4gICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYz4N Cj4NCj4NCg0KLS0NCmh0dHBzOi8vaml0c2kub3JnDQo= From nobody Tue Oct 14 08:34:15 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059B91A891B for ; Tue, 14 Oct 2014 08:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA9w0KtNJZ-D for ; Tue, 14 Oct 2014 08:34:10 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B358F1A88EE for ; Tue, 14 Oct 2014 08:34:10 -0700 (PDT) Received: from [130.209.247.112] (port=51857 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xe46x-0001od-Nz; Tue, 14 Oct 2014 16:34:08 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <5436E6F2.2010202@cisco.com> Date: Tue, 14 Oct 2014 16:33:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C96C1E5-3A4C-46AB-9350-B3A016864F1F@csperkins.org> References: <5436E6F2.2010202@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_Wi41vVzCXQMLhs-VY1XHa_8sQ0 Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:34:13 -0000 On 9 Oct 2014, at 20:50, Flemming Andreasen wrote: > This is to announce a 2 week Working Group Last Call for >=20 > draft-ietf-mmusic-sdp-bundle-negotiation-12 =20 >=20 > as Proposed Standard. Please review and provide any comments you may = have on the document by Friday, October 24, 2014. 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.=20 In general this looks good, but I do have a few relatively minor = comments: - Section 1, 7th paragraph: typo =93a new RTP SDES item=94 -> =93a new = RTCP SDES item=94 - Section 10.1.1: the third bullet point says that a given SSRC =93SHOULD = NOT=94 transmit RTP packets using payload types that originate from = different bundled =93m=3D=93 lines, and follows this with an explanatory = note. Given the problems that SSRC reuse will cause, I suggest = strengthening this to =93MUST NOT", then adding a further note to = address the case where SSRC reuse works saying =93However, once an SSRC = has left the RTP session by sending an RTCP BYE packet, that SSRC value = can later be reused by another source, possibly on a different bundled = m=3D line=94.=20 - Section 10.3.1: the last sentence is unclear what separate 5-tuple = will be used if RTP/RTCP multiplexing is not enabled. This is explained = in Section 10.3.2.3, and the draft would be clearer if 10.3.1 referenced = this. - Section 13.2: it may be useful to clarify that the mid value is not = zero terminated. - Section 13.3: again, clarify that the mid value is not zero = terminated. It may also be useful to remind implementers that the RFC = 5285 format requires padding out to the next 32-bit boundary using zero = bytes if the size of the header extension isn=92t a multiple of 32 bits. = This padding could easily be confused with a terminating zero by a = careless implementer. Colin --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 14 08:36:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2471A8941 for ; Tue, 14 Oct 2014 08:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeTa2EvBELQr for ; Tue, 14 Oct 2014 08:36:11 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 99AD01A8791 for ; Tue, 14 Oct 2014 08:36:11 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id B847223F044C; Tue, 14 Oct 2014 17:36:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 17:36:10 +0200 From: "Stach, Thomas" To: Christer Holmberg , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGuF9H8nwjukqj+Vm4R8Q5spwvRHTAgAB0OEA= Date: Tue, 14 Oct 2014 15:36:09 +0000 Message-ID: References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/EUxxMS4MGgjtSeLRCeU4oxsH1Pw Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:36:13 -0000 Christer, > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Dienstag, 14. Oktober 2014 10:44 > To: Ari Ker=E4nen; mmusic > Subject: Re: [MMUSIC] ICE updated offer >=20 > Hi, >=20 > ISSUES: > ---------- >=20 > I think not doing the updated o/a (in case the SDP is not aligned with th= e > selected candidates) would cause serious problems in environments where y= ou > have intermediaries etc that depend on correct SDP information, e.g. to > open gates etc. >=20 >=20 > SOLUTION SUGGESTION: > --------------------------------- >=20 > I DO understand that there are cases where the second o/a is not needed, > even if the SDP is not aligned with the selected candidates (as the > endpoints will get the information about selected candidates from the STU= N > messages). However, I don't think we can assume that the offerer knows wh= en > that is the case. >=20 > So, if people don't want to keep the current rules, one alternative would > to indicate in the ANSWER whether the second offer is needed or not. How would the answerer know that, if the offerer didn't? If later on the call is established in the other direction, the roles are j= ust reversed. Regards Thomas >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: 14. lokakuuta 2014 11:15 > To: mmusic > Subject: [MMUSIC] ICE updated offer >=20 > Hi all, >=20 > At the Toronto meeting we discussed whether we should change the behavior > with ICE updated offer. Currently, based on RFC 5245, when ICE has > finished, there is a new offer/answer with the selected candidate, > *if* they are different from the "default candidates", i.e., the ones in > original o/a m- and c-lines. >=20 > Based on the discussion there was strong desire to have an option of not > doing the updated o/a at all by indicating this in the original o/a. On t= he > other hand, for some, the updated o/a was seen as a requirement for getti= ng > correct behavior from the network in certain scenarios (e.g., with SIP- > aware middle boxes). >=20 > I would like to hear from people, who have issues making the updated o/a > optional, how bad the change would be and is there a way we could make th= is > work also in those scenarios? >=20 >=20 > Cheers, > Ari >=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 nobody Tue Oct 14 08:46:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99B61A8952 for ; Tue, 14 Oct 2014 08:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPrNmNuEDvvL for ; Tue, 14 Oct 2014 08:46:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2323F1A894C for ; Tue, 14 Oct 2014 08:46:26 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-5e-543d45513e70 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 30.42.04081.1554D345; Tue, 14 Oct 2014 17:46:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 17:46:24 +0200 From: Christer Holmberg To: "Stach, Thomas" , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTAgABUHYCAACH68A== Date: Tue, 14 Oct 2014 15:46:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47C4D7@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> 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.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjW6gq22IwfILYhZTlz9msTi5cxuz A5PHkiU/mTy29zxmCWCK4rJJSc3JLEst0rdL4Mq43niBtaBNpOLp3ZNsDYyLBLoYOTkkBEwk fv5+yQphi0lcuLeerYuRi0NI4CijROvHZawQzhJGibcdF5m7GDk42AQsJLr/aYPERQSaGSUO TbnEBhIXFlCXmHJPAWSQiICGxIJrXxghbCeJXf8OsoPYLAKqEm3fT7KA2LwCvhLPTpxigpi/ hVHiwLqvzCAJTgF/ifdrPjGB2IxAF30/tQbMZhYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+B/WB ksSi25+h6vUkbkydwgZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbQ4 tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzBSDm75bbCD8eVzx0OMAhyMSjy8C5ptQoRYE8uKK3MP MUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PZJQ711fvkuX42Km1du2mL yr49c4xD1wWx5E41aWG5Gz15O/PZtOkevecs+rY91/36oepWoTjLhYxJkvwrT+nnnJzX7vte pvq9THZV5qck501VDxUeCFZrMf+ui06bs38re8CJDRxPuiPv1Ins/rKJ1y2lY8HzNLHza2Sc Dz3pWNOw1E381yslluKMREMt5qLiRACxa9n0dQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_XjWYm48LA8RLELGc35bgwIjDAY Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 15:46:29 -0000 Hi, >> ISSUES: >> ---------- >>=20 >> I think not doing the updated o/a (in case the SDP is not aligned with=20 >> the selected candidates) would cause serious problems in environments=20 >> where you have intermediaries etc that depend on correct SDP=20 >> information, e.g. to open gates etc. >>=20 >>=20 >> SOLUTION SUGGESTION: >> --------------------------------- >>=20 >> I DO understand that there are cases where the second o/a is not=20 >> needed, even if the SDP is not aligned with the selected candidates=20 >> (as the endpoints will get the information about selected candidates=20 >> from the STUN messages). However, I don't think we can assume that the=20 >> offerer knows when that is the case. >>=20 >> So, if people don't want to keep the current rules, one alternative=20 >> would to indicate in the ANSWER whether the second offer is needed or=20 >>not. > >How would the answerer know that, if the offerer didn't? The answerer, and/or the intermediaries. The point is that whoever needs th= e second offer is given a chance to indicate so to the offerer. Regards, Christer > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: 14. lokakuuta 2014 11:15 > To: mmusic > Subject: [MMUSIC] ICE updated offer >=20 > Hi all, >=20 > At the Toronto meeting we discussed whether we should change the=20 > behavior with ICE updated offer. Currently, based on RFC 5245, when=20 > ICE has finished, there is a new offer/answer with the selected=20 > candidate, > *if* they are different from the "default candidates", i.e., the ones=20 > in original o/a m- and c-lines. >=20 > Based on the discussion there was strong desire to have an option of=20 > not doing the updated o/a at all by indicating this in the original=20 > o/a. On the other hand, for some, the updated o/a was seen as a=20 > requirement for getting correct behavior from the network in certain=20 > scenarios (e.g., with SIP- aware middle boxes). >=20 > I would like to hear from people, who have issues making the updated=20 > o/a optional, how bad the change would be and is there a way we could=20 > make this work also in those scenarios? >=20 >=20 > Cheers, > Ari >=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 nobody Tue Oct 14 09:19:41 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C541A89E0 for ; Tue, 14 Oct 2014 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7rlFeUHijfS for ; Tue, 14 Oct 2014 09:19:39 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DE91A89BB for ; Tue, 14 Oct 2014 09:19:39 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so8509842qgf.7 for ; Tue, 14 Oct 2014 09:19:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=uKhL1yzP3qLCJij03zno9hV8aWQI7tsWfk3H577Tn38=; b=DVluh0SlpeS1VZ2Aqs+3WTucffktbWFzjmloeiaLaQyswi8dPvGnDsoJ7IhAhtnOsz wIA9ZT6dtn56yJ2ldQu5cuFkdp3/UboUlTSfbVcm1Nly8qanHWvAsMpwFUT+MRkT/Xnb uNwCgUH/W0QdNNeAS7jzxsGfzSxKI/esI2/UBADt0lBdq77865MrcZgwHtozb2NjgkNO Ty8vtttbAZ90+MwEl5JkM6mTOeBcWT7ztXIEc7Zb9TG2sWJM2xFBsKty3iYfamtAGjjt JCI1mVehnr5dQ7cZQaEhuMkNymtdiM3dtg0T8TLSwYDmzUC8RVZsm32XqpztbYhNBUst TcbQ== X-Gm-Message-State: ALoCoQk1fNhxsgK0f6C+uDQ4cf/HicOwz3iyB0yQ0FpRzxZSgkAmBIeY6m86/le4ehoJWxdlS2lv X-Received: by 10.229.37.138 with SMTP id x10mr10858985qcd.5.1413303578714; Tue, 14 Oct 2014 09:19:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Tue, 14 Oct 2014 09:19:17 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 14 Oct 2014 18:19:17 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8kZilKWLC8nDR8fmB2CiH5iwD2k Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 16:19:40 -0000 2014-10-14 10:44 GMT+02:00 Christer Holmberg : > I think not doing the updated o/a (in case the SDP is not aligned with th= e selected candidates) would cause serious problems in environments where y= ou have intermediaries etc that depend on correct SDP information, e.g. to = open gates etc. Once the PC is connected, inspect the selected candidates via RTCStats, mangle your funny SDP with your custom JS code, and send your needed SDP re-offer to your server. No need to bore the native WebRTC API with that stuff. --=20 I=C3=B1aki Baz Castillo From nobody Tue Oct 14 10:10:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A581A8F3A for ; Tue, 14 Oct 2014 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL8_wkZD32-b for ; Tue, 14 Oct 2014 10:10:28 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1971A8F37 for ; Tue, 14 Oct 2014 10:09:03 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id h11so7482188wiw.5 for ; Tue, 14 Oct 2014 10:09:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R0TC6mX43DIiosHf2bdTaxhObeDEPA5bgwjaKAMhSJw=; b=OqNDFR3INVYvnPChPU3G/2En9kJM/Hq39BxKl2ptys0CiNgkm1a/3hT1HK+miQoldy NUMH1uDffMTpmMWJBcZdKzl8wyOTLt9+RttXj5YDnUadqbB8WCsEWp+51GtjTFUjqJQ9 CdnlrMZpANZKdt7nR9Nzh+burTxQ4A5atzAg7UMi1W9rRjjutqwUXRzV9JLE4pDToMno NaDdOAig0cRA150xo6rHzwwxAsBoz7tRYiMc/kBpkRG1TckHJiMuEEh9Ilkr98/qQvTn jzL21ibQcnW8qT+V8Bml984Us9ocfbDee5DaoiNMwICOkc/4CdhgGqKOGN//JaXDmxq3 fClg== X-Gm-Message-State: ALoCoQnxf4PsYyDEeawHyxBYEPxA6ULhQOLq4Qes4SHsxpW0T2C9yjmyyumMTOEMSr4Y3CMmKJLl X-Received: by 10.180.108.43 with SMTP id hh11mr6638566wib.80.1413306541000; Tue, 14 Oct 2014 10:09:01 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id p2sm16385947wiy.1.2014.10.14.10.08.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 10:08:59 -0700 (PDT) Message-ID: <543D58AE.4090307@jitsi.org> Date: Tue, 14 Oct 2014 19:09:02 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D47C432@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47C432@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/frv3OR8Z-fRdaPYQyNf59wfbRPw Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 17:10:31 -0000 On 14.10.14, 17:27, Christer Holmberg wrote: > Hi, > >>> ISSUES: ---------- >>> >>> I think not doing the updated o/a (in case the SDP is not aligned >>> with the selected candidates) would cause serious problems in >>> environments where you have intermediaries etc that depend on >>> correct SDP information, e.g. to open gates etc. >> >> Opening gates needs to happen from the first O/A though. Right? >> Otherwise ICE checks are not going to succeed. > > Correct. Depending on policy, you may open gates in order to allow > STUN requests associated with all candidates to pass, perhaps with > limited bandwidth. According to 5245 pacing interval has to be calculated to match the bitrate of the intended media session so limiting the bandwidth doesn't sound like a good thing to do here. > >>> SOLUTION SUGGESTION: --------------------------------- >>> >>> I DO understand that there are cases where the second o/a is not >>> needed, even if the SDP is not aligned with the selected >>> candidates (as the endpoints will get the information about >>> selected candidates from the STUN messages). However, I don't >>> think we can assume that the offerer knows when that is the >>> case. >>> >>> So, if people don't want to keep the current rules, one >>> alternative would to indicate in the ANSWER whether the second >>> offer is needed or not. >> >> I don't really mind this (especially if the default is: don't send >> an update) ... but, I'd also like to understand the exact use case >> where this is necessary. The only one I can think of is a middle >> box that introduces relayed candidates. I don't find this to be a >> compelling arguments since that > relay can simply timeout if >> necessary. > > Perhaps there could be some timeout logic (and for some functions > there are), but that is not how much of the existing deployments work > today. They rely on the controller setting the gates, bandwidth, etc, > based on SDP information. I might be off but I don't think the plan is to impose this condition on the past (although I don't think many implementations actually do this). I suppose we are trying to decide whether future implementations would need to treat this as mandatory. If an implementation declares itself as not supporting 5245bis, or one of its specific features, then yes, I would assume the O/A update would still have to happen. Emil > Regards, > > Christer > > > >> -----Original Message----- From: mmusic >> [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Keränen Sent: >> 14. lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated >> offer >> >> Hi all, >> >> At the Toronto meeting we discussed whether we should change the >> behavior with ICE updated offer. Currently, based on RFC 5245, >> when ICE has finished, there is a new offer/answer with the >> selected candidate, *if* they are different from the "default >> candidates", i.e., the ones in original o/a m- and c-lines. >> >> Based on the discussion there was strong desire to have an option >> of not doing the updated o/a at all by indicating this in the >> original o/a. On the other hand, for some, the updated o/a was seen >> as a requirement for getting correct behavior from the network in >> certain scenarios (e.g., with SIP-aware middle boxes). >> >> I would like to hear from people, who have issues making the >> updated o/a optional, how bad the change would be and is there a >> way we could make this work also in those scenarios? >> >> >> Cheers, Ari >> >> _______________________________________________ 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 >> > > -- https://jitsi.org > -- https://jitsi.org From nobody Tue Oct 14 10:26:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D914A1A9091 for ; Tue, 14 Oct 2014 10:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXrcLq3iZ8ak for ; Tue, 14 Oct 2014 10:26:41 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2763F1A90B0 for ; Tue, 14 Oct 2014 10:26:17 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-d5-543d5cb72621 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 95.66.21334.7BC5D345; Tue, 14 Oct 2014 19:26:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 19:26:15 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTAgABgKoCAADKgQA== Date: Tue, 14 Oct 2014 17:26:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47C7A6@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> 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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvje6OGNsQgz1POS2m77OxmLr8MYsD k8e5hvfsHkuW/GQKYIrisklJzcksSy3St0vgyvj+4zh7wSS2its3W9gbGP+wdjFyckgImEjs X98HZYtJXLi3nq2LkYtDSOAoo8TvSWfYIZwljBKdz28zdTFycLAJWEh0/9MGaRARsJH4d+EC O4jNLBAu8eDHanaQEmEBdYkp9xQgSjQkFlz7wghhO0n8efyFGaSERUBV4vjfWJAwr4CvxNtj fxghNm1jlHh2eAUbSIJTIFDi5KPvzCA2I9Bt30+tYYJYJS5x68l8JoibBSSW7DnPDGGLSrx8 /A/qFyWJtYe3s4DsYhbQlFi/Sx+iVVFiSvdDdoi9ghInZz5hmcAoNgvJ1FkIHbOQdMxC0rGA kWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmDcHNzyW3cH4+rXjocYBTgYlXh4FzTbhAix JpYVV+YeYpTmYFES5110bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbn0J4HHld61fia Xj7buJ/7gu9Ry8Y8jiNdWs8+3uSpeXPRRt54zrmeZMUnTs9mpDIdyHz41ub4bZYp8X6pJc0d 0VMi5f3Yq6Uvbv7Zfo+JUXq3vv7cN4nNzc3Wv63M7l5aZzDv5yeTuHNv7/XqXf8SWrPGms18 lZ3PtgCFVTU3L3i83zvt7mwlluKMREMt5qLiRAD+eIBVfAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/R-BiJFqdVuwno8_4_97ghwSvzlw Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 17:26:43 -0000 SGksDQoNCj4+IEkgdGhpbmsgbm90IGRvaW5nIHRoZSB1cGRhdGVkIG8vYSAoaW4gY2FzZSB0aGUg U0RQIGlzIG5vdCBhbGlnbmVkIHdpdGggdGhlIHNlbGVjdGVkIA0KPj4gY2FuZGlkYXRlcykgd291 bGQgY2F1c2Ugc2VyaW91cyBwcm9ibGVtcyBpbiBlbnZpcm9ubWVudHMgd2hlcmUgeW91IGhhdmUg aW50ZXJtZWRpYXJpZXMgPj4gZXRjIHRoYXQgZGVwZW5kIG9uIGNvcnJlY3QgU0RQIGluZm9ybWF0 aW9uLCBlLmcuIHRvIG9wZW4gZ2F0ZXMgZXRjLg0KPg0KPiBPbmNlIHRoZSBQQyBpcyBjb25uZWN0 ZWQsIGluc3BlY3QgdGhlIHNlbGVjdGVkIGNhbmRpZGF0ZXMgdmlhIFJUQ1N0YXRzLCBtYW5nbGUg eW91ciBmdW5ueSA+IFNEUCB3aXRoIHlvdXIgY3VzdG9tIEpTIGNvZGUsIGFuZCBzZW5kIHlvdXIg bmVlZGVkIFNEUCByZS1vZmZlciB0byB5b3VyIHNlcnZlci4NCj4gTm8gbmVlZCB0byBib3JlIHRo ZSBuYXRpdmUgV2ViUlRDIEFQSSB3aXRoIHRoYXQgc3R1ZmYuDQoNCklDRSBpcyBhbHNvIHVzZWQg ZWxzZXdoZXJlIHRoYW4gaW4gV2ViUlRDLiANCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoN Cg== From nobody Tue Oct 14 10:32:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5631A90C3 for ; Tue, 14 Oct 2014 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXYo3F5zKQaf for ; Tue, 14 Oct 2014 10:32:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6421A90B0 for ; Tue, 14 Oct 2014 10:32:12 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-b4-543d5e1ac615 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.D0.24955.A1E5D345; Tue, 14 Oct 2014 19:32:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 19:32:10 +0200 From: Christer Holmberg To: Emil Ivov , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTAgABCdgCAAC5W8P///UUAgAAmoPA= Date: Tue, 14 Oct 2014 17:32:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47C7CC@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D47C432@ESESSMB209.ericsson.se> <543D58AE.4090307@jitsi.org> In-Reply-To: <543D58AE.4090307@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja50nG2IwdMNrBZrdk5gsZi6/DGL A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgyli3zajgi0LF3k/vWRoYL0t1MXJySAiYSLx5 s5EJwhaTuHBvPVsXIxeHkMBRRondj34yQjhLGCUOPu1i72Lk4GATsJDo/qcN0iAiUCbRcmEz E0hYWEBdYso9BYiwhsSCa18YIWw/icszD7GA2CwCqhKz9u1nB7F5BXwljt7qYIEY/5FR4kPT HmaQBKeApsTxP3vBDmIEOuj7qTVgNrOAuMStJ/OhDhWQWLLnPDOELSrx8vE/VghbSWLt4e0s EPV6EjemTmGDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqclJtu ZKyXWpSZXFycn6eXl1qyiREYIwe3/FbdwXj5jeMhRgEORiUe3gXNNiFCrIllxZW5hxilOViU xHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxObrTolR54vQJPgu5RVQZTymfs7vy s69bIzTb7HSXoEx+3KxC2QLpcMsDKxfvs9eyChe4uLCidvqZiqy8ydcPyf5XEAp1fie+ZONU a+vE/PMepjsd+8vqWO2vSt48Y/Dd5Rvnkf1i8m37BVdcEJeIyv5v/+uXvuhiz1yz4GNu6rXs Xxs5JyuxFGckGmoxFxUnAgBR+Ng4cgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/h7WdZ3SaDCHzxAQ1vHc-9AEHrvw Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 17:32:24 -0000 Hi, >>>> ISSUES: ---------- >>>> >>>> I think not doing the updated o/a (in case the SDP is not aligned=20 >>>> with the selected candidates) would cause serious problems in=20 >>>> environments where you have intermediaries etc that depend on=20 >>>> correct SDP information, e.g. to open gates etc. >>> >>> Opening gates needs to happen from the first O/A though. Right? >>> Otherwise ICE checks are not going to succeed. >> >> Correct. Depending on policy, you may open gates in order to allow=20 >> STUN requests associated with all candidates to pass, perhaps with=20 >> limited bandwidth. > >According to 5245 pacing interval has to be calculated to match the bitrat= e of the intended >media session so limiting the bandwidth doesn't sound li= ke a good thing to do here. It is nowhere said that you have to do that, but it is what people sometime= s do. >>>> SOLUTION SUGGESTION: --------------------------------- >>>> >>>> I DO understand that there are cases where the second o/a is not=20 >>>> needed, even if the SDP is not aligned with the selected candidates=20 >>>> (as the endpoints will get the information about selected candidates=20 >>>> from the STUN messages). However, I don't think we can assume that=20 >>>> the offerer knows when that is the case. >>>> >>>> So, if people don't want to keep the current rules, one alternative=20 >>>> would to indicate in the ANSWER whether the second offer is needed=20 >>>> or not. >>> >>> I don't really mind this (especially if the default is: don't send an=20 >>> update) ... but, I'd also like to understand the exact use case where=20 >>> this is necessary. The only one I can think of is a middle box that=20 >>> introduces relayed candidates. I don't find this to be a compelling=20 >>> arguments since that > relay can simply timeout if necessary. >> >> Perhaps there could be some timeout logic (and for some functions=20 >> there are), but that is not how much of the existing deployments work=20 >> today. They rely on the controller setting the gates, bandwidth, etc,=20 >> based on SDP information. > > I might be off but I don't think the plan is to impose this condition on = the past (although I=20 > don't think many implementations actually do this).=20 > I suppose we are trying to decide whether future implementations would ne= ed to treat this > as mandatory. > > If an implementation declares itself as not supporting 5245bis, or one of= its specific features, > then yes, I would assume the O/A update would sti= ll have to happen. Again, I am perfectly fine by not mandating the O/A update, as long as it i= s possible to trigger it if needed. Regards, Christer >> -----Original Message----- From: mmusic=20 >> [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen Sent: >> 14. lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated=20 >> offer >> >> Hi all, >> >> At the Toronto meeting we discussed whether we should change the=20 >> behavior with ICE updated offer. Currently, based on RFC 5245, when=20 >> ICE has finished, there is a new offer/answer with the selected=20 >> candidate, *if* they are different from the "default candidates",=20 >> i.e., the ones in original o/a m- and c-lines. >> >> Based on the discussion there was strong desire to have an option of=20 >> not doing the updated o/a at all by indicating this in the original=20 >> o/a. On the other hand, for some, the updated o/a was seen as a=20 >> requirement for getting correct behavior from the network in certain=20 >> scenarios (e.g., with SIP-aware middle boxes). >> >> I would like to hear from people, who have issues making the updated=20 >> o/a optional, how bad the change would be and is there a way we could=20 >> make this work also in those scenarios? >> >> >> Cheers, Ari >> >> _______________________________________________ mmusic mailing list=20 >> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ mmusic mailing list=20 >> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >> > > -- https://jitsi.org > -- https://jitsi.org From nobody Tue Oct 14 10:50:01 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33491A90E9; Tue, 14 Oct 2014 10:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95DIotI2BcVw; Tue, 14 Oct 2014 10:49:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AFD1A90FF; Tue, 14 Oct 2014 10:49:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014174952.6716.67218.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 10:49:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tBNsoR8JlLDof9uIG_c5Pt2R9iA Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 17:49:58 -0000 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 : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-07.txt Pages : 19 Date : 2014-10-14 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "m-line" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-msid-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 14 11:06:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F84A1A924B for ; Tue, 14 Oct 2014 11:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSe17e3fqIb9 for ; Tue, 14 Oct 2014 11:06:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644831A9245 for ; Tue, 14 Oct 2014 11:06:17 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-f9-543d6617cfbb Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 09.E4.04387.7166D345; Tue, 14 Oct 2014 20:06:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 20:06:14 +0200 From: Christer Holmberg To: Colin Perkins , Flemming Andreasen Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments Thread-Index: Ac/n1XBtzTLmfbOlQvSkbOT9iPCTaQ== Date: Tue, 14 Oct 2014 18:06:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47C8AD@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvja54mm2IwfmjghbLX55gtPjUvYHN 4v0FXYupyx+zOLB4TPm9kdVj2v37bB5Llvxk8vhy+TNbAEsUl01Kak5mWWqRvl0CV8aLhytZ C6aLVRzc+oKtgXG/YBcjJ4eEgIlE074dTBC2mMSFe+vZuhi5OIQEjjJKvNl/hRHCWcIocW/v N/YuRg4ONgELie5/2iANIgJ+Eu0tG8AamAWmMkrsP/YabJKwQLzEs+3fWSCKEiRuXn3GBGHr Scx++4oFZA6LgKrEurOiICavgK/Enm5ukApGoBu+n1oDVs0sIC5x68l8qNsEJJbsOc8MYYtK vHz8jxXCVpJYe3g7C0S9jsSC3Z/YIGxtiWULX4PV8woISpyc+YRlAqPILCRjZyFpmYWkZRaS lgWMLKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAmPm4JbfVjsYDz53PMQowMGoxMO7oNkm RIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHrsejApbLav x8pVFhNjDNibC6omsJ+4e/+Cwc5rgh9uqB36ouS+8N/BZed0fmzdeLXu3uqYF/aCd1JX/b3j /7FG1dmsW/pt/hOp3dkL2A89bhL/unW1dG0lr+i1eR0LvNes0Znx7F5C6Il3u3OWBt2uVJ55 O0p/756KqrlTeia06fu6+k1scJ6kxFKckWioxVxUnAgAnHiwOXoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rR8Z04CfcLduck-uB9eIr4QC194 Cc: "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 18:06:19 -0000 Hi Colin, Thanks for your comments! See inline. >- Section 1, 7th paragraph: typo "a new RTP SDES item" -> "a new RTCP SDES= item" I actually use "RTP SDES item" and "RTP MID SDES item" terminology in quite= a few places. The reason is because that is what they are called in the IANA registry: http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-par= ameters-5 But, I have problem to change to "RTCP SDES item" if that is the correct te= rminology :) ------------------------ >- Section 10.1.1: the third bullet point says that a given SSRC "SHOULD NO= T" transmit RTP >packets using payload types that originate from different = bundled "m=3D" lines, and follows >this with an explanatory note. Given the= problems that SSRC reuse will cause, I suggest >strengthening this to "MUS= T NOT", then adding a further note to address the case where >SSRC reuse wo= rks saying "However, once an SSRC has left the RTP session by sending an >R= TCP BYE packet, that SSRC value can later be reused by another source, poss= ibly on a >different bundled m=3D line".=20 So, something like: o A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled "m=3D" lines. NOTE: The last bullet above is to avoid sending multiple media types from the same SSRC. If transmission of multiple media types are done with time overlap, RTP and RTCP fail to function. Even if done in proper sequence this causes RTP Timestamp rate switching issues [RFC7160]. However, once an SSRC has left the RTP session (by sending an RTCP BYE packet), that SSRC value can later be reused by another sour= ce (possible associated with a different bundled "m=3D" line. ------------------------ >- Section 10.3.1: the last sentence is unclear what separate 5-tuple will = be used if RTP/RTCP >multiplexing is not enabled. This is explained in Sect= ion 10.3.2.3, and the draft would be >clearer if 10.3.1 referenced this. While I agree that it would make the text clearer, I was asked to avoid for= ward referencing. But, as 10.3.1 is a General section, I assume it doesn't matter. ------------------------ > - Section 13.2: it may be useful to clarify that the mid value is not zer= o terminated. Can you suggest text? :) ------------------------ > - Section 13.3: again, clarify that the mid value is not zero terminated.= It may also be useful > to remind implementers that the RFC 5285 format re= quires padding out to the next 32-bit=20 > boundary using zero bytes if the size of the header extension isn't a mul= tiple of 32 bits. This > padding could easily be confused with a terminatin= g zero by a careless implementer. Can you suggest text? :) Regards, Christer From nobody Tue Oct 14 11:22:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5DD1ACD4A for ; Tue, 14 Oct 2014 11:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxHBdgEMb4xN for ; Tue, 14 Oct 2014 11:22:32 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AB41ACD46 for ; Tue, 14 Oct 2014 11:22:31 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id d1so10998951wiv.12 for ; Tue, 14 Oct 2014 11:22:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xUik0ImxocoyqS7spNBhMmBo9nhXMc8OTd67bsM94wk=; b=a8QyymF3lQ6WVJwQmEIl/oQqfR971BEdTgom9LcmHeDrt9RSi6+1aKKjsdEXuP9HoW BXiIZJpOyviHYOvkdwGq24gYFglEsCPanp23Wx9wx5T1w1d1UV6aKlh4ndt0YvvlP2+K j7Yw4GDBjfQCEyV3FRg7ijie7SyPMRt/H25c2DaYitvB8YGWaxxkRb94+Anp4/zH2SvR l6kTIPaqz512Ml1d7QBeQgvMB9XP503GKjf6erSV2Jtta91DvTGUXhjFxcju6kfvykr1 nrA5jmMn4KTUbNCUj5egKoPQDvLH0Tf1pijrFsiONa1OP+IwVAolj+MS2o1wUCCq3+ym nrkA== X-Gm-Message-State: ALoCoQlsZ/n1E508BfXZF8p8B8L0U814iWXFXxpZp5DhpJwJjZPu0YbMp7kNGEi6jyJHuhNjzwOg X-Received: by 10.194.100.98 with SMTP id ex2mr6811158wjb.48.1413310950709; Tue, 14 Oct 2014 11:22:30 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id he2sm16595096wib.4.2014.10.14.11.22.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 11:22:29 -0700 (PDT) Message-ID: <543D69E8.1020704@jitsi.org> Date: Tue, 14 Oct 2014 20:22:32 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D47C432@ESESSMB209.ericsson.se> <543D58AE.4090307@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D47C7CC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47C7CC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZAsEIoO6f-Aq878C6zCgevmy-Ks Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 18:22:34 -0000 On 14.10.14, 19:32, Christer Holmberg wrote: > Hi, > >>>>> ISSUES: ---------- >>>>> >>>>> I think not doing the updated o/a (in case the SDP is not aligned >>>>> with the selected candidates) would cause serious problems in >>>>> environments where you have intermediaries etc that depend on >>>>> correct SDP information, e.g. to open gates etc. >>>> >>>> Opening gates needs to happen from the first O/A though. Right? >>>> Otherwise ICE checks are not going to succeed. >>> >>> Correct. Depending on policy, you may open gates in order to allow >>> STUN requests associated with all candidates to pass, perhaps with >>> limited bandwidth. >> >> According to 5245 pacing interval has to be calculated to match the bitrate of the intended >media session so limiting the bandwidth doesn't sound like a good thing to do here. > > It is nowhere said that you have to do that, but it is what people sometimes do. Have a look at 5245, 16.1: These formulas are aimed at causing STUN transactions to be paced at the same rate as media. This ensures that ICE will work properly under the same network conditions needed to support the media as well. and then 5245, B.1 The definition of a "reasonable" rate is that STUN should not use more bandwidth than the RTP itself will use, once media starts flowing. The formula for Ta is designed so that, if a STUN packet were sent every Ta seconds, it would consume the same amount of bandwidth as RTP packets, summed across all media streams. >>>>> SOLUTION SUGGESTION: --------------------------------- >>>>> >>>>> I DO understand that there are cases where the second o/a is not >>>>> needed, even if the SDP is not aligned with the selected candidates >>>>> (as the endpoints will get the information about selected candidates >>>>> from the STUN messages). However, I don't think we can assume that >>>>> the offerer knows when that is the case. >>>>> >>>>> So, if people don't want to keep the current rules, one alternative >>>>> would to indicate in the ANSWER whether the second offer is needed >>>>> or not. >>>> >>>> I don't really mind this (especially if the default is: don't send an >>>> update) ... but, I'd also like to understand the exact use case where >>>> this is necessary. The only one I can think of is a middle box that >>>> introduces relayed candidates. I don't find this to be a compelling >>>> arguments since that > relay can simply timeout if necessary. >>> >>> Perhaps there could be some timeout logic (and for some functions >>> there are), but that is not how much of the existing deployments work >>> today. They rely on the controller setting the gates, bandwidth, etc, >>> based on SDP information. >> >> I might be off but I don't think the plan is to impose this condition on the past (although I >> don't think many implementations actually do this). >> I suppose we are trying to decide whether future implementations would need to treat this > as mandatory. >> >> If an implementation declares itself as not supporting 5245bis, or one of its specific features, > then yes, I would assume the O/A update would still have to happen. > > Again, I am perfectly fine by not mandating the O/A update, as long as it is possible to trigger it if needed. I seem to remember that this is pretty much the consensus we reached in Toronto. Emil > Regards, > > Christer > > > > >>> -----Original Message----- From: mmusic >>> [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Keränen Sent: >>> 14. lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated >>> offer >>> >>> Hi all, >>> >>> At the Toronto meeting we discussed whether we should change the >>> behavior with ICE updated offer. Currently, based on RFC 5245, when >>> ICE has finished, there is a new offer/answer with the selected >>> candidate, *if* they are different from the "default candidates", >>> i.e., the ones in original o/a m- and c-lines. >>> >>> Based on the discussion there was strong desire to have an option of >>> not doing the updated o/a at all by indicating this in the original >>> o/a. On the other hand, for some, the updated o/a was seen as a >>> requirement for getting correct behavior from the network in certain >>> scenarios (e.g., with SIP-aware middle boxes). >>> >>> I would like to hear from people, who have issues making the updated >>> o/a optional, how bad the change would be and is there a way we could >>> make this work also in those scenarios? >>> >>> >>> Cheers, Ari >>> >>> _______________________________________________ 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 >>> >> >> -- https://jitsi.org >> > > -- > https://jitsi.org > -- https://jitsi.org From nobody Tue Oct 14 11:29:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A2B1ACD94 for ; Tue, 14 Oct 2014 11:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-CIbYlqs74S for ; Tue, 14 Oct 2014 11:29:17 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657511ACD86 for ; Tue, 14 Oct 2014 11:29:17 -0700 (PDT) Received: from [81.187.2.149] (port=46651 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xe6qQ-0005aA-0k; Tue, 14 Oct 2014 19:29:14 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47C8AD@ESESSMB209.ericsson.se> Date: Tue, 14 Oct 2014 19:29:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99CAC302-DF7B-4C7F-A5FD-3B6017811F88@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1D47C8AD@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZRvXWpTOrICrKW8wkc_XnYciKLw Cc: Flemming Andreasen , "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 18:29:19 -0000 Hi, On 14 Oct 2014, at 19:06, Christer Holmberg = wrote: > Hi Colin, >=20 > Thanks for your comments! See inline. >=20 >> - Section 1, 7th paragraph: typo "a new RTP SDES item" -> "a new RTCP = SDES item" >=20 > I actually use "RTP SDES item" and "RTP MID SDES item" terminology in = quite a few places. >=20 > The reason is because that is what they are called in the IANA = registry: >=20 > = http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-pa= rameters-5 >=20 > But, I have problem to change to =93RTCP SDES item" if that is the = correct terminology :) It=92s not especially important; I just want to make sure it=92s not = confused with RTP security descriptions, which is sometimes referred to = as SDES. > ------------------------ >=20 >> - Section 10.1.1: the third bullet point says that a given SSRC = "SHOULD NOT" transmit RTP >packets using payload types that originate = from different bundled "m=3D" lines, and follows >this with an = explanatory note. Given the problems that SSRC reuse will cause, I = suggest >strengthening this to "MUST NOT", then adding a further note to = address the case where >SSRC reuse works saying "However, once an SSRC = has left the RTP session by sending an >RTCP BYE packet, that SSRC value = can later be reused by another source, possibly on a >different bundled = m=3D line".=20 >=20 > So, something like: >=20 > o A given SSRC MUST NOT transmit RTP packets using payload types > that originate from different bundled "m=3D" lines. >=20 > NOTE: The last bullet above is to avoid sending multiple media types > from the same SSRC. If transmission of multiple media types are = done > with time overlap, RTP and RTCP fail to function. Even if done in > proper sequence this causes RTP Timestamp rate switching issues > [RFC7160]. However, once an SSRC has left the RTP session (by = sending > an RTCP BYE packet), that SSRC value can later be reused by another = source > (possible associated with a different bundled "m=3D" line. >=20 >=20 > =97=97=97=97=97=97=97=97=97=97=97=97 Sure. >> - Section 10.3.1: the last sentence is unclear what separate 5-tuple = will be used if RTP/RTCP >multiplexing is not enabled. This is explained = in Section 10.3.2.3, and the draft would be >clearer if 10.3.1 = referenced this. >=20 > While I agree that it would make the text clearer, I was asked to = avoid forward referencing. >=20 > But, as 10.3.1 is a General section, I assume it doesn't matter. >=20 > ------------------------ >=20 >> - Section 13.2: it may be useful to clarify that the mid value is not = zero terminated. >=20 > Can you suggest text? :) =93The mid value is not zero terminated=94 > ------------------------ >=20 >> - Section 13.3: again, clarify that the mid value is not zero = terminated. It may also be useful > to remind implementers that the RFC = 5285 format requires padding out to the next 32-bit=20 >> boundary using zero bytes if the size of the header extension isn't a = multiple of 32 bits. This > padding could easily be confused with a = terminating zero by a careless implementer. >=20 > Can you suggest text? :) =93The mid value is not zero terminated. Note, however, that RTP header = extensions that are not a multiple of 32 bits in length MUST be padded = to the next 32-bit boundary using zero bytes; these padding bytes are = not included in the header length field [RFC5285].=94 --=20 Colin Perkins https://csperkins.org/ From nobody Tue Oct 14 11:31:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A531ACD9D for ; Tue, 14 Oct 2014 11:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcM3-BHgo16a for ; Tue, 14 Oct 2014 11:31:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE891ACD97 for ; Tue, 14 Oct 2014 11:31:11 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-e2-543d6bedbb69 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 93.76.04387.DEB6D345; Tue, 14 Oct 2014 20:31:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 20:31:09 +0200 From: Christer Holmberg To: Emil Ivov , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTAgABCdgCAAC5W8P///UUAgAAmoPD//+3pAIAAIyPA Date: Tue, 14 Oct 2014 18:31:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47C980@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <543D341A.3040006@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D47C432@ESESSMB209.ericsson.se> <543D58AE.4090307@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1D47C7CC@ESESSMB209.ericsson.se> <543D69E8.1020704@jitsi.org> In-Reply-To: <543D69E8.1020704@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje7bbNsQg+mrrCzW7JzAYjF1+WMW ByaPJUt+Mnn8fxMYwBTFZZOSmpNZllqkb5fAlfFquUvBE4GKa5fPMDUwnuPtYuTkkBAwkdjQ v4AJwhaTuHBvPVsXIxeHkMBRRokVZ4+wQzhLGCX6PywBynBwsAlYSHT/0wZpEBEok2i5sJkJ JCwsoC4x5Z4CRFhDYsG1L4wQdpTE6v/HWUBKWARUJWbOigcJ8wr4Sty8fBesREjgCpPE7G1R IDangKbEkq6fYOcwAp3z/dQaMJtZQFzi1pP5UGcKSCzZc54ZwhaVePn4HyuErSSx9vB2Foh6 PYkbU6ewQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLS Sy3KTC4uzs/Ty0st2cQIjI+DW35b7WA8+NzxEKMAB6MSD++CZpsQIdbEsuLK3EOM0hwsSuK8 C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuHh7+1HjvBkVArLSCn8NkjvCRQIedb/0 Ewi55SbReD3EXOn71cTr7BmVnh8miq53+cDeer9vD8/00x66lir1/F/2Xnnjsaz53D25zJ9X +3fzT1j1vei48/U3wYJr5n7xbtxT7MCq8z5kpcfzyPl3w/fKPlb8Ks49KdpWw7vwR8jnB70p JxdUKrEUZyQaajEXFScCAO9MGXNwAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/V54NNUDeTyfYZhSxyaegdcE5Ziw Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 18:31:14 -0000 Hi, ... >> Again, I am perfectly fine by not mandating the O/A update, as long as i= t is possible to=20 >> trigger it if needed. > > I seem to remember that this is pretty much the consensus we reached in T= oronto. My understanding is that the consensus was to allow the offerer to indicate= whether it is going to send a second offer or not, without the answerer (o= r an intermediary) being able to impact that decision. I am asking for a wa= y for the answerer (or an intermediary) to tell the offerer whether the sec= ond offer is needed. Regards, Christer >>> -----Original Message----- From: mmusic=20 >>> [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen Sent: >>> 14. lokakuuta 2014 11:15 To: mmusic Subject: [MMUSIC] ICE updated=20 >>> offer >>> >>> Hi all, >>> >>> At the Toronto meeting we discussed whether we should change the=20 >>> behavior with ICE updated offer. Currently, based on RFC 5245, when=20 >>> ICE has finished, there is a new offer/answer with the selected=20 >>> candidate, *if* they are different from the "default candidates",=20 >>> i.e., the ones in original o/a m- and c-lines. >>> >>> Based on the discussion there was strong desire to have an option of=20 >>> not doing the updated o/a at all by indicating this in the original=20 >>> o/a. On the other hand, for some, the updated o/a was seen as a=20 >>> requirement for getting correct behavior from the network in certain=20 >>> scenarios (e.g., with SIP-aware middle boxes). >>> >>> I would like to hear from people, who have issues making the updated=20 >>> o/a optional, how bad the change would be and is there a way we=20 >>> could make this work also in those scenarios? >>> >>> >>> Cheers, Ari >>> >>> _______________________________________________ mmusic mailing list=20 >>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>> >>> _______________________________________________ mmusic mailing list=20 >>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- https://jitsi.org >> > > -- > https://jitsi.org > -- https://jitsi.org From nobody Tue Oct 14 12:23:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899EE1ACE6A for ; Tue, 14 Oct 2014 12:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkRYusHu0Hfc for ; Tue, 14 Oct 2014 12:23:38 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6B11ACE66 for ; Tue, 14 Oct 2014 12:23:37 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so11433847wgh.21 for ; Tue, 14 Oct 2014 12:23:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=rdC1NYBI8QpCIsrGNG1pKsw0TjLLNscfXFyy+oCreP0=; b=hqchbOYslrK1Bt4cVmLaKKuSzP9tJBcXx5AnSbmNW/BnivUqsrQiWBu1FudQmk5wqP qt8eOGfQvAKYYZRqoFO9ecBBWItvANT69+xH5cbIvqMjDK6TEc+1hT7jPehcQ6qURi7C EWOFwYKMGaHIzjLdItS4zAfQlVNIvthB5sUnVhW9hSbikmzeXk5xFU44bzQpuqISf6Sz uA7BfU48CjZtExi7PA/ugW+T9JdT7wezEjhRQPZQ5moryt5nd+zQA5PLIY5CGc47cmzf O6Ig1x+Ffx2J0/dyPGyQaSRh023c0DxzmZSUKQ24TUVA6eeIRC6oK9Cr+5OF9oRp/1rr IsOg== X-Gm-Message-State: ALoCoQl1XfStiF+3sgyZOdw7JahOOvZIoenAzdug5d8p1CD0l2KBlb4atktsu2KtpK6MJPAYZDMZ X-Received: by 10.180.99.67 with SMTP id eo3mr7489924wib.82.1413314615970; Tue, 14 Oct 2014 12:23:35 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by mx.google.com with ESMTPSA id lm9sm20492019wjc.45.2014.10.14.12.23.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 12:23:35 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so11740101wgh.12 for ; Tue, 14 Oct 2014 12:23:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.8 with SMTP id m8mr7305710wjq.43.1413314202721; Tue, 14 Oct 2014 12:16:42 -0700 (PDT) Received: by 10.216.176.65 with HTTP; Tue, 14 Oct 2014 12:16:42 -0700 (PDT) Date: Tue, 14 Oct 2014 15:16:42 -0400 Message-ID: From: Roman Shpount To: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=047d7ba976320260c7050566db16 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/85Tvw0dev02gIFlh1AJ3xs5GgW0 Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 19:23:51 -0000 --047d7ba976320260c7050566db16 Content-Type: text/plain; charset=UTF-8 Would the better solution for this entire problem be a SIP option that allows to suppress ICE restart on new empty re-invite? If both sides support this option (via the Supported header), then new offer is not sent in the end of the ICE process. If remote party needs it, then it can do an empty SIP re-INVITE with this flag set. If intermediary does not support this, they can remove the option from the Supported header in any direction and this will cause a new offer-answer transaction per old RFC. _____________ Roman Shpount --047d7ba976320260c7050566db16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would the better solution for this entire problem be a SIP= option that allows to suppress ICE restart on new empty re-invite? If both= sides support this option (via the Supported header), then new offer is no= t sent in the end of the ICE process. If remote party needs it, then it can= do an empty SIP re-INVITE with this flag set. If intermediary does not sup= port this, they can remove the option from the Supported header in any dire= ction and this will cause a new offer-answer transaction per old RFC.
_____________
Roman Shpount
--047d7ba976320260c7050566db16-- From nobody Tue Oct 14 16:20:47 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDBB1A000F for ; Tue, 14 Oct 2014 16:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZZ-yBDZ2s9Z for ; Tue, 14 Oct 2014 16:20:37 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.28]) by ietfa.amsl.com (Postfix) with ESMTP id E14DA1A0049 for ; Tue, 14 Oct 2014 16:20:36 -0700 (PDT) Received: from userPC (unknown [122.167.224.12]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 57AFD3C0138; Tue, 14 Oct 2014 23:20:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1413328836; bh=+3vxpc8XBDMkqDdms+qSd3IiPGzh8/QtEkNrFA0+Ick=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lD6ob1lxLfAtQsW55XarKAaORNyuIJ+X3ZV5ozBFgJ2Xtu4NHQYj6Lm+Bl9eeL4wM WMRJogoiD5C6aSzQAWNwf+DZ5xxR7eZFapM81ZBt6eIyNl7a1YB9ZhZM61+adg01mF lDe/k94PG+CyyTXyL//q4UQFQCuAzHtkWuDwbs88= From: "Parthasarathi R" To: "'Christer Holmberg'" , =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , "'mmusic'" References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> Date: Wed, 15 Oct 2014 04:50:21 +0530 Message-ID: <010501cfe805$72268000$56738000$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTAgADxSCA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020203.543DAFC4.004A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/wWohtzxLAN343mEROKA_b4jq9_o Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2014 23:20:45 -0000 +1 Adding further, SDP handling (signaling) entity and media handling = entities for the given session shall be different physical device in the answerer side. By not updating SDP information, the resource allocated by = signaling entity would not freed or used properly. STUN only based signaling = mechanism in the middle of the session leads to the issue in those architecture as = SDP handling entity will not aware of the conclusion. Please note that SDP handling (signaling) entity and media handling = entity as a different device in the answerer side is not defined in IETF RTCWeb = so far.=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Tuesday, October 14, 2014 2:14 PM > To: Ari Ker=E4nen; mmusic > Subject: Re: [MMUSIC] ICE updated offer >=20 > Hi, >=20 > ISSUES: > ---------- >=20 > I think not doing the updated o/a (in case the SDP is not aligned with > the selected candidates) would cause serious problems in environments > where you have intermediaries etc that depend on correct SDP > information, e.g. to open gates etc. >=20 >=20 > SOLUTION SUGGESTION: > --------------------------------- >=20 > I DO understand that there are cases where the second o/a is not > needed, even if the SDP is not aligned with the selected candidates = (as > the endpoints will get the information about selected candidates from > the STUN messages). However, I don't think we can assume that the > offerer knows when that is the case. >=20 > So, if people don't want to keep the current rules, one alternative > would to indicate in the ANSWER whether the second offer is needed or > not. >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari = Ker=E4nen > Sent: 14. lokakuuta 2014 11:15 > To: mmusic > Subject: [MMUSIC] ICE updated offer >=20 > Hi all, >=20 > At the Toronto meeting we discussed whether we should change the > behavior with ICE updated offer. Currently, based on RFC 5245, when = ICE > has finished, there is a new offer/answer with the selected candidate, > *if* they are different from the "default candidates", i.e., the ones > in original o/a m- and c-lines. >=20 > Based on the discussion there was strong desire to have an option of > not doing the updated o/a at all by indicating this in the original > o/a. On the other hand, for some, the updated o/a was seen as a > requirement for getting correct behavior from the network in certain > scenarios (e.g., with SIP-aware middle boxes). >=20 > I would like to hear from people, who have issues making the updated > o/a optional, how bad the change would be and is there a way we could > make this work also in those scenarios? >=20 >=20 > Cheers, > Ari >=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 nobody Tue Oct 14 23:56:00 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C01C1A038D for ; Tue, 14 Oct 2014 23:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RGUj5bevxKG for ; Tue, 14 Oct 2014 23:55:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6F01A0383 for ; Tue, 14 Oct 2014 23:55:57 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-b2-543e1a7a59e2 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E6.FA.24955.A7A1E345; Wed, 15 Oct 2014 08:55:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 08:55:53 +0200 From: Christer Holmberg To: Roman Shpount , "mmusic@ietf.org" Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP5+NicCZjzEhGnkuH0Ney21PC/JwwuWOQ Date: Wed, 15 Oct 2014 06:55:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> References: 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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D47D84CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+JvjW61lF2IQetRVoupyx+zWMy4MJXZ gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZTw63stU8M614sv8zWwNjF+cuxg5OSQETCSa dl9lh7DFJC7cW8/WxcjFISRwlFHi2Kc9zCAJIYEljBJHpmR1MXJwsAlYSHT/0wYJiwh4SXQ/ uM4GEhYWUJeYck8BIqwhseDaF0YI20ji241VYFNYBFQlGhdPZAOxeQV8JW71XGaEmB4gMXfT D2aQMZwCgRIrN1eChBmBrvl+ag0TiM0sIC5x68l8JogrBSSW7DnPDGGLSrx8/I8VwlaSaFzy hBVkDLNAvsT2FTUQmwQlTs58wjKBUWQWkkmzEKpmIamCCGtKrN+lD1GtKDGl+yE7hK0h0Tpn Ljuy+AJG9lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgZF0cMtv1R2Ml984HmIU4GBU4uFV uGobIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKX0rqTq r1GY2L+SXfiCUPDz11OU9ml2saVdWiTUb8Txb6PfOa4XjOnfmVZp3i2T51mWE3xM4lb0ow2Z ddeU5jHlLgr/eHWmksLX/1c0N5lFlvd03H0edWadzeKiXbWes/f8rfE59agt5fFq+2v2ns6d 6SdeC34wvv7/9cmNruF9t/iE182MeaXEUpyRaKjFXFScCADWM3tMhQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aERmiIunQ9DsXY5sLtZEplUyLnM Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 06:55:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D47D84CESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRvIGJhc2Ugc29sdXRpb25zIG9uIHRoZSBzZW5kaW5nIG9mIGVtcHR5IHJlLUlOVklU RXMgaXMgaW4gbXkgb3BpbmlvbiBub3QgYSB2ZXJ5IGdvb2QgaWRlYS4gQWxzbywgaXQgbWFrZXMg dGhpbmdzIHRyaWNreSBmb3IgaW50ZXJtZWRpYXJpZXMgdGhhdCBuZWVkIHRoZSBpbmZvcm1hdGlv bi4gSW4gb3JkZXIgZm9yIHRoZW0gdG8gdHJpZ2dlciByZS1JTlZJVEVzIHRoZXkgaGF2ZSB0byBi ZSBCMkJVQSwgYW5kIHRoYXQgd2lsbCB0aGVuIGNhdXNlIG90aGVyIHByb2JsZW1zLg0KDQpXaGF0 IEkgc3VnZ2VzdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIElDRSBhcyBkZWZpbmVkIHRvZGF5 LiBJdCBvbmx5IGFkZHMgc29tZSBraW5kIG9mIGluZGljYXRvciAoaWNlLW9wdGlvbnMgYXR0cmli dXRlIHZhbHVlPykgd2hldGhlciB0aGUgc2Vjb25kIG9mZmVyIGlzIG5lZWRlZCBvciBub3QuIFNp bXBsZSA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBtbXVzaWMgW21haWx0bzpt bXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFuIFNocG91bnQNClNlbnQ6 IDE0IE9jdG9iZXIgMjAxNCAyMjoxNw0KVG86IG1tdXNpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtNTVVTSUNdIElDRSB1cGRhdGVkIG9mZmVyDQoNCldvdWxkIHRoZSBiZXR0ZXIgc29sdXRpb24g Zm9yIHRoaXMgZW50aXJlIHByb2JsZW0gYmUgYSBTSVAgb3B0aW9uIHRoYXQgYWxsb3dzIHRvIHN1 cHByZXNzIElDRSByZXN0YXJ0IG9uIG5ldyBlbXB0eSByZS1pbnZpdGU/IElmIGJvdGggc2lkZXMg c3VwcG9ydCB0aGlzIG9wdGlvbiAodmlhIHRoZSBTdXBwb3J0ZWQgaGVhZGVyKSwgdGhlbiBuZXcg b2ZmZXIgaXMgbm90IHNlbnQgaW4gdGhlIGVuZCBvZiB0aGUgSUNFIHByb2Nlc3MuIElmIHJlbW90 ZSBwYXJ0eSBuZWVkcyBpdCwgdGhlbiBpdCBjYW4gZG8gYW4gZW1wdHkgU0lQIHJlLUlOVklURSB3 aXRoIHRoaXMgZmxhZyBzZXQuIElmIGludGVybWVkaWFyeSBkb2VzIG5vdCBzdXBwb3J0IHRoaXMs IHRoZXkgY2FuIHJlbW92ZSB0aGUgb3B0aW9uIGZyb20gdGhlIFN1cHBvcnRlZCBoZWFkZXIgaW4g YW55IGRpcmVjdGlvbiBhbmQgdGhpcyB3aWxsIGNhdXNlIGEgbmV3IG9mZmVyLWFuc3dlciB0cmFu c2FjdGlvbiBwZXIgb2xkIFJGQy4NCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D47D84CESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+VG8gYmFzZSBzb2x1dGlvbnMgb24gdGhlIHNlbmRpbmcgb2YgZW1w dHkgcmUtSU5WSVRFcyBpcyBpbiBteSBvcGluaW9uIG5vdCBhIHZlcnkgZ29vZCBpZGVhLiBBbHNv LCBpdCBtYWtlcyB0aGluZ3MgdHJpY2t5IGZvciBpbnRlcm1lZGlhcmllcw0KIHRoYXQgbmVlZCB0 aGUgaW5mb3JtYXRpb24uIEluIG9yZGVyIGZvciB0aGVtIHRvIHRyaWdnZXIgcmUtSU5WSVRFcyB0 aGV5IGhhdmUgdG8gYmUgQjJCVUEsIGFuZCB0aGF0IHdpbGwgdGhlbiBjYXVzZSBvdGhlciBwcm9i bGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPldoYXQgSSBzdWdnZXN0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gSUNF IGFzIGRlZmluZWQgdG9kYXkuIEl0IG9ubHkgYWRkcyBzb21lIGtpbmQgb2YgaW5kaWNhdG9yIChp Y2Utb3B0aW9ucyBhdHRyaWJ1dGUgdmFsdWU/KQ0KIHdoZXRoZXIgdGhlIHNlY29uZCBvZmZlciBp cyBuZWVkZWQgb3Igbm90LiBTaW1wbGUgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5Sb21hbiBTaHBvdW50PGJyPg0KPGI+U2VudDo8L2I+IDE0IE9j dG9iZXIgMjAxNCAyMjoxNzxicj4NCjxiPlRvOjwvYj4gbW11c2ljQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBJQ0UgdXBkYXRlZCBvZmZlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIHRoZSBiZXR0ZXIgc29sdXRpb24gZm9yIHRo aXMgZW50aXJlIHByb2JsZW0gYmUgYSBTSVAgb3B0aW9uIHRoYXQgYWxsb3dzIHRvIHN1cHByZXNz IElDRSByZXN0YXJ0IG9uIG5ldyBlbXB0eSByZS1pbnZpdGU/IElmIGJvdGggc2lkZXMgc3VwcG9y dCB0aGlzIG9wdGlvbiAodmlhIHRoZSBTdXBwb3J0ZWQgaGVhZGVyKSwgdGhlbiBuZXcgb2ZmZXIg aXMgbm90IHNlbnQgaW4gdGhlIGVuZCBvZiB0aGUgSUNFDQogcHJvY2Vzcy4gSWYgcmVtb3RlIHBh cnR5IG5lZWRzIGl0LCB0aGVuIGl0IGNhbiBkbyBhbiBlbXB0eSBTSVAgcmUtSU5WSVRFIHdpdGgg dGhpcyBmbGFnIHNldC4gSWYgaW50ZXJtZWRpYXJ5IGRvZXMgbm90IHN1cHBvcnQgdGhpcywgdGhl eSBjYW4gcmVtb3ZlIHRoZSBvcHRpb24gZnJvbSB0aGUgU3VwcG9ydGVkIGhlYWRlciBpbiBhbnkg ZGlyZWN0aW9uIGFuZCB0aGlzIHdpbGwgY2F1c2UgYSBuZXcgb2ZmZXItYW5zd2VyIHRyYW5zYWN0 aW9uIHBlcg0KIG9sZCBSRkMuPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7594FB04B1934943A5C02806D1A2204B1D47D84CESESSMB209erics_-- From nobody Wed Oct 15 03:08:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CCA1A1A0D for ; Wed, 15 Oct 2014 03:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZp9B_rJOTk6 for ; Wed, 15 Oct 2014 03:08:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064991A1A04 for ; Wed, 15 Oct 2014 03:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3517; q=dns/txt; s=iport; t=1413367685; x=1414577285; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=zEG0mjt8cWZ2OeO0z9Pojuwc9X/zJadSujRJ2tOr9LM=; b=VAgvyQTmTBf8S9tHPqhPLB3/gE9rmiYOp/qAV7y0UhkmHeih5py4LPmg HtDjf2wct3HplCabq9Ti+DizHz9YBagwe9MF3UhVgI2AIMotPeGl+wePB oL18Am8Vrj+6DhnkMb15D4xsd7c6Y1VH2p6jIAu2CVPvYSrpXV+pQE5lm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFANRGPlStJV2Q/2dsb2JhbABbgmsjU1zLe4dLgRgWAX2EAgEBAQMBOkQLAgEZAwECHxAyHQgCBBMJiC0IAQzIEAEBAQEBAQQBAQEBAQEBARqPbBEBC1KDJ4EeBZF9hESHEYEwPIMKiguHF4N3bAGBDjmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,723,1406592000"; d="scan'208";a="87121615" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 15 Oct 2014 10:08:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9FA84VQ019100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Oct 2014 10:08:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 05:08:04 -0500 From: "Ali C. Begen (abegen)" To: mmusic WG Thread-Topic: New draft discussion 4566bis IANA issues Thread-Index: AQHP6F/odnwNabFYHUaFU9++lc/OuQ== Date: Wed, 15 Oct 2014 10:08:03 +0000 Message-ID: <0C3D8AA4-DFC0-49C4-87B5-E47BF06B2DB8@cisco.com> References: <20141015095756.7536.80011.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.29.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <4AE7F8ABAB15204BA9DB3FF237F0BB13@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ajMjiVSsnAsHq9cmglEen7z5YPw Subject: [MMUSIC] New draft discussion 4566bis IANA issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 10:08:08 -0000 Hi everyone 4566bis draft had major changes in the last revision. It is pending WG's re= view (See Paul K.' email dated Sept. 23rd). 4566bis had other open issues as listed in the tracker. http://trac.tools.ietf.org/wg/mmusic/trac/report/1 For all the IANA related matters, I just submitted a new draft addressing t= ickets 15, 16, 17, 18 and 19. https://datatracker.ietf.org/doc/draft-begen-mmusic-rfc4566bis-iana-updates= / Please review this draft as the chairs will likely take an action on it in = the next meeting. It addresses all the issues we have identified so far in = the IANA registries for the SDP. Once we agree on these changes, we can eit= her publish that draft right away (and keep 4566bis open for a bit longer) = or move all the IANA changes to the 4566bis document and everything gets pu= blished together. That is a rather minor issues. Most importantly, we need = reviews and approvals for these IANA changes. There is another draft that will change the IANA registry structure for SDP= parameters and attributes (draft-ietf-mmusic-sdp-mux-attributes). To minim= ize the load on the IANA folks, we need to decide on these changes soon and= schedule things carefully. Any questions/comments, post to the list. -acbegen Begin forwarded message: > From: > Subject: New Version Notification for draft-begen-mmusic-rfc4566bis-iana-= updates-00.txt > Date: October 15, 2014 at 11:57:56 AM GMT+2 > To: Ali Begen , "Ali C. Begen" >=20 >=20 > A new version of I-D, draft-begen-mmusic-rfc4566bis-iana-updates-00.txt > has been successfully submitted by Ali Begen and posted to the > IETF repository. >=20 > Name: draft-begen-mmusic-rfc4566bis-iana-updates > Revision: 00 > Title: IANA Registry Updates for RFC 4566bis > Document date: 2014-10-15 > Group: Individual Submission > Pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-begen-mmusic-rf= c4566bis-iana-updates-00.txt > Status: https://datatracker.ietf.org/doc/draft-begen-mmusic-rfc45= 66bis-iana-updates/ > Htmlized: http://tools.ietf.org/html/draft-begen-mmusic-rfc4566bis-= iana-updates-00 >=20 >=20 > Abstract: > The Session Description Protocol (SDP) specification is currently > being revised. There are a number of issues that have been > identified in the IANA registries related to the SDP protocol (These > are tracked in the issue tracker). This document has the goal of > addressing these issues by making the necessary changes in the IANA > registries and registration procedures. >=20 > The changes and updates listed in this draft are submitted in this > individual draft rather than the 4566bis draft because (i) the > 4566bis draft has seen quite a number of changes recently, which > require a detailed review and further revisions would make the review > process difficult, and (ii) the changes and updates listed in this > draft are all IANA related matters. If this draft gets published > separately, it will update RFC 4566 or the RFC resulting from the > 4566bis draft. An alternative option is to include the whole text in > the 4566bis draft once the changes and updates are agreed. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Oct 15 03:16:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26581A1A13 for ; Wed, 15 Oct 2014 03:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vzxbUgpp0Rj for ; Wed, 15 Oct 2014 03:16:37 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696F51A000B for ; Wed, 15 Oct 2014 03:16:37 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id b13so734956qcw.6 for ; Wed, 15 Oct 2014 03:16:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=71OcWvj4faFWcXMgSHEZ0Q6lEKHwj0FgpIO03YxYo6M=; b=kBgN4UNLU8pcySc/jktrs+NNzzKObOUullvfp76YhLjvBe/qgxQcF574XA+gtxCCFb 1ThcUKL8pi4unD0zV277p7/NldpdmxWASZjVspsa2D7XnOixZdsfQfNTJemGyJB6G/pt 7fJgVat8Ynb0s82tRX8sPg74/vjGVZ53Sii+8xMzI8xF0/93BkCfrizw78xsNOlSwq/L eWO+eqjcTembmnt0QOXnUY/Fb3dGjzg3l42ULCK9NySgLQuUMiQM/IINqe7Gqsc0QTq4 +WnM+vfs6xxtF0j7/BWSw+8fadvGJHJar4jT6Gv5JSacNB4YjhB4QLqSiQiuImM43yNh VI+w== X-Gm-Message-State: ALoCoQmj4bCBOOmEj56fkyP0IxMJ7TAmiP5DBNb6dPoIRioyiwFX9++ag7mALygqDR+9AUZMaO77 X-Received: by 10.224.60.69 with SMTP id o5mr18494964qah.85.1413368196615; Wed, 15 Oct 2014 03:16:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 15 Oct 2014 03:16:16 -0700 (PDT) In-Reply-To: <010501cfe805$72268000$56738000$@co.in> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <010501cfe805$72268000$56738000$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 15 Oct 2014 12:16:16 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FQiZREDPSw6yYTLB5XxwDjfFzHw Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Christer Holmberg Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 10:16:39 -0000 2014-10-15 1:20 GMT+02:00 Parthasarathi R : > STUN only based signaling mechanism > in the middle of the session leads to the issue in those architecture as = SDP > handling entity will not aware of the conclusion. If the SDP handling "entity" is not aware of the media/STUN stuff then you have a big problem. > Please note that SDP handling (signaling) entity and media handling entit= y > as a different device in the answerer side is not defined in IETF RTCWeb = so > far. Of course. And what? Both "entities" are supposed to be the same, or to inter-communicate somehow one to each other. --=20 I=C3=B1aki Baz Castillo From nobody Wed Oct 15 03:18:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033691A1A12 for ; Wed, 15 Oct 2014 03:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xXDO_6JwxFX for ; Wed, 15 Oct 2014 03:18:24 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBB01A1A0F for ; Wed, 15 Oct 2014 03:18:24 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id x12so608317qac.3 for ; Wed, 15 Oct 2014 03:18:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=/o2mUhl1hYJX3kU40TQ+mHie4EW6q40zLxlxX9YnLD8=; b=RxpHULNOpN+6tf5545jJH3ngEyX5qrsizwXna8cGeTWsl4lERMWJxW1O5KMoBg3Yz7 V0YW6guBTFpOPgj37ZzQAAwUBhtoi7kRYbZlEvOV+hk8dvEvvXPyFicb3h7HhnBTYiFs jekj3rfAEN4fgCLEbSYPz29yQLGXcD1W8//N0Y4y85oizaTOMEfBG/nKsZyM+2bDaSU0 d7omFB2kjTvAR3UA4V+cslamMe2Kiq6KpsAZrmiNx6cKZNlQgryQxbf3OPj3y91UDkC/ tiZGE0VnvRo2c6a6uckYFsy5D4xgqO8CArZ+vEglOKY2Eic/iTZYrbDV9rKdSPkF7iBT T5Sw== X-Gm-Message-State: ALoCoQkkRcqPtm6lk7o7X6iwLy2adiDFl3kS8b9LBL+JeLONGECoAFe5O66aa29ZkVNYkZeFk4Ir X-Received: by 10.224.131.8 with SMTP id v8mr18920946qas.6.1413368302630; Wed, 15 Oct 2014 03:18:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 15 Oct 2014 03:18:01 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 15 Oct 2014 12:18:01 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f07UWRBcnYSdKI6rRlbqTHMYdnQ Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 10:18:27 -0000 2014-10-15 8:55 GMT+02:00 Christer Holmberg : > What I suggest has very little impact on ICE as defined today. It only ad= ds > some kind of indicator (ice-options attribute value?) whether the second > offer is needed or not. Simple :) And in case the SDP says that the "second offer" is required, then what? I mean, should the browser do samething (I mean natively)? or is it just up to the JS application? --=20 I=C3=B1aki Baz Castillo From nobody Wed Oct 15 03:26:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B511A1A9A for ; Wed, 15 Oct 2014 03:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohfrNBv8ewt0 for ; Wed, 15 Oct 2014 03:26:08 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6C61A1A93 for ; Wed, 15 Oct 2014 03:26:08 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so1072557pab.16 for ; Wed, 15 Oct 2014 03:26:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lE6s2rHc6kOx7m9s7Kfb3PbUigB5co0p4qq15Mt4GKA=; b=UCh1/2e33ubZSLzXPEsoTwG34vu871BoT7SbV4wS/LiYOFzdxAB9ohXfyW9fwmajAl e5sONDAmQ1Y+hZY1OvrxCYbuz4EwfIOfPbq9dMon7NhhTRzNcVwDoKcLE+PWqPxxLlJ7 wZt49s3qWkaKleeo59WyA3Yg9rA08TMyLCFgfma1x7CAMSmIo4Gtx3Ae0YYrGYKt57kl EkYJ+JTEMq9D0aBemBbfUFu9D0F4RcMIXmtQ0CjyNb8tck5bPNq+OH7z13cXQloQz/B7 wHYSuKk8SyIc7Ks6QvhVibrVmPf9oBv+qe1a8I62cKDCsbFVMkgwbkxpY8gMGDY0Ucfc 1BtA== X-Gm-Message-State: ALoCoQmypwKfdX0STWarirWeDonlmwVpPJ5BkhBA0ycxGBjl97Wyq3Y6W68MBQoEraH/JE8PsYyK X-Received: by 10.68.135.33 with SMTP id pp1mr11522732pbb.120.1413368768070; Wed, 15 Oct 2014 03:26:08 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by mx.google.com with ESMTPSA id mp5sm16654340pbc.33.2014.10.15.03.26.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 03:26:06 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id rd3so1064370pab.6 for ; Wed, 15 Oct 2014 03:26:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.121.65 with SMTP id li1mr1228838pab.148.1413368766368; Wed, 15 Oct 2014 03:26:06 -0700 (PDT) Received: by 10.66.170.172 with HTTP; Wed, 15 Oct 2014 03:26:06 -0700 (PDT) Received: by 10.66.170.172 with HTTP; Wed, 15 Oct 2014 03:26:06 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> Date: Wed, 15 Oct 2014 12:26:06 +0200 Message-ID: From: Emil Ivov To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8ffbac2341ad420505738f65 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fE7oFbDA6T6mpVUz5PXlU7JsJBQ Cc: "mmusic@ietf.org" , Roman Shpount , Christer Holmberg Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 10:26:10 -0000 --e89a8ffbac2341ad420505738f65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I really don't think browsers have anything to do with this. It is purely a matter of signalling. Nothing needs to be changed for webrtc one way or another. --sent from my mobile On 15 Oct 2014 12:18 PM, "I=C3=B1aki Baz Castillo" wrote: > 2014-10-15 8:55 GMT+02:00 Christer Holmberg < > christer.holmberg@ericsson.com>: > > What I suggest has very little impact on ICE as defined today. It only > adds > > some kind of indicator (ice-options attribute value?) whether the secon= d > > offer is needed or not. Simple :) > > And in case the SDP says that the "second offer" is required, then > what? I mean, should the browser do samething (I mean natively)? or is > it just up to the JS application? > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --e89a8ffbac2341ad420505738f65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I really don't think browsers have anything to do with t= his. It is purely a matter of signalling. Nothing needs to be changed for w= ebrtc one way or another.

--sent from my mobile

On 15 Oct 2014 12:18 PM, "I=C3=B1aki Baz Ca= stillo" <ibc@aliax.net> wro= te:
2014-10-15 8:55 = GMT+02:00 Christer Holmberg <christer.holmberg@ericsson.com>:
> What I suggest has very little impact on ICE as defined today. It only= adds
> some kind of indicator (ice-options attribute value?) whether the seco= nd
> offer is needed or not. Simple :)

And in case the SDP says that the "second offer" is required, the= n
what? I mean, should the browser do samething (I mean natively)? or is
it just up to the JS application?


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic
--e89a8ffbac2341ad420505738f65-- From nobody Wed Oct 15 03:27:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522BC1A1A93 for ; Wed, 15 Oct 2014 03:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wydONmnjbRUH for ; Wed, 15 Oct 2014 03:27:55 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEA31A000B for ; Wed, 15 Oct 2014 03:27:54 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-39-543e4c2945c3 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B4.42.24955.92C4E345; Wed, 15 Oct 2014 12:27:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 12:27:52 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP5+NicCZjzEhGnkuH0Ney21PC/JwwuWOQgAAX6ICAACN0sA== Date: Wed, 15 Oct 2014 10:27:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47DC8E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvja6mj12IQetkAYvp+2wspi5/zGIx 48JUZgdmj3MN79k9liz5yeRxa0pBAHMUl01Kak5mWWqRvl0CV0bn5IfsBUvYK/Z+P8bYwNjD 3sXIySEhYCKx9e0SRghbTOLCvfVsXYxcHEICRxkllm4/ywThLGGUWHK5l7mLkYODTcBCovuf NkiDiICNxL8LF8AGMQt4STTM3s4GUiIsoC4x5Z4CRImGxIJrXxghbCeJu/NuMIHYLAKqEpe3 fAYr5xXwldi93R4kLCRwm1Hi5x4LEJtTIFCiYetRVhCbEei076fWMEFsEpe49WQ+E8TJAhJL 9pxnhrBFJV4+/scKYStK7DzbDnYws4CmxPpd+hCtihJTuh+CHcwrIChxcuYTlgmMYrOQTJ2F 0DELSccsJB0LGFlWMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgTG0cEtv1V3MF5+43iIUYCD UYmHV+GqbYgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAs PvT/sNNTw4e3DytbOITtLbcRkUm6wKXQw5JgJ+37e/KM0xfV30gtuvTs8pxLMc5blPMsq/57 s2/ev0Il/47AC/sX4UdOTHnge+q0wf3NIj83Z0/u3Vd97mR6Xylb6dTYQ/27LA7rMq9jMZtW OS9C+LPe3LkFFovzn91bpL+rpbKjLDWhqcxZiaU4I9FQi7moOBEAsugDGoQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/E_x79mcfg3Y32_7skUWy-MSm3Zk Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 10:27:56 -0000 SGksDQoNCj4+IFdoYXQgSSBzdWdnZXN0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gSUNFIGFz IGRlZmluZWQgdG9kYXkuIEl0IG9ubHkgDQo+PiBhZGRzIHNvbWUga2luZCBvZiBpbmRpY2F0b3Ig KGljZS1vcHRpb25zIGF0dHJpYnV0ZSB2YWx1ZT8pIHdoZXRoZXIgdGhlIA0KPj4gc2Vjb25kIG9m ZmVyIGlzIG5lZWRlZCBvciBub3QuIFNpbXBsZSA6KQ0KPg0KPiBBbmQgaW4gY2FzZSB0aGUgU0RQ IHNheXMgdGhhdCB0aGUgInNlY29uZCBvZmZlciIgaXMgcmVxdWlyZWQsIHRoZW4gd2hhdD8gSSBt ZWFuLCBzaG91bGQgdGhlIGJyb3dzZXIgZG8gc2FtZXRoaW5nIChJIG1lYW4gbmF0aXZlbHkpPyBv ciBpcyBpdCBqdXN0IHVwIHRvIHRoZSBKUyBhcHBsaWNhdGlvbj8NCg0KUGVyc29uYWxseSBJIGRv bid0IGNhcmUgLSBhcyBsb25nIGFzIHRoZXJlIGlzIGFuIHVwZGF0ZWQgb2ZmZXIsIHdpdGggdGhl IHByb3BlciBpbmZvcm1hdGlvbiwgY29taW5nIG91dCBvbiB0aGUgd2lyZS4NCg0KT2J2aW91c2x5 LCBpZiBpdCdzIHVwIHRvIHRoZSBKUyBhcHBsaWNhdGlvbiwgaXQgbmVlZHMgdG8ga25vdyB3aGVu IHRoZSBjYW5kaWRhdGVzIGhhdmUgYmVlbiBzZWxlY3RlZCwgaW4gb3JkZXIgdG8gY3JlYXRlIGFu ZCBzZW5kIHRoZSBzZWNvbmQgb2ZmZXIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Wed Oct 15 03:29:48 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D3B1A1A98 for ; Wed, 15 Oct 2014 03:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZkslSVKymZX for ; Wed, 15 Oct 2014 03:29:45 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DDD1A1A9B for ; Wed, 15 Oct 2014 03:29:44 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-ba-543e4c967eca Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.88.21334.69C4E345; Wed, 15 Oct 2014 12:29:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 12:29:42 +0200 From: Christer Holmberg To: Emil Ivov , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP5+NicCZjzEhGnkuH0Ney21PC/JwwuWOQgAAX6ICAAAJCAIAAIjDA Date: Wed, 15 Oct 2014 10:29:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47DCCE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D47DCCEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvje40H7sQg0krtSzW7JzAYjF9n43F 1OWPWSxmXJjK7MDica7hPbvHkiU/mTz+vwn0uDWlIIAlissmJTUnsyy1SN8ugSuju/kpa8EW 64qfDe1sDYx3LLsYOTkkBEwkJn17zAxhi0lcuLeerYuRi0NI4CijRNf6B8wQzhJGic6GVyxd jBwcbAIWEt3/tEEaRASiJb5P/8AOYjMLeEk0zN7OBlIiLKAuMeWeAkSJhsSCa18YIWw3icb3 H9lAbBYBVYmFM+6B7eUV8JVoOHqTEWLVIiaJQz92M4EkOAUCJa5PPwRmMwId9/3UGiaIXeIS t57MZ4I4WkBiyZ7zUA+ISrx8/I8VwlaU2Hm2nRmiPl/i+fe7rBDLBCVOznzCMoFRdBaSUbOQ lM1CUjYL6B1mAU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DIvopRtDi1uDg33chYL7UoM7m4 OD9PLy+1ZBMjMB4Pbvmtu4Nx9WvHQ4wCHIxKPLwKV21DhFgTy4orcw8xSnOwKInzLjo3L1hI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo6bbiVvMjRw3JV//9jmvuuubw6kXyjbrv7I93PXt pt+fN1PtUrfHVFfdjVXf83Spb2vgRQb3FN/aU01HW43XMj84JL6gOUqYo9YpOMHxjU/ju7P8 bqvvWDv91Fm2fen8TH0OywO+Fpf4lv+/f6bnnJmGpkRDo1nlyx+f9Yw642p7A3t6D1Q8V2Ip zkg01GIuKk4EAKHjUXOoAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VTA7sgZchs0iHnQU5vzp_M7qCcc Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 10:29:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D47DCCEESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIHJlYWxseSBkb24ndCB0aGluayBicm93c2VycyBoYXZlIGFueXRoaW5nIHRvIGRv IHdpdGggdGhpcy4gSXQgaXMgcHVyZWx5IGEgbWF0dGVyIG9mIHNpZ25hbGxpbmcuIE5vdGhpbmcg bmVlZHMgdG8gYmUgY2hhbmdlZCBmb3Igd2VicnRjIG9uZSB3YXkgb3IgYW5vdGhlci4NCg0KQ29y cmVjdC4gSXQgaXMgYWJvdXQgd2hhdCBhbiBlbnRpdHkgaGFzIHRvIHNpZ25hbCBpbiBvcmRlciB0 byBiZSBJQ0UgY29tcGxpYW50LiBIT1cgaXTigJlzIGRvbmUgYW5kIG1hbmFnZWQgaW50ZXJuYWxs eSB3aXRoaW4gdGhlIGNsaWVudCBpcyBpcnJlbGV2YW50IOKAkyBhdCBsZWFzdCBhcyBmYXIgYXMg dGhlIElDRSBzdGFuZGFyZCBpcyBjb25jZXJuZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQpPbiAxNSBPY3QgMjAxNCAxMjoxOCBQTSwgIknDsWFraSBCYXogQ2FzdGlsbG8iIDxpYmNA YWxpYXgubmV0PG1haWx0bzppYmNAYWxpYXgubmV0Pj4gd3JvdGU6DQoyMDE0LTEwLTE1IDg6NTUg R01UKzAyOjAwIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+Og0KPiBXaGF0IEkgc3Vn Z2VzdCBoYXMgdmVyeSBsaXR0bGUgaW1wYWN0IG9uIElDRSBhcyBkZWZpbmVkIHRvZGF5LiBJdCBv bmx5IGFkZHMNCj4gc29tZSBraW5kIG9mIGluZGljYXRvciAoaWNlLW9wdGlvbnMgYXR0cmlidXRl IHZhbHVlPykgd2hldGhlciB0aGUgc2Vjb25kDQo+IG9mZmVyIGlzIG5lZWRlZCBvciBub3QuIFNp bXBsZSA6KQ0KDQpBbmQgaW4gY2FzZSB0aGUgU0RQIHNheXMgdGhhdCB0aGUgInNlY29uZCBvZmZl ciIgaXMgcmVxdWlyZWQsIHRoZW4NCndoYXQ/IEkgbWVhbiwgc2hvdWxkIHRoZSBicm93c2VyIGRv IHNhbWV0aGluZyAoSSBtZWFuIG5hdGl2ZWx5KT8gb3IgaXMNCml0IGp1c3QgdXAgdG8gdGhlIEpT IGFwcGxpY2F0aW9uPw0KDQoNCi0tDQpJw7Fha2kgQmF6IENhc3RpbGxvDQo8aWJjQGFsaWF4Lm5l dDxtYWlsdG86aWJjQGFsaWF4Lm5ldD4+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D47DCCEESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0 Ozwvc3Bhbj5JIHJlYWxseSBkb24ndCB0aGluayBicm93c2VycyBoYXZlIGFueXRoaW5nIHRvIGRv IHdpdGggdGhpcy4gSXQgaXMgcHVyZWx5IGEgbWF0dGVyIG9mIHNpZ25hbGxpbmcuIE5vdGhpbmcg bmVlZHMgdG8gYmUgY2hhbmdlZCBmb3Igd2VicnRjIG9uZSB3YXkgb3IgYW5vdGhlci4NCjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29ycmVjdC4gSXQgaXMgYWJvdXQg d2hhdCBhbiBlbnRpdHkgaGFzIHRvIHNpZ25hbCBpbiBvcmRlciB0byBiZSBJQ0UgY29tcGxpYW50 LiBIT1cgaXTigJlzIGRvbmUgYW5kIG1hbmFnZWQgaW50ZXJuYWxseSB3aXRoaW4gdGhlIGNsaWVu dCBpcyBpcnJlbGV2YW50IOKAkyBhdCBsZWFzdCBhcyBmYXIgYXMgdGhlDQogSUNFIHN0YW5kYXJk IGlzIGNvbmNlcm5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNSBPY3QgMjAxNCAxMjoxOCBQ TSwgJnF1b3Q7ScOxYWtpIEJheiBDYXN0aWxsbyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmli Y0BhbGlheC5uZXQiPmliY0BhbGlheC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTQtMTAtMTUgODo1NSBHTVQmIzQzOzAyOjAwIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7 IFdoYXQgSSBzdWdnZXN0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gSUNFIGFzIGRlZmluZWQg dG9kYXkuIEl0IG9ubHkgYWRkczxicj4NCiZndDsgc29tZSBraW5kIG9mIGluZGljYXRvciAoaWNl LW9wdGlvbnMgYXR0cmlidXRlIHZhbHVlPykgd2hldGhlciB0aGUgc2Vjb25kPGJyPg0KJmd0OyBv ZmZlciBpcyBuZWVkZWQgb3Igbm90LiBTaW1wbGUgOik8YnI+DQo8YnI+DQpBbmQgaW4gY2FzZSB0 aGUgU0RQIHNheXMgdGhhdCB0aGUgJnF1b3Q7c2Vjb25kIG9mZmVyJnF1b3Q7IGlzIHJlcXVpcmVk LCB0aGVuPGJyPg0Kd2hhdD8gSSBtZWFuLCBzaG91bGQgdGhlIGJyb3dzZXIgZG8gc2FtZXRoaW5n IChJIG1lYW4gbmF0aXZlbHkpPyBvciBpczxicj4NCml0IGp1c3QgdXAgdG8gdGhlIEpTIGFwcGxp Y2F0aW9uPzxicj4NCjxicj4NCjxicj4NCi0tPGJyPg0KScOxYWtpIEJheiBDYXN0aWxsbzxicj4N CiZsdDs8YSBocmVmPSJtYWlsdG86aWJjQGFsaWF4Lm5ldCI+aWJjQGFsaWF4Lm5ldDwvYT4mZ3Q7 PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0Bp ZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D47DCCEESESSMB209erics_-- From nobody Wed Oct 15 03:35:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862141A1AA4 for ; Wed, 15 Oct 2014 03:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKoJOQtoiJED for ; Wed, 15 Oct 2014 03:35:44 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43BD1A1A98 for ; Wed, 15 Oct 2014 03:35:43 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id dc16so601367qab.35 for ; Wed, 15 Oct 2014 03:35:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=icK7EK8axO6gt70pOTRCj6vGpmI+OT8V/fdVE0EbXzk=; b=V2lwur64Fkcgqq9UK49seuLVViLZkOKmjFWsqybrvbUqkABGDMUivQYEjfbDZ4paSf D/EcUFJDnGKKlCXthh52GEkyx+iRnbDPnXC/SElAl21OZiLYsorjSGXmN3tJdk64EiLj JR6oXBkdablliqVAXkXYIvH24/f40aANzAC2sot4J0d9i2ktygjMdaW4G+8hx/hvNePf 9om02I/nvjQiwU9EnaoLadLVSt30hN5015Zr6oaAJ7E+n4WWEXWL9XuOpq7NCRAiPgJK 6hHO66QiOy9niWLZTa12Ci5fQmTPFasrKE0fHOCWpm2hCcmuADiLrh1T+8rQ27Gu0jLP /O1w== X-Gm-Message-State: ALoCoQk10LGO9E3N2dnH7/aWfBoJ0DpvVV8lsxmFZQnaXa4z0SAX4/1mzjyqcHj7RtI0q0JR6z7r X-Received: by 10.140.19.205 with SMTP id 71mr17829222qgh.98.1413369342944; Wed, 15 Oct 2014 03:35:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 15 Oct 2014 03:35:22 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47DCCE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47DCCE@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 15 Oct 2014 12:35:22 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Rgp3_TYIRK9QZbBm3pyf7-9q4nw Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 10:35:44 -0000 2014-10-15 12:29 GMT+02:00 Christer Holmberg : >>I really don't think browsers have anything to do with this. It is purely= a >> matter of signalling. Nothing needs to be changed for webrtc one way or >> another. > > Correct. It is about what an entity has to signal in order to be ICE > compliant. HOW it=E2=80=99s done and managed internally within the client= is > irrelevant =E2=80=93 at least as far as the ICE standard is concerned. It would be easy if the iceconnectionstatechange() event would provide info about the paired/connected candidate pair. Unfortunately it is a vague event which provides nothing but just "some of the transports in your PeerConnection has connected, but I won't tell you which one". --=20 I=C3=B1aki Baz Castillo From nobody Wed Oct 15 04:29:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF801A1AF6 for ; Wed, 15 Oct 2014 04:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GblkMs-rjfDj for ; Wed, 15 Oct 2014 04:29:33 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1831A1AFB for ; Wed, 15 Oct 2014 04:29:32 -0700 (PDT) Received: from ppp118-209-159-157.lns20.mel8.internode.on.net ([118.209.159.157]:65049 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XeMkI-0002aq-Oi for mmusic@ietf.org; Wed, 15 Oct 2014 22:27:58 +1100 Message-ID: <543E5A96.4060505@nteczone.com> Date: Wed, 15 Oct 2014 22:29:26 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <20141015095756.7536.80011.idtracker@ietfa.amsl.com> <0C3D8AA4-DFC0-49C4-87B5-E47BF06B2DB8@cisco.com> In-Reply-To: <0C3D8AA4-DFC0-49C4-87B5-E47BF06B2DB8@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/HMLBPz4_4CfTBa7lAD4b4_GRP3U Subject: Re: [MMUSIC] New draft discussion 4566bis IANA issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 11:29:39 -0000 Hello Ali, Thanks for doing the draft. I think having the "usable nettype values" is an improvement. With regards to the list of address types, the IANA registry is still missing network "TN" and address type "RFC2543" from RFC2848. It should be added for completeness. Regards, Christian On 15/10/2014 9:08 PM, Ali C. Begen (abegen) wrote: > Hi everyone > > 4566bis draft had major changes in the last revision. It is pending WG's review (See Paul K.' email dated Sept. 23rd). > > 4566bis had other open issues as listed in the tracker. > http://trac.tools.ietf.org/wg/mmusic/trac/report/1 > > For all the IANA related matters, I just submitted a new draft addressing tickets 15, 16, 17, 18 and 19. > https://datatracker.ietf.org/doc/draft-begen-mmusic-rfc4566bis-iana-updates/ > > Please review this draft as the chairs will likely take an action on it in the next meeting. It addresses all the issues we have identified so far in the IANA registries for the SDP. Once we agree on these changes, we can either publish that draft right away (and keep 4566bis open for a bit longer) or move all the IANA changes to the 4566bis document and everything gets published together. That is a rather minor issues. Most importantly, we need reviews and approvals for these IANA changes. > > There is another draft that will change the IANA registry structure for SDP parameters and attributes (draft-ietf-mmusic-sdp-mux-attributes). To minimize the load on the IANA folks, we need to decide on these changes soon and schedule things carefully. > > Any questions/comments, post to the list. > > -acbegen > > > Begin forwarded message: > >> From: >> Subject: New Version Notification for draft-begen-mmusic-rfc4566bis-iana-updates-00.txt >> Date: October 15, 2014 at 11:57:56 AM GMT+2 >> To: Ali Begen , "Ali C. Begen" >> >> >> A new version of I-D, draft-begen-mmusic-rfc4566bis-iana-updates-00.txt >> has been successfully submitted by Ali Begen and posted to the >> IETF repository. >> >> Name: draft-begen-mmusic-rfc4566bis-iana-updates >> Revision: 00 >> Title: IANA Registry Updates for RFC 4566bis >> Document date: 2014-10-15 >> Group: Individual Submission >> Pages: 5 >> URL: http://www.ietf.org/internet-drafts/draft-begen-mmusic-rfc4566bis-iana-updates-00.txt >> Status: https://datatracker.ietf.org/doc/draft-begen-mmusic-rfc4566bis-iana-updates/ >> Htmlized: http://tools.ietf.org/html/draft-begen-mmusic-rfc4566bis-iana-updates-00 >> >> >> Abstract: >> The Session Description Protocol (SDP) specification is currently >> being revised. There are a number of issues that have been >> identified in the IANA registries related to the SDP protocol (These >> are tracked in the issue tracker). This document has the goal of >> addressing these issues by making the necessary changes in the IANA >> registries and registration procedures. >> >> The changes and updates listed in this draft are submitted in this >> individual draft rather than the 4566bis draft because (i) the >> 4566bis draft has seen quite a number of changes recently, which >> require a detailed review and further revisions would make the review >> process difficult, and (ii) the changes and updates listed in this >> draft are all IANA related matters. If this draft gets published >> separately, it will update RFC 4566 or the RFC resulting from the >> 4566bis draft. An alternative option is to include the whole text in >> the 4566bis draft once the changes and updates are agreed. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Oct 15 05:11:15 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14F1A1BE4 for ; Wed, 15 Oct 2014 05:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrD80JU0j4tI for ; Wed, 15 Oct 2014 05:11:06 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348221A1BB0 for ; Wed, 15 Oct 2014 05:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4551; q=dns/txt; s=iport; t=1413375064; x=1414584664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mn3L6IugPj+TAHWLMXjfMaSFPEY0s99SrJeiaGHVgho=; b=Zs/8UO0PkWoM74BJ8ajfdOQfpgnWq7A8+I+8vS+mStVYzfi1zhjYU3MC YsWLwTRBlv5qMhfKFip+OtlQsKDp9APiNHMA3jDvz5CsPWPDoxbNekWzH sZ0JTY0pfUFPiInU2D7PliuKL3Ljmmc39H2so2A9BQuVSHcdzSZWZ242v E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAPJjPlStJA2K/2dsb2JhbABbgmsjU1gEy3MMhndUAoESFgF9hAIBAQEDAQEBATc0CwULAgEIEQMBAgEeECcLHQgCBA4FCYgtCAEMyBoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj2wRAQsSCCsHBoMngR4FkX+ERIcRgTA8gwqKDIcYg3dsAYEOOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,723,1406592000"; d="scan'208";a="87148662" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 15 Oct 2014 12:10:53 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9FCArIk027768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 12:10:53 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 07:10:53 -0500 From: "Ali C. Begen (abegen)" To: Christian Groves Thread-Topic: [MMUSIC] New draft discussion 4566bis IANA issues Thread-Index: AQHP6F/3k+bICs0JIUC2prcPwKIaUZwxWZ4AgAALk4A= Date: Wed, 15 Oct 2014 12:10:52 +0000 Message-ID: <1CFC8A04-D7AC-4C6B-B822-F36087544182@cisco.com> References: <20141015095756.7536.80011.idtracker@ietfa.amsl.com> <0C3D8AA4-DFC0-49C4-87B5-E47BF06B2DB8@cisco.com> <543E5A96.4060505@nteczone.com> In-Reply-To: <543E5A96.4060505@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.29.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <72F418D967EF6C4289796ECB1A997BA1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/E7pP2FLCNiKgL8uuoAAG4j2NnEA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] New draft discussion 4566bis IANA issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 12:11:13 -0000 On Oct 15, 2014, at 1:29 PM, Christian Groves wrote: > Hello Ali, >=20 > Thanks for doing the draft. I think having the "usable nettype values" is= an improvement. Thanks, >=20 > With regards to the list of address types, the IANA registry is still mis= sing network "TN" and address type "RFC2543" from RFC2848. It should be add= ed for completeness. Do you remember why it was omitted in the first place?=20 >=20 > Regards, Christian >=20 > On 15/10/2014 9:08 PM, Ali C. Begen (abegen) wrote: >> Hi everyone >>=20 >> 4566bis draft had major changes in the last revision. It is pending WG's= review (See Paul K.' email dated Sept. 23rd). >>=20 >> 4566bis had other open issues as listed in the tracker. >> http://trac.tools.ietf.org/wg/mmusic/trac/report/1 >>=20 >> For all the IANA related matters, I just submitted a new draft addressin= g tickets 15, 16, 17, 18 and 19. >> https://datatracker.ietf.org/doc/draft-begen-mmusic-rfc4566bis-iana-upda= tes/ >>=20 >> Please review this draft as the chairs will likely take an action on it = in the next meeting. It addresses all the issues we have identified so far = in the IANA registries for the SDP. Once we agree on these changes, we can = either publish that draft right away (and keep 4566bis open for a bit longe= r) or move all the IANA changes to the 4566bis document and everything gets= published together. That is a rather minor issues. Most importantly, we ne= ed reviews and approvals for these IANA changes. >>=20 >> There is another draft that will change the IANA registry structure for = SDP parameters and attributes (draft-ietf-mmusic-sdp-mux-attributes). To mi= nimize the load on the IANA folks, we need to decide on these changes soon = and schedule things carefully. >>=20 >> Any questions/comments, post to the list. >>=20 >> -acbegen >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: >>> Subject: New Version Notification for draft-begen-mmusic-rfc4566bis-ian= a-updates-00.txt >>> Date: October 15, 2014 at 11:57:56 AM GMT+2 >>> To: Ali Begen , "Ali C. Begen" >>>=20 >>>=20 >>> A new version of I-D, draft-begen-mmusic-rfc4566bis-iana-updates-00.txt >>> has been successfully submitted by Ali Begen and posted to the >>> IETF repository. >>>=20 >>> Name: draft-begen-mmusic-rfc4566bis-iana-updates >>> Revision: 00 >>> Title: IANA Registry Updates for RFC 4566bis >>> Document date: 2014-10-15 >>> Group: Individual Submission >>> Pages: 5 >>> URL: http://www.ietf.org/internet-drafts/draft-begen-mmusic-= rfc4566bis-iana-updates-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-begen-mmusic-rfc= 4566bis-iana-updates/ >>> Htmlized: http://tools.ietf.org/html/draft-begen-mmusic-rfc4566bi= s-iana-updates-00 >>>=20 >>>=20 >>> Abstract: >>> The Session Description Protocol (SDP) specification is currently >>> being revised. There are a number of issues that have been >>> identified in the IANA registries related to the SDP protocol (These >>> are tracked in the issue tracker). This document has the goal of >>> addressing these issues by making the necessary changes in the IANA >>> registries and registration procedures. >>>=20 >>> The changes and updates listed in this draft are submitted in this >>> individual draft rather than the 4566bis draft because (i) the >>> 4566bis draft has seen quite a number of changes recently, which >>> require a detailed review and further revisions would make the review >>> process difficult, and (ii) the changes and updates listed in this >>> draft are all IANA related matters. If this draft gets published >>> separately, it will update RFC 4566 or the RFC resulting from the >>> 4566bis draft. An alternative option is to include the whole text in >>> the 4566bis draft once the changes and updates are agreed. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Oct 15 06:40:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9401A6F8C for ; Wed, 15 Oct 2014 06:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUqVbl2zsVFT for ; Wed, 15 Oct 2014 06:40:28 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FAB31A1AC3 for ; Wed, 15 Oct 2014 06:40:27 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so13016134wid.0 for ; Wed, 15 Oct 2014 06:40:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=nTl1uODbm7FKrfzXSVranmXOPFa6DXZr1JSGd05a79o=; b=fbcShTi+W0y8A/JB1yzY1yPtjHAnXgzo9hFTlW5yNKHOtHlp5ylbB5me4m5UcfMBVB ZJBrytQbbjCzvh5XgBxXn5k6HjaghMNC12ifoEO0CIX+BMR8JqrMQmbGokl4BQ30ZmTi Kz66KsasgsFOkzC4aK2diwSzBMqwRQgYUTjBE5wO+hA+3Bjrvi9tjM8gaakfYVwdn/Ik oWwpgYWRUeMD4aFvhx6D4LYgZ7+PqtfRIBhabstbErkj0cFJz0cFtcvtEZVrFSbi5Quo s3njCxXLGb+sv2LCj301ESxRm6n670Acry/iqMrnn/Hzowv96AXKYUVFvTYbtMi7tGBj MXug== X-Gm-Message-State: ALoCoQn6doTuxtexwnxsZ1LEwWrN/rNt3jwoN+ASiwxS9Atc20IAwMN06OAqP5pkGj+Gx7SwMv2Z X-Received: by 10.194.100.98 with SMTP id ex2mr12158934wjb.48.1413380426316; Wed, 15 Oct 2014 06:40:26 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx.google.com with ESMTPSA id t10sm6187557wja.43.2014.10.15.06.40.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 06:40:25 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id d1so1964702wiv.0 for ; Wed, 15 Oct 2014 06:40:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.20.19 with SMTP id j19mr12169847wie.43.1413380424810; Wed, 15 Oct 2014 06:40:24 -0700 (PDT) Received: by 10.216.176.65 with HTTP; Wed, 15 Oct 2014 06:40:24 -0700 (PDT) Date: Wed, 15 Oct 2014 09:40:24 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec53d55eb274aab0505764631 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5meXP-jQmJzJtp7d6SdpDaIqTno Cc: "mmusic@ietf.org" Subject: [MMUSIC] ICE and empty re-INVITE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 13:40:30 -0000 --bcaec53d55eb274aab0505764631 Content-Type: text/plain; charset=UTF-8 I guess, then my question is, should this group also address the ICE-restart on empty re-INVITE as a separate item? It is extremely inconvenient that the need for ICE-restart vs old ICE pair reuse cannot be signaled when offer is requested. _____________ Roman Shpount On Wed, Oct 15, 2014 at 2:55 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > To base solutions on the sending of empty re-INVITEs is in my opinion not > a very good idea. Also, it makes things tricky for intermediaries that need > the information. In order for them to trigger re-INVITEs they have to be > B2BUA, and that will then cause other problems. > > > > What I suggest has very little impact on ICE as defined today. It only > adds some kind of indicator (ice-options attribute value?) whether the > second offer is needed or not. Simple :) > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Roman > Shpount > *Sent:* 14 October 2014 22:17 > *To:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] ICE updated offer > > > > Would the better solution for this entire problem be a SIP option that > allows to suppress ICE restart on new empty re-invite? If both sides > support this option (via the Supported header), then new offer is not sent > in the end of the ICE process. If remote party needs it, then it can do an > empty SIP re-INVITE with this flag set. If intermediary does not support > this, they can remove the option from the Supported header in any direction > and this will cause a new offer-answer transaction per old RFC. > > _____________ > Roman Shpount > --bcaec53d55eb274aab0505764631 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess, then my question is, should this group also addre= ss the ICE-restart on empty re-INVITE as a separate item? It is extremely i= nconvenient that the need for ICE-restart vs old ICE pair reuse cannot be s= ignaled when offer is requested.

_____________
Roman Shpount

On Wed, Oct 15, 2014 at 2:55 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,<= /p>

=C2=A0

To base solutions on the = sending of empty re-INVITEs is in my opinion not a very good idea. Also, it= makes things tricky for intermediaries that need the information. In order for them to trigger re-INVITEs they ha= ve to be B2BUA, and that will then cause other problems.

=C2=A0

What I suggest has very l= ittle impact on ICE as defined today. It only adds some kind of indicator (= ice-options attribute value?) whether the second offer is needed or not. Simple :)<= /p>

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 14 October 2014 22:17
To: mmusic@ietf= .org
Subject: Re: [MMUSIC] ICE updated offer

=C2=A0

Would the better solution for this entire problem be= a SIP option that allows to suppress ICE restart on new empty re-invite? I= f both sides support this option (via the Supported header), then new offer= is not sent in the end of the ICE process. If remote party needs it, then it can do an empty SIP re-INVITE w= ith this flag set. If intermediary does not support this, they can remove t= he option from the Supported header in any direction and this will cause a = new offer-answer transaction per old RFC.

_____________
Roman Shpount


--bcaec53d55eb274aab0505764631-- From nobody Wed Oct 15 06:48:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1C71A6FDF for ; Wed, 15 Oct 2014 06:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaRTKFrhRZTj for ; Wed, 15 Oct 2014 06:48:34 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 29D0C1A6FA7 for ; Wed, 15 Oct 2014 06:48:34 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id BDF3623F05DE; Wed, 15 Oct 2014 15:48:32 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 15:48:32 +0200 From: "Stach, Thomas" To: Emil Ivov , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP6GJtuF9H8nwjukqj+Vm4R8Q5spwxLGYQ Date: Wed, 15 Oct 2014 13:48:32 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PMl88pfqRBVXeATRhNqA1BCXNeg Cc: "mmusic@ietf.org" , Roman Shpount , Christer Holmberg Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 13:48:35 -0000 DQoNCg0KSSByZWFsbHkgZG9uJ3QgdGhpbmsgYnJvd3NlcnMgaGF2ZSBhbnl0aGluZyB0byBkbyB3 aXRoIHRoaXMuIEl0IGlzIHB1cmVseSBhIG1hdHRlciBvZiBzaWduYWxsaW5nLiBOb3RoaW5nIG5l ZWRzIHRvIGJlIGNoYW5nZWQgZm9yIHdlYnJ0YyBvbmUgd2F5IG9yIGFub3RoZXIuIA0KW1RTXSBJ IGFncmVlLiBJQ0UgdXBkYXRlZCBvZmZlciB3YXMgaW50cm9kdWNlZCB0byBhY2NvbW1vZGF0ZSBj ZXJ0YWluIFNJUCBtaWRkbGVib3hlcy4gSXRzIHJlbGV2YW5jZSBvdXRzaWRlIG9mIFNJUCBpcyBh dCBsZWFzdCBkZWJhdGFibGUuDQoNCi0tc2VudCBmcm9tIG15IG1vYmlsZQ0KT24gMTUgT2N0IDIw MTQgMTI6MTggUE0sICJJw7Fha2kgQmF6IENhc3RpbGxvIiA8aWJjQGFsaWF4Lm5ldD4gd3JvdGU6 DQoyMDE0LTEwLTE1IDg6NTUgR01UKzAyOjAwIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+Og0KPiBXaGF0IEkgc3VnZ2VzdCBoYXMgdmVyeSBsaXR0bGUg aW1wYWN0IG9uIElDRSBhcyBkZWZpbmVkIHRvZGF5LiBJdCBvbmx5IGFkZHMNCj4gc29tZSBraW5k IG9mIGluZGljYXRvciAoaWNlLW9wdGlvbnMgYXR0cmlidXRlIHZhbHVlPykgd2hldGhlciB0aGUg c2Vjb25kDQo+IG9mZmVyIGlzIG5lZWRlZCBvciBub3QuIFNpbXBsZSA6KQ0KDQpBbmQgaW4gY2Fz ZSB0aGUgU0RQIHNheXMgdGhhdCB0aGUgInNlY29uZCBvZmZlciIgaXMgcmVxdWlyZWQsIHRoZW4N CndoYXQ/IEkgbWVhbiwgc2hvdWxkIHRoZSBicm93c2VyIGRvIHNhbWV0aGluZyAoSSBtZWFuIG5h dGl2ZWx5KT8gb3IgaXMNCml0IGp1c3QgdXAgdG8gdGhlIEpTIGFwcGxpY2F0aW9uPw0KDQoNCi0t DQpJw7Fha2kgQmF6IENhc3RpbGxvDQo8aWJjQGFsaWF4Lm5ldD4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1t dXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCg== From nobody Wed Oct 15 09:13:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C671A88F8 for ; Wed, 15 Oct 2014 09:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1mvlf0hVRkg for ; Wed, 15 Oct 2014 09:13:14 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.16]) by ietfa.amsl.com (Postfix) with ESMTP id C73AC1A88E7 for ; Wed, 15 Oct 2014 09:12:04 -0700 (PDT) Received: from userPC (unknown [122.172.198.200]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 4DCF7E2800A; Wed, 15 Oct 2014 16:11:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1413389523; bh=LZCuQ4dj7tXaoSGdF0CtZ9+hdQeFcjiJD2vTcpSVklY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=K3Wc28jgg9unnHzdeQmBv9j56ldCTpcGMdmCjuGmF5MEydDrDYVF/cs/C+k8Z5juw ohGuzZF8saFP9L0rrACAhUSpkvZSb9cFPiChKj1t0Ppm5DzCq3xjhxTq6h6iyiXJ62 KOeCK4k/nWLpAl9sDSeMmAzW1WhXIFVLZDBpHtl4= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <010501cfe805$72268000$56738000$@co.in> In-Reply-To: Date: Wed, 15 Oct 2014 21:41:48 +0530 Message-ID: <003f01cfe892$be23f310$3a6bd930$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/oYRpvlVdqCCkFStCSwNRohM3AiAAMES8Q Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.543E9CD3.00C5, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.134 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mZEym3ri2Xt-COoP5raa2TYXk8w Cc: =?UTF-8?Q?'Ari_Ker=C3=A4nen'?= , 'mmusic' , 'Christer Holmberg' Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 16:13:16 -0000 > If the SDP handling "entity" is not aware of the media/STUN = stuff then > you have a big problem. IOW, the second offer/answer is required to solve the problem.=20 Please note that single offer/answer may be suitable in couple of = deployments but it is not generic enough to accept as a single solution. > -----Original Message----- > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Wednesday, October 15, 2014 3:46 PM > To: Parthasarathi R > Cc: Christer Holmberg; Ari Ker=C3=A4nen; mmusic > Subject: Re: [MMUSIC] ICE updated offer >=20 > 2014-10-15 1:20 GMT+02:00 Parthasarathi R = : > > STUN only based signaling mechanism > > in the middle of the session leads to the issue in those = architecture > as SDP > > handling entity will not aware of the conclusion. >=20 > If the SDP handling "entity" is not aware of the media/STUN stuff then > you have a big problem. >=20 >=20 > > Please note that SDP handling (signaling) entity and media handling > entity > > as a different device in the answerer side is not defined in IETF > RTCWeb so > > far. >=20 > Of course. And what? > Both "entities" are supposed to be the same, or to inter-communicate > somehow one to each other. >=20 >=20 > -- > I=C3=B1aki Baz Castillo > From nobody Wed Oct 15 09:36:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5601A898F for ; Wed, 15 Oct 2014 09:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIThb1UvBi46 for ; Wed, 15 Oct 2014 09:36:53 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.15]) by ietfa.amsl.com (Postfix) with ESMTP id 998831A1AB6 for ; Wed, 15 Oct 2014 09:36:53 -0700 (PDT) Received: from userPC (unknown [122.172.198.200]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id DFC951908C91; Wed, 15 Oct 2014 16:36:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1413391013; bh=Q8+EcJIlYu4XRFzmVvS5aqa8kXvFJWdgGDWirsmsnlU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZR5il1IsCHxEIuNPAujBiRK0Ye80IrNx/nqXpPwiwbisogmgmhPDxXujopy9a2oGn qhv/eWHr1/Y+RewhKPXEFN4lccU7onlLHhUARyN6orXs6WWbV7h7csmrsq87kEaqS4 i7UeFZfJcHI+LP2bGzYF67Jh2pfDzTCz0ADMbB6w= From: "Parthasarathi R" To: "'Stach, Thomas'" , "'Emil Ivov'" , =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> In-Reply-To: Date: Wed, 15 Oct 2014 22:06:37 +0530 Message-ID: <004001cfe896$36205220$a260f660$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP6GJtuF9H8nwjukqj+Vm4R8Q5spwxLGYQgAAojIA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.543EA2A5.00CF, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mD8Ho9yPCnT2CXjnW7fNcTS55io Cc: mmusic@ietf.org, 'Roman Shpount' , 'Christer Holmberg' Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 16:36:55 -0000 Hi Thomas, I'm not seeing that the second offer is relevant only to SIP. Even in = case WebRTC entity with (proprietary) signaling & media in the separate = device, WebRTC signaling entity will not aware of the actual media IP, = port & transport. Thanks Partha > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Stach, > Thomas > Sent: Wednesday, October 15, 2014 7:19 PM > To: Emil Ivov; I=C3=B1aki Baz Castillo > Cc: mmusic@ietf.org; Roman Shpount; Christer Holmberg > Subject: Re: [MMUSIC] ICE updated offer >=20 >=20 >=20 >=20 > I really don't think browsers have anything to do with this. It is > purely a matter of signalling. Nothing needs to be changed for webrtc > one way or another. > [TS] I agree. ICE updated offer was introduced to accommodate certain > SIP middleboxes. Its relevance outside of SIP is at least debatable. >=20 > --sent from my mobile > On 15 Oct 2014 12:18 PM, "I=C3=B1aki Baz Castillo" = wrote: > 2014-10-15 8:55 GMT+02:00 Christer Holmberg > : > > What I suggest has very little impact on ICE as defined today. It > only adds > > some kind of indicator (ice-options attribute value?) whether the > second > > offer is needed or not. Simple :) >=20 > And in case the SDP says that the "second offer" is required, then > what? I mean, should the browser do samething (I mean natively)? or is > it just up to the JS application? >=20 >=20 > -- > I=C3=B1aki Baz Castillo > >=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 From nobody Wed Oct 15 09:37:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2776F1A1AB3 for ; Wed, 15 Oct 2014 09:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltQVmyQjWRxW for ; Wed, 15 Oct 2014 09:37:37 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64131A1AB0 for ; Wed, 15 Oct 2014 09:37:36 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j7so1113284qaq.15 for ; Wed, 15 Oct 2014 09:37:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Rnux5uSAZ4VpvcOxFbPHpYh13hDsbQuTtgREif028Wk=; b=lo74N8q/yPy4Yn1/T0o0QomYVGX/ZW+70WnRRPuEADfxw3IP0CLgG0XKVwREzICBCa 4ckPrm2cJAmfLiM38Ou91jthAdno+V56tqFIuK3eIbbQ/wK4/nxKgDkvh8mrdAiFYz2/ 31pv1PKg2/ArqvzrAXgwpMz2xhwx0ntJuv/obClAFQRwG0biQkyaKWXBx9S26y1RH2vq FXyTfc1x/VezSp1nWzMfXE/2uQmWtuuGou9b7dMxp8gI8qDQ8HjOOyKRxQlAdONzupyO Q7EoyKSvFZrGFTnB/NPQUzpNtPW1nTcFjAsTarNTweXt0j4tkhvgTfJvKPOA/NKc1EK/ gW9w== X-Gm-Message-State: ALoCoQknMnYDwAOfQDBIrvbcLktH5xkaUaBRHdv0e4GrHgG+9qkWm1pWhAL07GYsBK9ceUPr+THA X-Received: by 10.229.247.200 with SMTP id md8mr22326318qcb.7.1413391055480; Wed, 15 Oct 2014 09:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 15 Oct 2014 09:37:15 -0700 (PDT) In-Reply-To: <003f01cfe892$be23f310$3a6bd930$@co.in> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <010501cfe805$72268000$56738000$@co.in> <003f01cfe892$be23f310$3a6bd930$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 15 Oct 2014 18:37:15 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/r0E8ISakmBz6FniTmH7Y1pVtD00 Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , mmusic , Christer Holmberg Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 16:37:38 -0000 2014-10-15 18:11 GMT+02:00 Parthasarathi R : > Please note that single offer/answer may be suitable in couple of deploym= ents but it is not generic enough to accept as a single solution. Nothing prevents you from performing a second and a third O/A round trip. --=20 I=C3=B1aki Baz Castillo From nobody Wed Oct 15 09:39:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890FF1A8791 for ; Wed, 15 Oct 2014 09:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yoMoxKmnchS for ; Wed, 15 Oct 2014 09:39:41 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C271A899B for ; Wed, 15 Oct 2014 09:39:36 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id h11so10435352wiw.7 for ; Wed, 15 Oct 2014 09:39:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zqv9a3U2JKbF0BtRR8X3kZrW9ziO+HbbIEp9umVebIQ=; b=dorJuN515uSkv8h1IPkNQbWhdF+HHjMP1ut727dTTdKTh8SWiHp2HhVT2akc61zNoM d+fT4ZTYJbdIRxDp10xB5BBwUMqu/vXRO9m/lt2XprKBaU/2PHhu2V45c3zrqYEcNEOn MGE0+Lck7PWrIFRKX8c3/DB6dmlrcqJcRG9H8MrdSVxX8F+20JlfMlsWoEzFD1LcYgRO pXgApDb2gOwNMGBHIgaVStT/biGFDa/gBx4kT1IfmN64lXW0u+8th4IBAvtkWslIU+sz BJHWtUwLWAPy1mdjqIGHvR476J6Kq6w3n/jptkjMh12CK7YHiFSWuG9xw9y+PG+IoHAr NkkQ== X-Gm-Message-State: ALoCoQloNpBtXGJpCgowKbWGH3tU5o+SjEYtwCWOiGAg1hGLctEK6cQbjpnEZKPgqVl5SlGwb5VN X-Received: by 10.194.205.103 with SMTP id lf7mr3545507wjc.134.1413391175071; Wed, 15 Oct 2014 09:39:35 -0700 (PDT) Received: from porcinet.u-strasbg.fr (porcinet.u-strasbg.fr. [130.79.91.167]) by mx.google.com with ESMTPSA id b6sm19942400wiy.22.2014.10.15.09.39.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 09:39:33 -0700 (PDT) Message-ID: <543EA344.5030104@jitsi.org> Date: Wed, 15 Oct 2014 18:39:32 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Parthasarathi R , "'Stach, Thomas'" , =?UTF-8?B?J0nDsWFraSBCYXogQ2FzdGlsbG8n?= References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> In-Reply-To: <004001cfe896$36205220$a260f660$@co.in> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5CNdrzJjYGe26vnYzTw1XOeBlAY Cc: mmusic@ietf.org, 'Roman Shpount' , 'Christer Holmberg' Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 16:39:43 -0000 On 15.10.14, 18:36, Parthasarathi R wrote: > Hi Thomas, > > I'm not seeing that the second offer is relevant only to SIP. Even in case WebRTC entity with (proprietary) signaling & media in the separate device, WebRTC signaling entity will not aware of the actual media IP, port & transport. That's not an ICE problem though. It's a WebRTC API problem though and trying to solve it by triggering new SDPs would be quite daft really. Emil > Thanks > Partha > >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Stach, >> Thomas >> Sent: Wednesday, October 15, 2014 7:19 PM >> To: Emil Ivov; Iñaki Baz Castillo >> Cc: mmusic@ietf.org; Roman Shpount; Christer Holmberg >> Subject: Re: [MMUSIC] ICE updated offer >> >> >> >> >> I really don't think browsers have anything to do with this. It is >> purely a matter of signalling. Nothing needs to be changed for webrtc >> one way or another. >> [TS] I agree. ICE updated offer was introduced to accommodate certain >> SIP middleboxes. Its relevance outside of SIP is at least debatable. >> >> --sent from my mobile >> On 15 Oct 2014 12:18 PM, "Iñaki Baz Castillo" wrote: >> 2014-10-15 8:55 GMT+02:00 Christer Holmberg >> : >>> What I suggest has very little impact on ICE as defined today. It >> only adds >>> some kind of indicator (ice-options attribute value?) whether the >> second >>> offer is needed or not. Simple :) >> >> And in case the SDP says that the "second offer" is required, then >> what? I mean, should the browser do samething (I mean natively)? or is >> it just up to the JS application? >> >> >> -- >> Iñaki Baz Castillo >> >> >> _______________________________________________ >> 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 > > -- https://jitsi.org From nobody Wed Oct 15 09:39:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7599B1A8993 for ; Wed, 15 Oct 2014 09:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsU2sk0mlg6q for ; Wed, 15 Oct 2014 09:39:47 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0581A8970 for ; Wed, 15 Oct 2014 09:39:47 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id x3so1297094qcv.11 for ; Wed, 15 Oct 2014 09:39:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=H0RQAXLEiEL2sjjWYdp5rkWcuNmzy2ts04EF8HcT6UM=; b=mX6JsRKm8IuRDacwtRK6hF5vQQviNpu2CVX1G+mRdgeCKifwdya+L79gW8eI2ak+f/ Ce/7++iBWp5N8du8g+StK4nKOeI5NfV96vcQ3XfNDBcZxeA65lqestJLCAlV6zGse+r0 znw7IKY/4VGVmaF8Q0xXJz4j6yXbG9jXpAbFFbDgeRAsNf5qWGj7oo85V6F6GHDUlVCj i9I6XnCMXz21JnSj6L/0Ji0jm+4E6EOKjN+Mff6hflYmW1G6EvKc/0x1mrVCose6onww Rbg9XLHhoVe/W28Lm5/IfQYp4sXPCPI4bOA6hU8hIW/5o8bpJ038JqhMBlqEMq3NZ040 SoCA== X-Gm-Message-State: ALoCoQmbz7rXlDMWL2tQijshULYsYtgk0ZhYeqv3QRZWlkAvR2uW38FOkp34mKUGBp10eRnBwQb4 X-Received: by 10.140.19.205 with SMTP id 71mr21056332qgh.98.1413391186213; Wed, 15 Oct 2014 09:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Wed, 15 Oct 2014 09:39:25 -0700 (PDT) In-Reply-To: <004001cfe896$36205220$a260f660$@co.in> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 15 Oct 2014 18:39:25 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UBNn0B1WKiIU8V2Eui2MOZITzBk Cc: Christer Holmberg , "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 16:39:48 -0000 2014-10-15 18:36 GMT+02:00 Parthasarathi R : > in case WebRTC entity with (proprietary) signaling & media in the separat= e device, WebRTC signaling entity will not aware of the actual media IP, po= rt & transport. If somebody builds a WebRTC entity/endpoint/whatever in which the signaling "entity" and the media "entity" are not inter-communicated... then indeed that is a big problem. A big *design* problem. Just fix it. --=20 I=C3=B1aki Baz Castillo From nobody Wed Oct 15 12:02:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DC71A90AE for ; Wed, 15 Oct 2014 12:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOcCJbVDJ4c8 for ; Wed, 15 Oct 2014 12:02:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D392B1A90C8 for ; Wed, 15 Oct 2014 12:02:06 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-1e-543ec4ac5992 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.9D.04081.CA4CE345; Wed, 15 Oct 2014 21:02:04 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.174.1; Wed, 15 Oct 2014 21:02:04 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1B73F1102AA; Wed, 15 Oct 2014 22:02:04 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A1DA4E941; Wed, 15 Oct 2014 22:04:10 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E68B64E695; Wed, 15 Oct 2014 22:04:09 +0300 (EEST) Message-ID: <543EC4AB.7090809@ericsson.com> Date: Wed, 15 Oct 2014 22:02:03 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvje6aI3YhBi2rVSzeX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXGxoZG1YANHxc4PGQ2M59i6GDk5JARMJOZe vQ5li0lcuLceyObiEBI4yiixZO5cdghnA6PEiw1/WSCcvYwSm5ffhHLWMUqsP/WUEaRfSGAF kHPaqYuRg4NXQFvi2kJ2kDCLgKrEyV/3wGw2AXuJmxOug9miAskSa7ZOArN5BQQlTs58wgJi iwjISOzdtJkZxGYGGjP7ziwmEFsYyH799zArRNxW4sKc6ywQtrzE9rdzmCFeUJO4em4TM8Q5 qhJX/71inMAoPAvJillI2mchaV/AyLyKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzC8D275 bbCD8eVzx0OMAhyMSjy8CldtQ4RYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA2PRu3ezJ+9gOLIkKWqeyxupG88dkiY8eSYkmzSZc1vJll2zzCLMbOvnsciF 9+/NfHEn8vfWw3XXCxcecOEWUCrzmdR5rlrjFathz235Nczv0lfbrJ7BKeXTfNwynUuueCqX bKauVN/c893Wn7ImqnwQOMu/4v4n1zW7Kt2alYuX/T8vyNsrz6bEUpyRaKjFXFScCAC7N+0P UAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/5Z2f1Y8lrnbkigd93jz7YFlvJR8 Cc: Flemming Andreasen Subject: [MMUSIC] MMUSIC Agenda Requests for IETF 91 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 19:02:09 -0000 Hi all, MMUSIC has again two 2,5 hour sessions tentatively scheduled: http://tools.ietf.org/agenda/91/ If you want to request a time slot to discuss a draft, please send an e-mail to the chairs as soon as possible, but latest by the end of Tuesday 21st of October. As usual, we want to ensure we take advantage of our meeting time in a productive manner that leads to forward progress. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback already. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following: - name of the draft and the presenter - how much time would you need - outline of major open issues; what needs to be discussed at the meeting - dependencies to your draft (if any) Thanks, Ari & Flemming From nobody Wed Oct 15 12:13:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EE11A9138 for ; Wed, 15 Oct 2014 12:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p1wf8pO32Cf for ; Wed, 15 Oct 2014 12:13:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945CC1A1B19 for ; Wed, 15 Oct 2014 12:13:48 -0700 (PDT) Received: from BL2PR08MB225.namprd08.prod.outlook.com (10.242.199.13) by BL2PR08MB226.namprd08.prod.outlook.com (10.242.199.15) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 15 Oct 2014 19:13:42 +0000 Received: from BL2PR08MB225.namprd08.prod.outlook.com ([169.254.10.80]) by BL2PR08MB225.namprd08.prod.outlook.com ([169.254.10.80]) with mapi id 15.00.1054.004; Wed, 15 Oct 2014 19:13:43 +0000 From: Yong Xin To: "mmusic@ietf.org" Thread-Topic: RTCP bandwidth modifiers in a unicast SDP Offer/Answer Thread-Index: Ac/oq9AmyebyeNPBRvub2lK0DA6zRg== Date: Wed, 15 Oct 2014 19:13:42 +0000 Message-ID: <86084b9b964c4b178c43d0b37bb1372d@BL2PR08MB225.namprd08.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [209.82.16.66] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR08MB226; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(99286002)(107886001)(2351001)(95666004)(122556002)(80022003)(46102003)(107046002)(105586002)(86362001)(229853001)(92566001)(76576001)(15975445006)(106356001)(50986999)(99396003)(54356999)(20776003)(77096002)(31966008)(101416001)(120916001)(76482002)(19580395003)(40100003)(64706001)(87936001)(110136001)(33646002)(4396001)(85852003)(21056001)(97736003)(85306004)(2501002)(2656002)(15202345003)(108616004)(230673001)(74316001)(66066001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR08MB226; H:BL2PR08MB225.namprd08.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_86084b9b964c4b178c43d0b37bb1372dBL2PR08MB225namprd08pro_" MIME-Version: 1.0 X-OriginatorOrg: radisys.com Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/U08ARjKxEfGQV5-p0I4RblEzIsU Subject: [MMUSIC] RTCP bandwidth modifiers in a unicast SDP Offer/Answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 19:13:50 -0000 --_000_86084b9b964c4b178c43d0b37bb1372dBL2PR08MB225namprd08pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi mmusic experts, My google search found this thread https://www.ietf.org/mail-archive/web/mm= usic/current/msg07254.html but could not find an answer for it. I have the same question - is anybody in this group able to answer this que= stion? Thanks, Yong --_000_86084b9b964c4b178c43d0b37bb1372dBL2PR08MB225namprd08pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi mmusic experts,
 
 
I have the same question – is anybody in this group able to answ= er this question?
 
Thanks,
Yong
 
 
 --_000_86084b9b964c4b178c43d0b37bb1372dBL2PR08MB225namprd08pro_-- From nobody Wed Oct 15 12:25:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4081A9153 for ; Wed, 15 Oct 2014 12:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6hjwJXShCb4 for ; Wed, 15 Oct 2014 12:25:08 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F48E1A9251 for ; Wed, 15 Oct 2014 12:25:07 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-36-543eca110473 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EC.6F.04081.11ACE345; Wed, 15 Oct 2014 21:25:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Wed, 15 Oct 2014 21:25:05 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments Thread-Index: Ac/n1XBtzTLmfbOlQvSkbOT9iPCTaf//7RSA//49PmA= Date: Wed, 15 Oct 2014 19:25:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47E535@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47C8AD@ESESSMB209.ericsson.se> <99CAC302-DF7B-4C7F-A5FD-3B6017811F88@csperkins.org> In-Reply-To: <99CAC302-DF7B-4C7F-A5FD-3B6017811F88@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3RlfwlF2Iwb93qhbLX55gtPjUvYHN 4v0FXYupyx+zOLB4TPm9kdVj2v37bB5Llvxk8vhy+TNbAEsUl01Kak5mWWqRvl0CV8ble21M Bcd5K059mcvawHiPq4uRk0NCwETi0rGdbBC2mMSFe+uBbC4OIYGjjBJPt69jh3CWMEosWdHF 2MXIwcEmYCHR/U8bpEFEQFVix/F/jCA1zAL7GCVuHDrMDpIQFoiXeLb9OwtEUYLEzavPmCBs K4ldi2+xgtgsQM2Pz0wDq+EV8JU4vngBK8SyFkaJmYf+sIMs4xRwlHg1JRCkhhHouu+n1oDN YRYQl7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwphK0msPbydBaJeR2LB7k9sELa2xLKFr5kh9gpK nJz5hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjEC4+zg lt8GOxhfPnc8xCjAwajEw6tw1TZEiDWxrLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUw8gdmGpSfcDmVtKDbMvZJm6xC2JXVuYL54kelZvzfkjbh1JXsnj69ln8u aey7XnXMkwsX3rD/xCO72ju9goeuCNg9yM01qrt+OjdHPPTms0dTWk5r96zsii93bb/QxNzN 6GTfF1cWuV+y7HqU9KKK6XdWz2zh6Tm5tWg5p4iUm+OF7EuvZW8psRRnJBpqMRcVJwIAC2nq pJQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/35glusazrZIN-ufe_CWURgT0lTw Cc: Flemming Andreasen , "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 19:25:09 -0000 Hi Colin, >>> - Section 1, 7th paragraph: typo "a new RTP SDES item" -> "a new RTCP S= DES item" >>=20 >> I actually use "RTP SDES item" and "RTP MID SDES item" terminology in qu= ite a few places. >>=20 >> The reason is because that is what they are called in the IANA registry: >>=20 >> http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rt >> p-parameters-5 >>=20 >> But, I have problem to change to "RTCP SDES item" if that is the=20 >> correct terminology :) > > It's not especially important; I just want to make sure it's not confused= with RTP security descriptions, which is sometimes referred to as SDES. You know better than me what terminology is used out there :) ------------------------ =20 >>> - Section 13.2: it may be useful to clarify that the mid value is not z= ero terminated. >>=20 >> Can you suggest text? :) > > "The mid value is not zero terminated" Ok :) ------------------------ =20 >>> - Section 13.3: again, clarify that the mid value is not zero=20 >>> terminated. It may also be useful to remind implementers that the RFC 5= 285 format requires=20 >>> padding out to the next 32-bit boundary using zero bytes if the size of= the header extension=20 >>> isn't a multiple of 32 bits. This > padding could easily be confused wi= th a terminating zero by=20 >>> a careless implementer. >>=20 >> Can you suggest text? :) > > "The mid value is not zero terminated. Note, however, that RTP header ext= ensions that are not a multiple of 32 bits in length MUST be padded to the = next 32-bit boundary using zero=20 > bytes; these padding bytes are not included in the header length field [R= FC5285]." Thanks! Regards, Christer From nobody Wed Oct 15 13:14:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7C91A88CD for ; Wed, 15 Oct 2014 13:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5ryDZxwkGjh for ; Wed, 15 Oct 2014 13:14:27 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7215D1A879F for ; Wed, 15 Oct 2014 13:14:27 -0700 (PDT) Received: from ppp118-209-159-157.lns20.mel8.internode.on.net ([118.209.159.157]:51536 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XeUwC-0006dg-NQ; Thu, 16 Oct 2014 07:12:48 +1100 Message-ID: <543ED59D.400@nteczone.com> Date: Thu, 16 Oct 2014 07:14:21 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <20141015095756.7536.80011.idtracker@ietfa.amsl.com> <0C3D8AA4-DFC0-49C4-87B5-E47BF06B2DB8@cisco.com> <543E5A96.4060505@nteczone.com> <1CFC8A04-D7AC-4C6B-B822-F36087544182@cisco.com> In-Reply-To: <1CFC8A04-D7AC-4C6B-B822-F36087544182@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SlGmCXqbhlU2aJ6_LTlmjjqbdkM Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] New draft discussion 4566bis IANA issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 20:14:35 -0000 Hello Ali, No I don't know why it wasn't registered. I suspect it was forgotten as the IANA considerations were buried in an Appendix and 14 years ago the processes weren't as robust as they are today. It seems there's also some attributes that weren't registered e.g. a=phone-content, a=clir, a=Q763-nature, a=Q763-plan, a=Q763-INN, a=require. It also wants to register the PROTO values "voice, fax" and "pager". These don't appear in the IANA proto registry either. I don't have any particular interest in PINT. I stumbled across it when I went digging when I noticed the E164 problem. Regards, Christian On 15/10/2014 11:10 PM, Ali C. Begen (abegen) wrote: > On Oct 15, 2014, at 1:29 PM, Christian Groves wrote: > >> Hello Ali, >> >> Thanks for doing the draft. I think having the "usable nettype values" is an improvement. > Thanks, > >> With regards to the list of address types, the IANA registry is still missing network "TN" and address type "RFC2543" from RFC2848. It should be added for completeness. > Do you remember why it was omitted in the first place? > >> Regards, Christian >> >> On 15/10/2014 9:08 PM, Ali C. Begen (abegen) wrote: >>> Hi everyone >>> >>> 4566bis draft had major changes in the last revision. It is pending WG's review (See Paul K.' email dated Sept. 23rd). >>> >>> 4566bis had other open issues as listed in the tracker. >>> http://trac.tools.ietf.org/wg/mmusic/trac/report/1 >>> >>> For all the IANA related matters, I just submitted a new draft addressing tickets 15, 16, 17, 18 and 19. >>> https://datatracker.ietf.org/doc/draft-begen-mmusic-rfc4566bis-iana-updates/ >>> >>> Please review this draft as the chairs will likely take an action on it in the next meeting. It addresses all the issues we have identified so far in the IANA registries for the SDP. Once we agree on these changes, we can either publish that draft right away (and keep 4566bis open for a bit longer) or move all the IANA changes to the 4566bis document and everything gets published together. That is a rather minor issues. Most importantly, we need reviews and approvals for these IANA changes. >>> >>> There is another draft that will change the IANA registry structure for SDP parameters and attributes (draft-ietf-mmusic-sdp-mux-attributes). To minimize the load on the IANA folks, we need to decide on these changes soon and schedule things carefully. >>> >>> Any questions/comments, post to the list. >>> >>> -acbegen >>> >>> >>> Begin forwarded message: >>> >>>> From: >>>> Subject: New Version Notification for draft-begen-mmusic-rfc4566bis-iana-updates-00.txt >>>> Date: October 15, 2014 at 11:57:56 AM GMT+2 >>>> To: Ali Begen , "Ali C. Begen" >>>> >>>> >>>> A new version of I-D, draft-begen-mmusic-rfc4566bis-iana-updates-00.txt >>>> has been successfully submitted by Ali Begen and posted to the >>>> IETF repository. >>>> >>>> Name: draft-begen-mmusic-rfc4566bis-iana-updates >>>> Revision: 00 >>>> Title: IANA Registry Updates for RFC 4566bis >>>> Document date: 2014-10-15 >>>> Group: Individual Submission >>>> Pages: 5 >>>> URL: http://www.ietf.org/internet-drafts/draft-begen-mmusic-rfc4566bis-iana-updates-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-begen-mmusic-rfc4566bis-iana-updates/ >>>> Htmlized: http://tools.ietf.org/html/draft-begen-mmusic-rfc4566bis-iana-updates-00 >>>> >>>> >>>> Abstract: >>>> The Session Description Protocol (SDP) specification is currently >>>> being revised. There are a number of issues that have been >>>> identified in the IANA registries related to the SDP protocol (These >>>> are tracked in the issue tracker). This document has the goal of >>>> addressing these issues by making the necessary changes in the IANA >>>> registries and registration procedures. >>>> >>>> The changes and updates listed in this draft are submitted in this >>>> individual draft rather than the 4566bis draft because (i) the >>>> 4566bis draft has seen quite a number of changes recently, which >>>> require a detailed review and further revisions would make the review >>>> process difficult, and (ii) the changes and updates listed in this >>>> draft are all IANA related matters. If this draft gets published >>>> separately, it will update RFC 4566 or the RFC resulting from the >>>> 4566bis draft. An alternative option is to include the whole text in >>>> the 4566bis draft once the changes and updates are agreed. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>> _______________________________________________ >>> 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 nobody Wed Oct 15 17:02:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7C71ACE9C for ; Wed, 15 Oct 2014 17:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G06lhuDIySAp for ; Wed, 15 Oct 2014 17:02:32 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B89C1ACE9A for ; Wed, 15 Oct 2014 17:02:32 -0700 (PDT) Received: from auge (75-25-120-141.lightspeed.snvaca.sbcglobal.net [75.25.120.141]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s9G02K6k028572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Oct 2014 17:02:21 -0700 Date: Wed, 15 Oct 2014 17:02:20 -0700 (PDT) From: Stephen Casner To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47C8AD@ESESSMB209.ericsson.se> Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D47C8AD@ESESSMB209.ericsson.se> User-Agent: Alpine 2.19.9991 (OSX 64 2014-05-31) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Sonic-CAuth: UmFuZG9tSVaYLpOybDdHhC2tkEF0PiR8JjL0sqlhmnxwrbdtNAURhc/XUBj8Fl1/w517gCUh/aysTBDFW3vKqgChFl4XKJ85 X-Sonic-ID: C;sAHBssdU5BGZQIEG/FJGkA== M;Solns8dU5BGZQIEG/FJGkA== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/dK539XbV5jLsTO4tgqVZY3Neeq0 Cc: Flemming Andreasen , "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , Colin Perkins , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 00:02:34 -0000 On Tue, 14 Oct 2014, Christer Holmberg wrote: > Hi Colin, > > Thanks for your comments! See inline. > > >- Section 1, 7th paragraph: typo "a new RTP SDES item" -> "a new RTCP SDES item" > > I actually use "RTP SDES item" and "RTP MID SDES item" terminology in quite a few places. > > The reason is because that is what they are called in the IANA registry: > > http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-5 Aha. The registry title should be changed. -- Steve From nobody Wed Oct 15 22:58:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3481ACECB for ; Wed, 15 Oct 2014 22:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRSHT3vGd_sX for ; Wed, 15 Oct 2014 22:58:06 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8C01ACDF7 for ; Wed, 15 Oct 2014 22:58:06 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 231331EB845C; Thu, 16 Oct 2014 07:58:05 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 07:58:04 +0200 From: "Stach, Thomas" To: Parthasarathi R , =?utf-8?B?J0nDsWFraSBCYXogQ2FzdGlsbG8n?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: Ac/oYRpvuF9H8nwjukqj+Vm4R8Q5sgAMES8QAB0li9A= Date: Thu, 16 Oct 2014 05:58:04 +0000 Message-ID: References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <010501cfe805$72268000$56738000$@co.in> <003f01cfe892$be23f310$3a6bd930$@co.in> In-Reply-To: <003f01cfe892$be23f310$3a6bd930$@co.in> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/W8y6iqzmOWi4WlvLcmL037UzVFE Cc: =?utf-8?B?J0FyaSBLZXLDpG5lbic=?= , 'mmusic' , 'Christer Holmberg' Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 05:58:07 -0000 PiANCj4gPHNuaXA+ID4gSWYgdGhlIFNEUCBoYW5kbGluZyAiZW50aXR5IiBpcyBub3QgYXdhcmUg b2YgdGhlIG1lZGlhL1NUVU4gc3R1ZmYNCj4gdGhlbg0KPiA+IHlvdSBoYXZlIGEgYmlnIHByb2Js ZW0uIDwvc25pcD4NCj4gDQo+IElPVywgdGhlIHNlY29uZCBvZmZlci9hbnN3ZXIgaXMgcmVxdWly ZWQgdG8gc29sdmUgdGhlIHByb2JsZW0uDQpbVFNdIEl0IG1pZ2h0IHNvbHZlIHRoYXQgcHJvYmxl bSwgYnV0IGNhdXNlcyBvdGhlciBwcm9ibGVtcw0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBzaW5n bGUgb2ZmZXIvYW5zd2VyIG1heSBiZSBzdWl0YWJsZSBpbiBjb3VwbGUgb2YNCj4gZGVwbG95bWVu dHMgYnV0IGl0IGlzIG5vdCBnZW5lcmljIGVub3VnaCB0byBhY2NlcHQgYXMgYSBzaW5nbGUgc29s dXRpb24uDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogScOx YWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+ID4gU2VudDogV2VkbmVz ZGF5LCBPY3RvYmVyIDE1LCAyMDE0IDM6NDYgUE0NCj4gPiBUbzogUGFydGhhc2FyYXRoaSBSDQo+ ID4gQ2M6IENocmlzdGVyIEhvbG1iZXJnOyBBcmkgS2Vyw6RuZW47IG1tdXNpYw0KPiA+IFN1Ympl Y3Q6IFJlOiBbTU1VU0lDXSBJQ0UgdXBkYXRlZCBvZmZlcg0KPiA+DQo+ID4gMjAxNC0xMC0xNSAx OjIwIEdNVCswMjowMCBQYXJ0aGFzYXJhdGhpIFIgPHBhcnRoYUBwYXJ0aGFzYXJhdGhpLmNvLmlu PjoNCj4gPiA+IFNUVU4gb25seSBiYXNlZCBzaWduYWxpbmcgbWVjaGFuaXNtDQo+ID4gPiBpbiB0 aGUgbWlkZGxlIG9mIHRoZSBzZXNzaW9uIGxlYWRzIHRvIHRoZSBpc3N1ZSBpbiB0aG9zZSBhcmNo aXRlY3R1cmUNCj4gPiBhcyBTRFANCj4gPiA+IGhhbmRsaW5nIGVudGl0eSB3aWxsIG5vdCBhd2Fy ZSBvZiB0aGUgY29uY2x1c2lvbi4NCj4gPg0KPiA+IElmIHRoZSBTRFAgaGFuZGxpbmcgImVudGl0 eSIgaXMgbm90IGF3YXJlIG9mIHRoZSBtZWRpYS9TVFVOIHN0dWZmIHRoZW4NCj4gPiB5b3UgaGF2 ZSBhIGJpZyBwcm9ibGVtLg0KPiA+DQo+ID4NCj4gPiA+IFBsZWFzZSBub3RlIHRoYXQgU0RQIGhh bmRsaW5nIChzaWduYWxpbmcpIGVudGl0eSBhbmQgbWVkaWEgaGFuZGxpbmcNCj4gPiBlbnRpdHkN Cj4gPiA+IGFzIGEgZGlmZmVyZW50IGRldmljZSBpbiB0aGUgYW5zd2VyZXIgc2lkZSBpcyBub3Qg ZGVmaW5lZCBpbiBJRVRGDQo+ID4gUlRDV2ViIHNvDQo+ID4gPiBmYXIuDQo+ID4NCj4gPiBPZiBj b3Vyc2UuIEFuZCB3aGF0Pw0KPiA+IEJvdGggImVudGl0aWVzIiBhcmUgc3VwcG9zZWQgdG8gYmUg dGhlIHNhbWUsIG9yIHRvIGludGVyLWNvbW11bmljYXRlDQo+ID4gc29tZWhvdyBvbmUgdG8gZWFj aCBvdGhlci4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBJw7Fha2kgQmF6IENhc3RpbGxvDQo+ID4g PGliY0BhbGlheC5uZXQ+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K From nobody Wed Oct 15 23:17:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575881ACED4 for ; Wed, 15 Oct 2014 23:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFXrvu1dvZ9E for ; Wed, 15 Oct 2014 23:17:38 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 11E9E1ACECB for ; Wed, 15 Oct 2014 23:17:38 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 5179A23F0434; Thu, 16 Oct 2014 08:17:37 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 08:17:37 +0200 From: "Stach, Thomas" To: Parthasarathi R , 'Emil Ivov' , =?utf-8?B?J0nDsWFraSBCYXogQ2FzdGlsbG8n?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP6GJtuF9H8nwjukqj+Vm4R8Q5spwxLGYQgAAojICAAOuxkA== Date: Thu, 16 Oct 2014 06:17:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> In-Reply-To: <004001cfe896$36205220$a260f660$@co.in> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/V54g-Sghlo9a0ZIyStTSo1QMNJs Cc: "mmusic@ietf.org" , 'Roman Shpount' , 'Christer Holmberg' Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 06:17:39 -0000 PiANCj4gSGkgVGhvbWFzLA0KPiANCj4gSSdtIG5vdCBzZWVpbmcgdGhhdCB0aGUgc2Vjb25kIG9m ZmVyIGlzIHJlbGV2YW50IG9ubHkgdG8gU0lQLiANCltUU10gVGhhdCBpcyBub3Qgd2hhdCBJIHNh aWQuDQpGb3IgYmFja2dyb3VuZCBvbiBteSBvcmlnaW5hbCBzdGF0ZW1lbnQgeW91IG1heSB3YW50 IHRvIHJlZmVyIHRvDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yb3NlbmJlcmct bW11c2ljLWljZS1ub25zaXAtMDEjc2VjdGlvbi01LjQuMiANCg0KPiBFdmVuIGluIGNhc2UNCj4g V2ViUlRDIGVudGl0eSB3aXRoIChwcm9wcmlldGFyeSkgc2lnbmFsaW5nICYgbWVkaWEgaW4gdGhl IHNlcGFyYXRlIGRldmljZSwNCj4gV2ViUlRDIHNpZ25hbGluZyBlbnRpdHkgd2lsbCBub3QgYXdh cmUgb2YgdGhlIGFjdHVhbCBtZWRpYSBJUCwgcG9ydCAmDQo+IHRyYW5zcG9ydC4NCj4gDQo+IFRo YW5rcw0KPiBQYXJ0aGENCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBG cm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFN0YWNoLA0KPiA+IFRob21hcw0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNSwgMjAx NCA3OjE5IFBNDQo+ID4gVG86IEVtaWwgSXZvdjsgScOxYWtpIEJheiBDYXN0aWxsbw0KPiA+IENj OiBtbXVzaWNAaWV0Zi5vcmc7IFJvbWFuIFNocG91bnQ7IENocmlzdGVyIEhvbG1iZXJnDQo+ID4g U3ViamVjdDogUmU6IFtNTVVTSUNdIElDRSB1cGRhdGVkIG9mZmVyDQo+ID4NCj4gPg0KPiA+DQo+ ID4NCj4gPiBJIHJlYWxseSBkb24ndCB0aGluayBicm93c2VycyBoYXZlIGFueXRoaW5nIHRvIGRv IHdpdGggdGhpcy4gSXQgaXMNCj4gPiBwdXJlbHkgYSBtYXR0ZXIgb2Ygc2lnbmFsbGluZy4gTm90 aGluZyBuZWVkcyB0byBiZSBjaGFuZ2VkIGZvciB3ZWJydGMNCj4gPiBvbmUgd2F5IG9yIGFub3Ro ZXIuDQo+ID4gW1RTXSBJIGFncmVlLiBJQ0UgdXBkYXRlZCBvZmZlciB3YXMgaW50cm9kdWNlZCB0 byBhY2NvbW1vZGF0ZSBjZXJ0YWluDQo+ID4gU0lQIG1pZGRsZWJveGVzLiBJdHMgcmVsZXZhbmNl IG91dHNpZGUgb2YgU0lQIGlzIGF0IGxlYXN0IGRlYmF0YWJsZS4NCj4gPg0KPiA+IC0tc2VudCBm cm9tIG15IG1vYmlsZQ0KPiA+IE9uIDE1IE9jdCAyMDE0IDEyOjE4IFBNLCAiScOxYWtpIEJheiBD YXN0aWxsbyIgPGliY0BhbGlheC5uZXQ+IHdyb3RlOg0KPiA+IDIwMTQtMTAtMTUgODo1NSBHTVQr MDI6MDAgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gPiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPjoNCj4gPiA+IFdoYXQgSSBzdWdnZXN0IGhhcyB2ZXJ5IGxpdHRsZSBpbXBhY3Qgb24gSUNF IGFzIGRlZmluZWQgdG9kYXkuIEl0DQo+ID4gb25seSBhZGRzDQo+ID4gPiBzb21lIGtpbmQgb2Yg aW5kaWNhdG9yIChpY2Utb3B0aW9ucyBhdHRyaWJ1dGUgdmFsdWU/KSB3aGV0aGVyIHRoZQ0KPiA+ IHNlY29uZA0KPiA+ID4gb2ZmZXIgaXMgbmVlZGVkIG9yIG5vdC4gU2ltcGxlIDopDQo+ID4NCj4g PiBBbmQgaW4gY2FzZSB0aGUgU0RQIHNheXMgdGhhdCB0aGUgInNlY29uZCBvZmZlciIgaXMgcmVx dWlyZWQsIHRoZW4NCj4gPiB3aGF0PyBJIG1lYW4sIHNob3VsZCB0aGUgYnJvd3NlciBkbyBzYW1l dGhpbmcgKEkgbWVhbiBuYXRpdmVseSk/IG9yIGlzDQo+ID4gaXQganVzdCB1cCB0byB0aGUgSlMg YXBwbGljYXRpb24/DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gScOxYWtpIEJheiBDYXN0aWxsbw0K PiA+IDxpYmNAYWxpYXgubmV0Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+ID4gbW11c2lj QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gPiBtbXVzaWNAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= From nobody Wed Oct 15 23:23:33 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C171ACEDB for ; Wed, 15 Oct 2014 23:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H__LiMBucdHf for ; Wed, 15 Oct 2014 23:23:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0D91A0370 for ; Wed, 15 Oct 2014 23:23:30 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-55-543f64610699 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 27.FD.04081.1646F345; Thu, 16 Oct 2014 08:23:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 08:23:28 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Parthasarathi R Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP5+NicCZjzEhGnkuH0Ney21PC/JwwuWOQgAAX6ICAAAJCAIAAOI8AgAAu9oCAAADJgIABBy4Q Date: Thu, 16 Oct 2014 06:23:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> 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.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3RjcxxT7EYNZ9AYs1OyewWEzfZ2Mx dfljFovJn/pYLWZcmMpscXLnNmYHNo9zDe/ZPZYs+cnk8f9NoMeH+V/YPW5NKfDY3vOYJYAt issmJTUnsyy1SN8ugStj0rUf7AWr2CoO333O1sA4ha2LkZNDQsBE4s7+eUwQtpjEhXvrgeJc HEICRxklNkydwQiSEBJYwijx/pB0FyMHB5uAhUT3P22QsIhAjsSdOxtZQeqZBSYzSly93McC UiMsoC4x5Z4CRI2GxIJrXxhBwiICURJfZ5eDhFkEVCVe3m4GW8sr4Csx9/sZJoi1N5gllp6b A5bgFAiUmN23ihnEZgS67fupNWBxZgFxiVtP5kPdLCCxZM95ZghbVOLl43+sELaSxI8Nl8DO YRbQlFi/Sx+iVVFiSvdDdoi9ghInZz5hmcAoNgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqR kV5qUWZycXF+nl5easkmRmAMHtzy22AH48vnjocYBTgYlXh4H8bZhwixJpYVV+YeYpTmYFES 5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYIB+tHR94dPsRdHWqRpyI1qe9CY9CO b52yF2ZefbW6wviv//8Fr3ocv99KW9zIp7yx7WQ81918Fwe7vbdvJp6SOfXd/ZPOgWNWEhud hbb+NN7LyH91xtX+to9l/q02zAkufCtnL7usf6vd67L2oluhE7sL4qpfiyf8jMvZ906grjti 9iUXte1KLMUZiYZazEXFiQCtiN+zogIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/y8oOtJwdF04nwkZNNk5ngeBckvA Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 06:23:32 -0000 SGksDQoNCj4+IGluIGNhc2UgV2ViUlRDIGVudGl0eSB3aXRoIChwcm9wcmlldGFyeSkgc2lnbmFs aW5nICYgbWVkaWEgaW4gdGhlIHNlcGFyYXRlIGRldmljZSwgV2ViUlRDIHNpZ25hbGluZyBlbnRp dHkgd2lsbCBub3QgYXdhcmUgb2YgdGhlIGFjdHVhbCBtZWRpYSBJUCwgcG9ydCAmIHRyYW5zcG9y dC4NCj4NCj4gSWYgc29tZWJvZHkgYnVpbGRzIGEgV2ViUlRDIGVudGl0eS9lbmRwb2ludC93aGF0 ZXZlciBpbiB3aGljaCB0aGUgc2lnbmFsaW5nICJlbnRpdHkiIGFuZCB0aGUgbWVkaWEgImVudGl0 eSIgYXJlIG5vdCBpbnRlci1jb21tdW5pY2F0ZWQuLi4gdGhlbiBpbmRlZWQgdGhhdCBpcyBhIGJp ZyBwcm9ibGVtLiBBIGJpZw0KPiAqZGVzaWduKiBwcm9ibGVtLiBKdXN0IGZpeCBpdC4NCg0KT2J2 aW91c2x5IHRoZSBzaWduYWxpbmcgZW50aXR5IG5lZWRzIHRvIGJlIGFibGUgdG8gY29udHJvbCB0 aGUgbWVkaWEgZW50aXR5LiBJZiB0aGF0IGNvbnRyb2wgaXMgYmFzZWQgb24gdGhlIFNEUCBpbmZv cm1hdGlvbiwgdGhhdCBTRFAgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgY29ycmVjdC4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Wed Oct 15 23:26:05 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BAD1A0370 for ; Wed, 15 Oct 2014 23:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q08-dWhrLqQV for ; Wed, 15 Oct 2014 23:26:02 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5E21A0248 for ; Wed, 15 Oct 2014 23:26:01 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-df-543f64f7b544 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 13.A3.24955.7F46F345; Thu, 16 Oct 2014 08:26:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 08:25:59 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Parthasarathi R Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP54cGcCZjzEhGnkuH0Ney21PC/JwvRHTAgADxSCCAAJvKAIAAY1YAgAAHHICAAQhoQA== Date: Thu, 16 Oct 2014 06:25:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47EBBE@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D47B9DA@ESESSMB209.ericsson.se> <010501cfe805$72268000$56738000$@co.in> <003f01cfe892$be23f310$3a6bd930$@co.in> 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.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvje6PFPsQgzuvOS2m77OxmLr8MYvF 5E99rA7MHuca3rN7LFnyk8njw/wv7AHMUVw2Kak5mWWpRfp2CVwZ/34uYSw4xFbRs+cLWwPj GrYuRk4OCQETicOnm5kgbDGJC/fWA8W5OIQEjjJKvDzYywrhLGGU6DrYztzFyMHBJmAh0f1P G6RBRCBH4s6djawgNrNAuMSDH6vZQUqEBdQlptxTgCjRkFhw7QsjhB0m0bl4JTOIzSKgKjF5 zy+wVl4BX4kvK14xQay6yCSxa+ECsOM4BQIlDn6/DGYzAh33/dQaJohd4hK3nsyHOlpAYsme 88wQtqjEy8f/WCFsJYkfGy6xgNzDLKApsX6XPkSrosSU7ofsEHsFJU7OfMIygVFsFpKpsxA6 ZiHpmIWkYwEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwGg6uOW36g7Gy28cDzEKcDAq 8fA+iLMPEWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjDEr EjzNQ3ujvl5d92jrNybxBf5OWpkMT/eJmSYWPhYt6HJKKzq5mktAr/rFPxY5BZ6F+lk7jr9S EHO6MD9/sjvfds65tY/TGTjc279WMynq7Mq3X1Z08TBna52z1+3vPBZz75+1tHjamlwvuWP5 436dh6ElrTHXP/Hl8VVbT38lFbFYsH2fEktxRqKhFnNRcSIAhCLQRIcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1ve2_QCgJ0kY1RW1N6vtUxuWm5M Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , mmusic Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 06:26:03 -0000 SGksDQoNCj4+IFBsZWFzZSBub3RlIHRoYXQgc2luZ2xlIG9mZmVyL2Fuc3dlciBtYXkgYmUgc3Vp dGFibGUgaW4gY291cGxlIG9mIGRlcGxveW1lbnRzIGJ1dCBpdCBpcyBub3QgZ2VuZXJpYyBlbm91 Z2ggdG8gYWNjZXB0IGFzIGEgc2luZ2xlIHNvbHV0aW9uLg0KPg0KPiBOb3RoaW5nIHByZXZlbnRz IHlvdSBmcm9tIHBlcmZvcm1pbmcgYSBzZWNvbmQgYW5kIGEgdGhpcmQgTy9BIHJvdW5kIHRyaXAu DQoNClRoZSB3aG9sZSBwdXJwb3NlIGlzIHRvLCBpbiB0aGUgSUNFIHNwZWMsIHNwZWNpZnkgdGhh dCB0aGF0IHNlY29uZCBvZmZlciBtdXN0IGJlIHNlbnQsIHNvIHRoYXQgcGVvcGxlIGltcGxlbWVu dGluZyBhcHBsaWNhdGlvbnMgKEphdmFTY3JpcHQgb3IgbmF0aXZlKSBkbyBpdC4NCg0KQnV0LCBh Z2FpbiwgSSBkbyByZWFsaXplIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB0aGUgc2Vjb25kIG9mZmVy IGlzIG5vdCBuZWVkZWQsIGFuZCB0aGF0IGlzIHdoeSBJIGFzIGEgY29tcHJvbWlzZSBzdWdnZXN0 ZWQgdGhhdCBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gc2lnbmFsIHdoZXRoZXIgaXQncyBuZWVk ZWQgb3Igbm90Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Thu Oct 16 00:20:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972DE1A0381 for ; Thu, 16 Oct 2014 00:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8NAK-_bffaR for ; Thu, 16 Oct 2014 00:20:16 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 39B591A037A for ; Thu, 16 Oct 2014 00:20:16 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 5CCEC1EB858C; Thu, 16 Oct 2014 09:20:15 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 09:20:14 +0200 From: "Stach, Thomas" To: Christer Holmberg , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Parthasarathi R Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP6GJtuF9H8nwjukqj+Vm4R8Q5spwwuWOQgAAX6ICAAAJCAIAAOI8AgAAu9oCAAADJgIABBy4QgAAAuGA= Date: Thu, 16 Oct 2014 07:20:14 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OiTUfSHz9pahdT_6m5c5JeRxsdc Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 07:20:17 -0000 PiANCj4gSGksDQo+IA0KPiA+PiBpbiBjYXNlIFdlYlJUQyBlbnRpdHkgd2l0aCAocHJvcHJpZXRh cnkpIHNpZ25hbGluZyAmIG1lZGlhIGluIHRoZQ0KPiBzZXBhcmF0ZSBkZXZpY2UsIFdlYlJUQyBz aWduYWxpbmcgZW50aXR5IHdpbGwgbm90IGF3YXJlIG9mIHRoZSBhY3R1YWwgbWVkaWENCj4gSVAs IHBvcnQgJiB0cmFuc3BvcnQuCQ0KPiA+DQo+ID4gSWYgc29tZWJvZHkgYnVpbGRzIGEgV2ViUlRD IGVudGl0eS9lbmRwb2ludC93aGF0ZXZlciBpbiB3aGljaCB0aGUNCj4gc2lnbmFsaW5nICJlbnRp dHkiIGFuZCB0aGUgbWVkaWEgImVudGl0eSIgYXJlIG5vdCBpbnRlci1jb21tdW5pY2F0ZWQuLi4N Cj4gdGhlbiBpbmRlZWQgdGhhdCBpcyBhIGJpZyBwcm9ibGVtLiBBIGJpZw0KPiA+ICpkZXNpZ24q IHByb2JsZW0uIEp1c3QgZml4IGl0Lg0KPiANCj4gT2J2aW91c2x5IHRoZSBzaWduYWxpbmcgZW50 aXR5IG5lZWRzIHRvIGJlIGFibGUgdG8gY29udHJvbCB0aGUgbWVkaWENCj4gZW50aXR5LiBJZiB0 aGF0IGNvbnRyb2wgaXMgYmFzZWQgb24gdGhlIFNEUCBpbmZvcm1hdGlvbiwgdGhhdCBTRFANCj4g aW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgY29ycmVjdC4NCltUU10gVGhlIFNEUCBpbmZvcm1hdGlv biBpcyBjb3JyZWN0IGFuZCBpdCBwcm92aWRlcyBldmVyeXRoaW5nIHRoYXQgdGhlIG1lZGlhIGVu dGl0eSBuZWVkcyAodmlhIHRoZSBjYW5kaWRhdGVzKS4NClNpbmNlIGFsbCBjb25uZWN0aXZpdHkg Y2hlY2tzIGZvbGxvdyB0aGUgbWVkaWEgcGF0aCB0aGUgbWVkaWEgZW50aXR5IGlzIGFsc28gYWJs ZSB0byBsZWFybiB0aGUgZXZlbnR1YWxseSB1c2VkIG1lZGlhIElQLCBwb3J0ICYgdHJhbnNwb3J0 Lg0KSSBhZ3JlZSBpdCBpcyAianVzdCIgYSBkZXNpZ24gcHJvYmxlbS4NCg0KPiANCj4gUmVnYXJk cywNCj4gDQo+IENocmlzdGVyDQoNCg== From nobody Thu Oct 16 00:36:41 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC141A038C for ; Thu, 16 Oct 2014 00:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGtX8jKWH7fA for ; Thu, 16 Oct 2014 00:36:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A7A1A038B for ; Thu, 16 Oct 2014 00:36:36 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-7a-543f7582dff6 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.2F.24955.2857F345; Thu, 16 Oct 2014 09:36:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 09:36:34 +0200 From: Christer Holmberg To: "Stach, Thomas" , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Parthasarathi R Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP5+NicCZjzEhGnkuH0Ney21PC/JwwuWOQgAAX6ICAAAJCAIAAOI8AgAAu9oCAAADJgIABBy4Q///u6gCAACTyUA== Date: Thu, 16 Oct 2014 07:36:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+JvjW5TqX2IwZ0J6hZrdk5gsZi+z8Zi 6vLHLBaTP/WxWsy4MJXZ4uTObcwObB7nGt6zeyxZ8pPJ4/+bQI8P87+we9yaUuCxvecxSwBb FJdNSmpOZllqkb5dAlfGxEk7WAu2cVd8WrOGuYFxAncXIyeHhICJxPLrF5kgbDGJC/fWs3Ux cnEICRxllLjx4TozhLOEUeLn/6msXYwcHGwCFhLd/7RB4iICMxglPt5dC9bNLJAt8WlfFzNI jbCAusSUewogYREBDYkF174wgoRFBLIkJi2NBQmzCKhKvNvXyw5i8wr4SmxeNpsVYtVDFonO xY1sIAlOAX+JC53PwYoYgY77fmoN1CpxiVtP5kMdLSCxZM95ZghbVOLl43+sELaixM6z7WDn MAtoSqzfpQ/Rqigxpfsh1F5BiZMzn7BMYBSbhWTqLISOWUg6ZiHpWMDIsopRtDi1OCk33chY L7UoM7m4OD9PLy+1ZBMjMAoPbvmtuoPx8hvHQ4wCHIxKPLwP4uxDhFgTy4orcw8xSnOwKInz Ljw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo7HeA+PrS+Im7Hl00vlDZqdPzKSPvAJu 73xdr691FKtQKQxunnDA7/LPJe+jPRPPerdZFmjWvGILkH8dWzp1Vkai/Kk2qW3hJ1ibl3hU lpdf/f6QmeHYz++S4a0bF2V4K21sfGi24uTu/YZvQns2zfp56GkHS/Tmq8L1U4Vd/Fk2c1j7 fj69UYmlOCPRUIu5qDgRAH63+VWjAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RYb09PMWZ5U9D35Xd1xb12fwK4o Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 07:36:39 -0000 SGksDQoNCj4+IE9idmlvdXNseSB0aGUgc2lnbmFsaW5nIGVudGl0eSBuZWVkcyB0byBiZSBhYmxl IHRvIGNvbnRyb2wgdGhlIG1lZGlhIA0KPj4gZW50aXR5LiBJZiB0aGF0IGNvbnRyb2wgaXMgYmFz ZWQgb24gdGhlIFNEUCBpbmZvcm1hdGlvbiwgdGhhdCBTRFAgDQo+PiBpbmZvcm1hdGlvbiBuZWVk cyB0byBiZSBjb3JyZWN0Lg0KPiBbVFNdIFRoZSBTRFAgaW5mb3JtYXRpb24gaXMgY29ycmVjdCBh bmQgaXQgcHJvdmlkZXMgZXZlcnl0aGluZyB0aGF0IHRoZSBtZWRpYSBlbnRpdHkgbmVlZHMgKHZp YSB0aGUgY2FuZGlkYXRlcykuDQo+IFNpbmNlIGFsbCBjb25uZWN0aXZpdHkgY2hlY2tzIGZvbGxv dyB0aGUgbWVkaWEgcGF0aCB0aGUgbWVkaWEgZW50aXR5IGlzIGFsc28gYWJsZSB0byBsZWFybiB0 aGUgZXZlbnR1YWxseSB1c2VkIG1lZGlhIElQLCBwb3J0ICYgdHJhbnNwb3J0Lg0KDQpUaGF0IGlz IG5vdCBob3cgbWFueSBjdXJyZW50IGRlcGxveW1lbnRzIHdvcmsgdG9kYXksIGFuZCBJIGRvbid0 IHRoaW5rIHdlIHNob3VsZCBtZXNzIHRob3NlIHVwIGJ5IGZpeGluZyBzb21ldGhpbmcgdGhhdCBp c24ndCBicm9rZW4gKG5vdCBzZW5kaW5nIHRoZSBzZWNvbmQgb2ZmZXIgaXMganVzdCBhbiBvcHRp bWl6YXRpb24pLg0KDQpUaGUgcmVxdWVzdCBmb3Igbm90IHNlbmRpbmcgdGhlIHNlY29uZCBvZmZl ciBjYW1lIG1haW5seSBmcm9tIHRoZSBXZWJSVEMgY29tbXVuaXR5LiBBbmQsIGFzIHdlIGhhdmUg bm90ZWQsIHRoZSBzZW5kaW5nIG9mIHRoZSBzZWNvbmQgb2ZmZXIgY2FuIGJlIHRha2VuIG9mIGJ5 IHRoZSBKUyBhcHAsIHNvIGl0IGRvZXNuJ3QgYWZmZWN0IHRoZSBXZWJSVEMgQVBJIGV0Yy4NCg0K Tm93LCBhcyBJIHNhaWQgZWFybGllciwgdGhlIEpTIGFwcCB3b3VsZCBoYXZlIHRvIGtub3cgd2hl biB0aGUgY2FuZGlkYXRlcyBoYXZlIGJlZW4gc2VsZWN0ZWQuIEJVVCwgSSB0aGluayB0aGF0IGlu Zm9ybWF0aW9uIGNvdWxkIGJlIHVzZWZ1bCB0byB0aGUgSlMgYXBwIGZvciBvdGhlciByZWFzb25z IHRoYW4gSUNFIHRvby4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Thu Oct 16 01:14:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249391A039D for ; Thu, 16 Oct 2014 01:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADEgSEozVT7i for ; Thu, 16 Oct 2014 01:14:07 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C191A0398 for ; Thu, 16 Oct 2014 01:14:06 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id j107so2134203qga.2 for ; Thu, 16 Oct 2014 01:14:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=mdPZKuzTrft8irYcUVnf3gQIieUu+7vXeMSPJYpbuAU=; b=NuP0pKVs0cRItUBwlsLYwC14ER7bPqB5k09hwlNw0bB5v/y/CegMN0XZlUqVXFV7kT dTg/4r09ctF+NpxTZPEsY4oIJrsGC8ot0aZ/g40Xzp05mnm/j2bAuLnvYAYenVTJS0cw b3kNeSilAGcQ/fmTzX7umjzh3uVqtclOQb3y08HyqQOZVqdGJrQgKxJhbu8D+AA6tqBM dl59wTZ1W/qncMtPtO2oGVHChjpRVSmihVD9t+szvbR3xDDlVMMZL85zv38qYUoIxcFh RWwlGrANo62/3/QgrivEGUJzGae86l/pa8F+DMtcWzDsDvQ1+FSe0UHzeRFiWVb+AyVN h6AQ== X-Gm-Message-State: ALoCoQnSBNHTX/hjcjX3HzgwwMtBQRVaaOUMeL5I02jkPHcPFzMPCakPZ1ZW3hWyyz5tPlGi0w7K X-Received: by 10.224.20.199 with SMTP id g7mr5912413qab.74.1413447246046; Thu, 16 Oct 2014 01:14:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Thu, 16 Oct 2014 01:13:45 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 16 Oct 2014 10:13:45 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tLClfMtfdzYJhvQJJcWpgZQZe3c Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 08:14:10 -0000 2014-10-16 8:23 GMT+02:00 Christer Holmberg : > Obviously the signaling entity needs to be able to control the media enti= ty. If that control is based on the SDP information, that SDP information n= eeds to be correct. I hope the media entity is able to notify its signaling entity about the selected candidate pair. Does your signaling entity trust the remote peer more than its own media en= tity? Regards. --=20 I=C3=B1aki Baz Castillo From nobody Thu Oct 16 01:18:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59AB1A039D for ; Thu, 16 Oct 2014 01:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPsB_Au0Xc0A for ; Thu, 16 Oct 2014 01:18:36 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6B71A0398 for ; Thu, 16 Oct 2014 01:18:36 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id c9so2307889qcz.8 for ; Thu, 16 Oct 2014 01:18:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=aPYAIAgO+UmDEceimvBa5pNMTVL5ekNlrwbjK/SRVG4=; b=ZOvCQnJAA2Cdpn5PKoZZ+gmsvnRBJB2Dnh1feRdHfHjQXDuvF9XpRzRwlt6yvZme0z 7pwCotrVKAUOFiG5KoNZ3vsL5zme5knQtI+iL/i1McSI/pQFiOjXnnik+veClP+ih4xt KitFVxAjI0AgHLruQPLRAx3H6pfF//a8k+WiTP2GUYWMwcbstKjsiXjmxXpKeIwVNfxN +Vq/nF/kw7I6v+uLWv1C31st5zVVfzN+9YzEkSFIcO6vBL63dxEfDJmaIzSbweYJFyOH 9g643Lp4icE0uZY50OeDJHGD4RA/L6AivxzXACmjKIJXAzfgV1HWTyLG5TIb6if6KYMq srAw== X-Gm-Message-State: ALoCoQl2gTwVR2gv+e/LhO3ULPPGgGCK7310ypNPLpTKL4suqNK7XyteFFPF3dttMOOMnZ/fnDIz X-Received: by 10.229.236.197 with SMTP id kl5mr397163qcb.31.1413447515360; Thu, 16 Oct 2014 01:18:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Thu, 16 Oct 2014 01:18:14 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 16 Oct 2014 10:18:14 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_3DO5QkBbWgMIV_2uJE9wvhxC1M Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 08:18:38 -0000 2014-10-16 9:36 GMT+02:00 Christer Holmberg : > Now, as I said earlier, the JS app would have to know when the candidates= have been selected. BUT, I think that information could be useful to the J= S app for other reasons than ICE too. That's impossible with the current API as it is not "transport"-based but "all-stuff-together"-based, which means that the JS application has no way to know the number of transports being negotiated, and hence an API to provide paired candidates is of little use within WebRTC 1.0. --=20 I=C3=B1aki Baz Castillo From nobody Thu Oct 16 02:00:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F871A1AE8 for ; Thu, 16 Oct 2014 02:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSECUxETHVkN for ; Thu, 16 Oct 2014 02:00:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72571A1AE0 for ; Thu, 16 Oct 2014 02:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1794; q=dns/txt; s=iport; t=1413450015; x=1414659615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ag+QfDDp10PMBAiMANKJd79d8Iu81e63NlPT7Cm6APY=; b=BxAqMgDYBnaGZgUL6rBN2VmnKY3QQQikNmJLBz6y3c/yTeKdcLoXrh/C UocQuyjqsKYvB533WnBSAj1CQHqHAdHMOv98Jg4XB+R5cOmBCsjA1WgiI QNAWoy+13jD9bwPSR4mod/jL3+FADTngbXAM4gh/xpFtbxpAm+a+MnsT4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FACyIP1StJV2b/2dsb2JhbABbgw5TWATMBgqGeVQCgRAWAX2EAgEBAQMBAQEBawsMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCAyIIggNyWkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBJAdMQcGgyeBHgWLI4ZcoXGDd2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,731,1406592000"; d="scan'208";a="363905339" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 16 Oct 2014 09:00:15 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9G90F4W026210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 09:00:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 04:00:14 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Christer Holmberg , "Stach, Thomas" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Parthasarathi R Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP6GJtuF9H8nwjukqj+Vm4R8Q5spwxLGYQgAAojICAAFtDgIAA5jyAgAAP3QCAAASPgP//vqBg Date: Thu, 16 Oct 2014 09:00:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2833D692@xmb-rcd-x10.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.239.82] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IdZykrtyeTBfIt0Hac3uN5nn5DA Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 09:00:17 -0000 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Thursday, October 16, 2014 1:07 PM > To: Stach, Thomas; I=F1aki Baz Castillo; Parthasarathi R > Cc: mmusic@ietf.org; Roman Shpount > Subject: Re: [MMUSIC] ICE updated offer >=20 > Hi, >=20 > >> Obviously the signaling entity needs to be able to control the media > >> entity. If that control is based on the SDP information, that SDP > >> information needs to be correct. > > [TS] The SDP information is correct and it provides everything that the > media entity needs (via the candidates). > > Since all connectivity checks follow the media path the media entity is= also > able to learn the eventually used media IP, port & transport. >=20 > That is not how many current deployments work today, and I don't think we > should mess those up by fixing something that isn't broken (not sending t= he > second offer is just an optimization). >=20 > The request for not sending the second offer came mainly from the WebRTC > community. And, as we have noted, the sending of the second offer can be > taken of by the JS app, so it doesn't affect the WebRTC API etc. >=20 > Now, as I said earlier, the JS app would have to know when the candidates > have been selected. BUT, I think that information could be useful to the = JS > app for other reasons than ICE too. Yup, the other use case is that WebRTC/SIP server uses the selected candida= tes to communicate with the SDN controller to program on-path network devic= es to prioritize the media streams. -Tiru >=20 > Regards, >=20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Oct 16 02:01:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83241A1AE8 for ; Thu, 16 Oct 2014 02:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyPdBWxWgS9d for ; Thu, 16 Oct 2014 02:01:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F911A1AE0 for ; Thu, 16 Oct 2014 02:01:18 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-55-543f895cfbba Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 06.4E.24955.C598F345; Thu, 16 Oct 2014 11:01:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 11:01:16 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP5+NicCZjzEhGnkuH0Ney21PC/JwwuWOQgAAX6ICAAAJCAIAAOI8AgAAu9oCAAADJgIABBy4Q///u6gCAACTyUP//60MAgAAsP3A= Date: Thu, 16 Oct 2014 09:01:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47F159@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> 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.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rje20z7E4NEVFos1OyewWEzfZ2Mx dfljFovJn/pYLWZcmMpscXLnNmYHNo9zDe/ZPZYs+cnk8f9NoMeH+V/YPW5NKfDY3vOYJYAt issmJTUnsyy1SN8ugStj/7XTzAV7OCpuzxBvYFzA0cXIwSEhYCKxdFlZFyMnkCkmceHeerYu Ri4OIYGjjBJ7upYxQjhLGCVeXH/DCtLAJmAh0f1PG6RBRMBG4t+FC+wgNcwChxklmuc/Ygap ERZQl5hyTwGiRkNiwbUvjBB2mcTUBx0sIDaLgKrE+1PTmUFsXgFfiSUtIONBdr1hlTj66Sw7 SIJTIFDi+paVYA2MQNd9P7WGCcRmFhCXuPVkPhPE1QISS/acZ4awRSVePv7HCmErSfzYcIkF 5B5mAU2J9bv0IVoVJaZ0P2SH2CsocXLmE5YJjGKzkEydhdAxC0nHLCQdCxhZVjGKFqcWJ+Wm GxnrpRZlJhcX5+fp5aWWbGIExuDBLb9VdzBefuN4iFGAg1GJh/dBnH2IEGtiWXFl7iFGaQ4W JXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgbJk/b+2t+VEy50pe/psm7N+zv71n tUJNwfb3PvL9F7Zvsp4SGBJ9W6n6h1kRx9SeR3uUJr9Y4TFNsyJQcdGL1j+GB/p3vfiyajJD 9e3LfVvtJsh0lZn59l47NzNdhGOj+7x/T/Oylbb1zpWcOCV2caSc3NLEh/cclRLWl3A/Wren qsP4uuUDSyWW4oxEQy3mouJEAD4x9Q6iAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OP_iNlonUnkL7QlEPStUMKiJ4Xw Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 09:01:21 -0000 SGksDQoNCj4+IE5vdywgYXMgSSBzYWlkIGVhcmxpZXIsIHRoZSBKUyBhcHAgd291bGQgaGF2ZSB0 byBrbm93IHdoZW4gdGhlIGNhbmRpZGF0ZXMgaGF2ZSBiZWVuIHNlbGVjdGVkLiBCVVQsIEkgdGhp bmsgdGhhdCBpbmZvcm1hdGlvbiBjb3VsZCBiZSB1c2VmdWwgdG8gdGhlIEpTIGFwcCBmb3Igb3Ro ZXIgcmVhc29ucyB0aGFuIElDRSB0b28uDQo+DQo+VGhhdCdzIGltcG9zc2libGUgd2l0aCB0aGUg Y3VycmVudCBBUEkgYXMgaXQgaXMgbm90ICJ0cmFuc3BvcnQiLWJhc2VkIGJ1dCAiYWxsLXN0dWZm LXRvZ2V0aGVyIi1iYXNlZCwgd2hpY2ggbWVhbnMgdGhhdCB0aGUgSlMgYXBwbGljYXRpb24gaGFz IG5vIHdheSB0byBrbm93IHRoZSBudW1iZXIgb2YgdHJhbnNwb3J0cyBiZWluZyBuZWdvdGlhdGVk LCBhbmQgaGVuY2UgYW4gQVBJIHRvIHByb3ZpZGUgcGFpcmVkIGNhbmRpZGF0ZXMgaXMgb2YgbGl0 dGxlIHVzZSB3aXRoaW4gV2ViUlRDIDEuMC4NCg0KQWxsIEkgbmVlZCB0byBrbm93IGlzIHRoZSBs b2NhbCBhZGRyZXNzOnBvcnQgdGhhdCBoYXMgYmVlbiBzZWxlY3RlZCwgYW5kIGJhc2VkIG9uIHRo YXQgSSBjYW4gY3JlYXRlIGFuZCBzZW5kIHRoZSB1cGRhdGVkIG9mZmVyLg0KDQpLZWVwIGluIG1p bmQgdGhhdCBCVU5ETEUgYWxzbyBtYW5kYXRlcyBhIHNlY29uZCBvZmZlciAodGhlIEJBUyBvZmZl ciksIHNvIHlvdSdkIG5lZWQgdGhpcyBldmVuIGlmIHlvdSBkb24ndCBuZWVkIHRvIHNlbmQgYSBz ZWNvbmQgb2ZmZXIgZHVlIHRvIElDRS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Thu Oct 16 02:09:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8F41A19E3 for ; Thu, 16 Oct 2014 02:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoF6U2nZUEmu for ; Thu, 16 Oct 2014 02:09:37 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEB31A014F for ; Thu, 16 Oct 2014 02:09:37 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id z60so2238987qgd.1 for ; Thu, 16 Oct 2014 02:09:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=w/MDD5g3Jw2ACF97lxerevwgK21KpQ8Udl53i+kB6XI=; b=X5KCeu2RC5d4u5t/IgNyv195ct4Yrd4UeoZdWg/5Rdj+CyIIZj9L9DhZmGvlveMTmH yk0arP9ZcsXBQx7vpLAR78WmGv4OjhVWfGhq2pciEo1gEhGdSFITIN3Ij5DvEBjw9HRZ 7sayrMO7XBaO457gQspxbGX47MGgItYOfR/R+AbT1eRNr0SwFg6EbW7azpHI6wZzSu8e pBmt1//Y9S4mwtVoH06ogF3/PmVpIvpnwHd3nJtfZbQ+FfETEK6G/JkWRekE1jAadkr8 FGLr4Gtw97Ek7FkRNPptLFqVlGRZdI0M1IL8vqQlEVOytfoe5ngMK2avjS77cywohLWl LDTQ== X-Gm-Message-State: ALoCoQlTYO3n4w1syHysv8F6gYD34JJbcL0mqSrn4c185q+pNx+Y4dAlQgJ18HJ7FTGWjESf7KA8 X-Received: by 10.140.105.164 with SMTP id c33mr22850qgf.11.1413450576487; Thu, 16 Oct 2014 02:09:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Thu, 16 Oct 2014 02:09:16 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47F159@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47F159@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 16 Oct 2014 11:09:16 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3MAqv_JCSXUYs4uEuJdfDe6C3x4 Cc: "mmusic@ietf.org" , Roman Shpount Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 09:09:38 -0000 2014-10-16 11:01 GMT+02:00 Christer Holmberg : >>That's impossible with the current API as it is not "transport"-based but= "all-stuff-together"-based, which means that the JS application has no way= to know the number of transports being negotiated, and hence an API to pro= vide paired candidates is of little use within WebRTC 1.0. > > All I need to know is the local address:port that has been selected, and = based on that I can create and send the updated offer. Your browser may support Bundle but the peer may not. If so, your PeerConnection will establish two (or more) ICE transports thus you need to know the local address:port for each transport (but at the same time you never knew the number of transports in place so...). --=20 I=C3=B1aki Baz Castillo From nobody Thu Oct 16 02:23:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002191A6F9C for ; Thu, 16 Oct 2014 02:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW-EGEkXBzND for ; Thu, 16 Oct 2014 02:23:16 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4E71A0A6B for ; Thu, 16 Oct 2014 02:23:16 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 63D871EB881E; Thu, 16 Oct 2014 11:23:15 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 11:23:14 +0200 From: "Stach, Thomas" To: Christer Holmberg , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP6GJtuF9H8nwjukqj+Vm4R8Q5spwwuWOQgAAX6ICAAAJCAIAAOI8AgAAu9oCAAADJgIABBy4QgAAAuGD///HDgIAAC6YAgAAMBYCAACOQoA== Date: Thu, 16 Oct 2014 09:23:14 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47F159@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47F159@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kOwjCVLbWHaFIMzPrF7Hpk0yQvg Cc: Roman Shpount , "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 09:23:17 -0000 PiANCj4gS2VlcCBpbiBtaW5kIHRoYXQgQlVORExFIGFsc28gbWFuZGF0ZXMgYSBzZWNvbmQgb2Zm ZXIgKHRoZSBCQVMgb2ZmZXIpLCBzbw0KPiB5b3UnZCBuZWVkIHRoaXMgZXZlbiBpZiB5b3UgZG9u J3QgbmVlZCB0byBzZW5kIGEgc2Vjb25kIG9mZmVyIGR1ZSB0byBJQ0UuDQpbVFNdIEJBUyBpcyBi YXNlZCBvbiB0aGUgc2FtZSBhcmd1bWVudHMgYXMgZm9yIHRoZSBJQ0UgdXBkYXRlZCBvZmZlci4N CkFzIHRoaXMgd2lsbCBjYXVzZSBzaW1pbGFyLCBpZiBub3QgdGhlIHNhbWUgaXNzdWVzLCBJJ2Qg cmF0aGVyIGhhbmRsZSBib3RoIGluIHRoZSBzYW1lIHdheS4NCg0KDQo+IA0KPiBSZWdhcmRzLA0K PiANCj4gQ2hyaXN0ZXINCg0K From nobody Thu Oct 16 02:24:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1791A1AB6 for ; Thu, 16 Oct 2014 02:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaH9sKkoYce0 for ; Thu, 16 Oct 2014 02:24:40 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123861A014F for ; Thu, 16 Oct 2014 02:24:39 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-01-543f8ed6b488 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 19.17.21334.6DE8F345; Thu, 16 Oct 2014 11:24:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 11:24:37 +0200 From: Christer Holmberg To: "Stach, Thomas" , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] ICE updated offer Thread-Index: AQHP5+NicCZjzEhGnkuH0Ney21PC/JwwuWOQgAAX6ICAAAJCAIAAOI8AgAAu9oCAAADJgIABBy4Q///u6gCAACTyUP//60MAgAAsP3D//+XqAAAENrqA Date: Thu, 16 Oct 2014 09:24:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47F2A9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47F159@ESESSMB209.ericsson.se> 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.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvje61PvsQg85vohZrdk5gsZi+z8Zi 6vLHLBaTP/WxWsy4MJXZ4uTObcwObB7nGt6zeyxZ8pPJ4/+bQI8P87+we9yaUuCxvecxSwBb FJdNSmpOZllqkb5dAldGz+4LbAW32Cs6e9+zNzAeYO9i5OSQEDCRWLh1JZQtJnHh3nq2LkYu DiGBo4wSK5rfskA4SxgljrfeY+pi5OBgE7CQ6P6nDWKKCGRIHHupC1LCLDCdUaLxyXk2kLiw gLrElHsKIDNFBDQkFlz7wghSIyLQxCix/tUqNpAEi4CqxJVt91lAbF4BX4m3nx9B7frKJjGt bRYzyCBOAX+Juf9EQWoYgY77fmoNE4jNLCAucevJfCaIowUkluw5zwxhi0q8fPyPFcJWkvix 4RILyBhmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjGKzkEydhdAxC0nHLCQdCxhZVjGKFqcW F+emGxnrpRZlJhcX5+fp5aWWbGIERuHBLb91dzCufu14iFGAg1GJh/dBnH2IEGtiWXFl7iFG aQ4WJXHeRefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpglGk7f1VC1EnpxOqprfK39k+s /5P2v8bQ7/OT75Laj76q+Xy+LRYkx2HAEbDW+V2DlSMTj95FTuVnVxOXuedLSfLvnay8V9fn p4pE++eojSWbpzyf+UzUNbHnZnrorm27l0tZeDyaedb99RWBLetWJFVJ7uR+r3i1MP54qPGd urXHVhx32hTaoMRSnJFoqMVcVJwIAM3rFq2jAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kOUsDkuSYX_OrFo15TAnFNav98k Cc: Roman Shpount , "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 09:24:42 -0000 RXZlbiBpZiBtZSB3b3VsZCBtYWtlIHRoZSBCQVMgb3B0aW9uYWwsIG9uZSBzdGlsbCBuZWVkcyB0 byBiZSBhYmxlIHRvIHByb3Blcmx5IGNyZWF0ZSBpdC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFN0YWNoLCBUaG9tYXMgW21haWx0bzp0aG9tYXMuc3RhY2hAdW5pZnkuY29t XSANClNlbnQ6IDE2LiBsb2tha3V1dGEgMjAxNCAxMjoyMw0KVG86IENocmlzdGVyIEhvbG1iZXJn OyBJw7Fha2kgQmF6IENhc3RpbGxvDQpDYzogUGFydGhhc2FyYXRoaSBSOyBFbWlsIEl2b3Y7IG1t dXNpY0BpZXRmLm9yZzsgUm9tYW4gU2hwb3VudA0KU3ViamVjdDogUkU6IFtNTVVTSUNdIElDRSB1 cGRhdGVkIG9mZmVyDQoNCj4gDQo+IEtlZXAgaW4gbWluZCB0aGF0IEJVTkRMRSBhbHNvIG1hbmRh dGVzIGEgc2Vjb25kIG9mZmVyICh0aGUgQkFTIG9mZmVyKSwgDQo+IHNvIHlvdSdkIG5lZWQgdGhp cyBldmVuIGlmIHlvdSBkb24ndCBuZWVkIHRvIHNlbmQgYSBzZWNvbmQgb2ZmZXIgZHVlIHRvIElD RS4NCltUU10gQkFTIGlzIGJhc2VkIG9uIHRoZSBzYW1lIGFyZ3VtZW50cyBhcyBmb3IgdGhlIElD RSB1cGRhdGVkIG9mZmVyLg0KQXMgdGhpcyB3aWxsIGNhdXNlIHNpbWlsYXIsIGlmIG5vdCB0aGUg c2FtZSBpc3N1ZXMsIEknZCByYXRoZXIgaGFuZGxlIGJvdGggaW4gdGhlIHNhbWUgd2F5Lg0KDQoN Cj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KDQo= From nobody Thu Oct 16 04:46:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927341AD0A1 for ; Thu, 16 Oct 2014 04:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwgyR1JBjbd3 for ; Thu, 16 Oct 2014 04:46:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9D21AD0A0 for ; Thu, 16 Oct 2014 04:46:30 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-98-543fb0141ee5 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4B.80.21334.410BF345; Thu, 16 Oct 2014 13:46:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 13:46:28 +0200 From: Christer Holmberg To: Stephen Casner Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments Thread-Index: Ac/n1XBtzTLmfbOlQvSkbOT9iPCTaQA7kBkAABy9V1A= Date: Thu, 16 Oct 2014 11:46:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D47F7DA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D47C8AD@ESESSMB209.ericsson.se> 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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGfG3Rld0g32IwZ1pvBYvVs1hsVj+8gSj xafuDWwW7y/oWkxd/pjFgdXj8hVvjym/N7J6TLt/n81jyZKfTB5fLn9mC2CN4rJJSc3JLEst 0rdL4MrYvaKNseAfR8W/mVeYGhi/snUxcnJICJhI3NvawgJhi0lcuLceKM7FISRwlFFi3sx7 UM4SRolpSz6xdjFycLAJWEh0/9MGaRARUJb40f+VHcRmFnjKKDHrbSGILSwQL/Fs+3cWiJoE iZtXnzGBtIoIWEn8+aAPEmYRUJXY+nErM4jNK+Ar8XLbUxaIVT2MEhfW/WUFSXAKeEqcW9oN digj0HHfT61hgtglLnHryXwmiKMFJJbsOc8MYYtKvHz8jxXCVpT4+GofI0S9jsSC3Z/YIGxt iWULX0MtFpQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMYoWpxYX56YbGeulFmUmFxfn5+nl pZZsYgTG3cEtv3V3MK5+7XiIUYCDUYmH90GcfYgQa2JZcWXuIUZpDhYlcd5F5+YFCwmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamA0in7DyOn+RPtU0bsnHk4tNmLfo9I0Fx3w+SOtYDU1Iblj h1Vowd3kSWx1RX47LefdaM31CVK8w/qtqoFJb7vGPLfzq0PYUl3WlfibW/2qu/HRldcz9/uv Wf9ZtmTvdVCcWX/g9f3Xfx7Z/9qQpv0jymfK06+Xzeelxs1WFp3uLvl3m3OWirISS3FGoqEW c1FxIgCmE+4/nAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/z6uZGYEJMC1cw7eQpqLA2wNqOmY Cc: Flemming Andreasen , "draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org" , Colin Perkins , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 11:46:33 -0000 Hi Stephen, So, I will use "RTCP SDES" terminology. Anything I need to do in order to change the registry title? I guess that c= annot be done as an IANA consideration within the draft, can it? Regards, Christer -----Original Message----- From: Stephen Casner [mailto:casner@acm.org]=20 Sent: 16. lokakuuta 2014 3:02 To: Christer Holmberg Cc: Colin Perkins; Flemming Andreasen; draft-ietf-mmusic-sdp-bundle-negotia= tion@tools.ietf.org; mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 = - Colin's comments On Tue, 14 Oct 2014, Christer Holmberg wrote: > Hi Colin, > > Thanks for your comments! See inline. > > >- Section 1, 7th paragraph: typo "a new RTP SDES item" -> "a new RTCP SD= ES item" > > I actually use "RTP SDES item" and "RTP MID SDES item" terminology in qui= te a few places. > > The reason is because that is what they are called in the IANA registry: > > http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-p= arameters-5 Aha. The registry title should be changed. -- Steve From nobody Thu Oct 16 08:35:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88C01A3BA2; Thu, 16 Oct 2014 08:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDp8hllYMldM; Thu, 16 Oct 2014 08:34:59 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D491A3BA1; Thu, 16 Oct 2014 08:34:59 -0700 (PDT) Received: from auge (75-25-120-141.lightspeed.snvaca.sbcglobal.net [75.25.120.141]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s9GFYsIN028643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Oct 2014 08:34:54 -0700 Date: Thu, 16 Oct 2014 08:34:54 -0700 (PDT) From: Stephen Casner To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D47F7DA@ESESSMB209.ericsson.se> Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D47C8AD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47F7DA@ESESSMB209.ericsson.se> User-Agent: Alpine 2.19.9991 (OSX 64 2014-05-31) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Sonic-CAuth: UmFuZG9tSVYis8a2Hi4H2RO7niZMwy9nmW26HZOXcNCBHpBsE0o1zzeuWuNe+1hDKHPkXG3uj+74L7DYnapRyq7Z1mjwp8B1 X-Sonic-ID: C;OOjY+UlV5BGfm4EG/FJGkA== M;9EQa+klV5BGfm4EG/FJGkA== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8WPJoVvl2KBIlIEqamLv6qj6WWM Cc: Colin Perkins , AVT WG , mmusic Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 15:35:01 -0000 Christer, > So, I will use "RTCP SDES" terminology. Good. > Anything I need to do in order to change the registry title? I guess > that cannot be done as an IANA consideration within the draft, can > it? I agree that this does not belong in the IANA considerations of your draft. Instead, I think the change should just be a direct request to IANA. I note that the immediately preceding registry on the same page is "RTCP Control Packet types (PT)", so that one is correctly named. I also see that in the Note section of the "RTP SDES item types" registry says that the list of item types is "for the RTCP SDES control packet". Thus, I would not expect IANA to object to the change. For the "RTCP Control Packet types (PT)" registry, Magnus and I are listed as experts, but there are no experts listed for the "RTP SDES item types" registry. I could send a message to IANA, but it might be more appropriate for the request to come from the AVTCORE WG, that is, from the current chair. -- Steve > -----Original Message----- > From: Stephen Casner [mailto:casner@acm.org] > Sent: 16. lokakuuta 2014 3:02 > To: Christer Holmberg > Cc: Colin Perkins; Flemming Andreasen; draft-ietf-mmusic-sdp-bundle-negotiation@tools.ietf.org; mmusic > Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments > > On Tue, 14 Oct 2014, Christer Holmberg wrote: > > > Hi Colin, > > > > Thanks for your comments! See inline. > > > > >- Section 1, 7th paragraph: typo "a new RTP SDES item" -> "a new RTCP SDES item" > > > > I actually use "RTP SDES item" and "RTP MID SDES item" terminology in quite a few places. > > > > The reason is because that is what they are called in the IANA registry: > > > > http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-5 > > Aha. The registry title should be changed. > > -- Steve From nobody Thu Oct 16 16:04:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4928C1A8F38 for ; Thu, 16 Oct 2014 16:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4LJSJqZfTt2 for ; Thu, 16 Oct 2014 16:04:13 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9922F1A8F35 for ; Thu, 16 Oct 2014 16:04:13 -0700 (PDT) Received: from userPC (unknown [122.178.210.228]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 389A263978A; Thu, 16 Oct 2014 23:04:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1413500652; bh=tEJ1SiW4+rj4gqpk0uqSVVN4I6KnbODBmEiggA+kkTg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=k+JlUNsKf38KdwWDiiJ+cgowsVW0s19nXC29pCd2WtLoUY3lXiFKGZAS4r4TsS+Db wj9lZE/MTVmM2ZMuwU4TQyL9u9tJYBjtUwEIlcXGl9+AbXNqxu9dCaBBjTDr/NDprh xcIXRPnnkRx0l4ZMbUlhwn0pzwcneC25uDMyBM9k= From: "Parthasarathi R" To: "'Stach, Thomas'" , "'Emil Ivov'" , =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> In-Reply-To: Date: Fri, 17 Oct 2014 04:33:52 +0530 Message-ID: <006301cfe995$7b990ae0$72cb20a0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP6GJtuF9H8nwjukqj+Vm4R8Q5spwxLGYQgAAojICAAOuxkIABFKuA Content-Language: en-us X-CTCH-RefID: str=0001.0A020202.54404EEC.0201, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/F8vp-aMdsJPBpNjDjQ3twwWHBUo Cc: mmusic@ietf.org, 'Roman Shpount' , 'Christer Holmberg' Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 23:04:15 -0000 Hi Thomas, I understand your original statement now. Hope you understand that the = second offer is required to all signaling entity which is controlling = the separate media entity irrespective the protocol (SIP/WebRTC/...) = used.=20 Thanks Partha > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@unify.com] > Sent: Thursday, October 16, 2014 11:48 AM > To: Parthasarathi R; 'Emil Ivov'; 'I=C3=B1aki Baz Castillo' > Cc: mmusic@ietf.org; 'Roman Shpount'; 'Christer Holmberg' > Subject: RE: [MMUSIC] ICE updated offer >=20 > > > > Hi Thomas, > > > > I'm not seeing that the second offer is relevant only to SIP. > [TS] That is not what I said. > For background on my original statement you may want to refer to > http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip- > 01#section-5.4.2 >=20 > > Even in case > > WebRTC entity with (proprietary) signaling & media in the separate > device, > > WebRTC signaling entity will not aware of the actual media IP, port = & > > transport. > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Stach, > > > Thomas > > > Sent: Wednesday, October 15, 2014 7:19 PM > > > To: Emil Ivov; I=C3=B1aki Baz Castillo > > > Cc: mmusic@ietf.org; Roman Shpount; Christer Holmberg > > > Subject: Re: [MMUSIC] ICE updated offer > > > > > > > > > > > > > > > I really don't think browsers have anything to do with this. It is > > > purely a matter of signalling. Nothing needs to be changed for > webrtc > > > one way or another. > > > [TS] I agree. ICE updated offer was introduced to accommodate > certain > > > SIP middleboxes. Its relevance outside of SIP is at least > debatable. > > > > > > --sent from my mobile > > > On 15 Oct 2014 12:18 PM, "I=C3=B1aki Baz Castillo" > wrote: > > > 2014-10-15 8:55 GMT+02:00 Christer Holmberg > > > : > > > > What I suggest has very little impact on ICE as defined today. = It > > > only adds > > > > some kind of indicator (ice-options attribute value?) whether = the > > > second > > > > offer is needed or not. Simple :) > > > > > > And in case the SDP says that the "second offer" is required, then > > > what? I mean, should the browser do samething (I mean natively)? = or > is > > > it just up to the JS application? > > > > > > > > > -- > > > I=C3=B1aki Baz Castillo > > > > > > > > > _______________________________________________ > > > 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 nobody Thu Oct 16 16:24:47 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE151A9007 for ; Thu, 16 Oct 2014 16:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTFKXu1XG1m7 for ; Thu, 16 Oct 2014 16:24:43 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id C61ED1A8F3F for ; Thu, 16 Oct 2014 16:24:42 -0700 (PDT) Received: from userPC (unknown [122.178.210.228]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 08776639AAE; Thu, 16 Oct 2014 23:24:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1413501881; bh=zyBDi5FfGQz63sBCKP65O1HEzv424inAR3hrvn0B2Fs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=X2lu8WhbAE8lKXEJsOD4+ZB1C23Lpbfx77KmYlAXQLgAhadUqvRFNnukInEjwCyFh Hylt5vKzNW0cOZ3STFrk12BUM0y/cs7bC3f13WNEDGKrDGovQN6SxyAAMarskh3PhW IG97lzHNQGM/woh+l+zLd+Fc4XakfhwWSgml+KZE= From: "Parthasarathi R" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Christer Holmberg'" , "'Stach, Thomas'" , =?iso-8859-1?Q?'I=F1aki_Baz_Castillo'?= References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <7594FB04B1934943A5C02806D1A2204B1D47EB9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D47EF43@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A2833D692@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2833D692@xmb-rcd-x10.cisco.com> Date: Fri, 17 Oct 2014 04:54:24 +0530 Message-ID: <006501cfe998$57f3f3e0$07dbdba0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP6GJtuF9H8nwjukqj+Vm4R8Q5spwxLGYQgAAojICAAFtDgIAA5jyAgAAP3QCAAASPgP//vqBggAD1QOA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.544053B9.0165, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/y9duPWGHBF-HWvEOKrIl_2dBPO8 Cc: mmusic@ietf.org, 'Roman Shpount' Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 23:24:45 -0000 Hi Tiru & all, Yup, the other use case is that WebRTC/SIP server uses the selected candidates to communicate with the SDN controller to program on-path = network devices to prioritize the media streams. It is yet another good usecase for the updated offer requirement.=20 Thanks Partha > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: Thursday, October 16, 2014 2:30 PM > To: Christer Holmberg; Stach, Thomas; I=F1aki Baz Castillo; = Parthasarathi > R > Cc: mmusic@ietf.org; Roman Shpount > Subject: RE: [MMUSIC] ICE updated offer >=20 > > -----Original Message----- > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer > > Holmberg > > Sent: Thursday, October 16, 2014 1:07 PM > > To: Stach, Thomas; I=F1aki Baz Castillo; Parthasarathi R > > Cc: mmusic@ietf.org; Roman Shpount > > Subject: Re: [MMUSIC] ICE updated offer > > > > Hi, > > > > >> Obviously the signaling entity needs to be able to control the > media > > >> entity. If that control is based on the SDP information, that SDP > > >> information needs to be correct. > > > [TS] The SDP information is correct and it provides everything = that > the > > media entity needs (via the candidates). > > > Since all connectivity checks follow the media path the media > entity is also > > able to learn the eventually used media IP, port & transport. > > > > That is not how many current deployments work today, and I don't > think we > > should mess those up by fixing something that isn't broken (not > sending the > > second offer is just an optimization). > > > > The request for not sending the second offer came mainly from the > WebRTC > > community. And, as we have noted, the sending of the second offer = can > be > > taken of by the JS app, so it doesn't affect the WebRTC API etc. > > > > Now, as I said earlier, the JS app would have to know when the > candidates > > have been selected. BUT, I think that information could be useful to > the JS > > app for other reasons than ICE too. >=20 > Yup, the other use case is that WebRTC/SIP server uses the selected > candidates to communicate with the SDN controller to program on-path > network devices to prioritize the media streams. >=20 > -Tiru >=20 > > > > Regards, > > > > Christer > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Oct 16 16:37:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAA31A8AA6 for ; Thu, 16 Oct 2014 16:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-iOyH7keIjQ for ; Thu, 16 Oct 2014 16:37:53 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8C50E1A88C7 for ; Thu, 16 Oct 2014 16:37:53 -0700 (PDT) Received: from userPC (unknown [122.178.210.228]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 3410E1908C0E; Thu, 16 Oct 2014 23:37:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1413502673; bh=3O+jU+32a14WhnPNSRv9Y2lZ6LI6MpkrE/WLwGhHIqA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DCZhCUIta+SQz6CyIbVmcfYVrmqeAPdfEc0BjSvN95xnw4mSoaVqlA36Dt5j+0lLX CxQFXl/N9XhZrvTvzLDLIA5tEoN5d6Cn3P3bP59thSrRgBSR1ulackl1xRMoHqTMeO avSjBG8cr90dBd6hj9GVTZxkW0yTwzQ3kmhNPC4c= From: "Parthasarathi R" To: "'Emil Ivov'" , "'Stach, Thomas'" , =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <7594FB04B1934943A5C02806D1A2204B1D47D84C@ESESSMB209.ericsson.se> <004001cfe896$36205220$a260f660$@co.in> <543EA344.5030104@jitsi.org> In-Reply-To: <543EA344.5030104@jitsi.org> Date: Fri, 17 Oct 2014 05:07:35 +0530 Message-ID: <006601cfe99a$2fb3ed70$8f1bc850$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/olpr8+LxxE6YaSVut3PRnqK3ZiABAfpIQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.544056D0.0264, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mYbRdoeBN35ESVEeZaCCWnYpa_Q Cc: mmusic@ietf.org, 'Roman Shpount' , 'Christer Holmberg' Subject: Re: [MMUSIC] ICE updated offer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 16 Oct 2014 23:37:55 -0000 Hi Emil, It is ICE problem w.r.t signaling exchange. In case of normal RTP, SDP m = line port & c line IP will mention where the media flow occur to the = signaling device. In case of SDP with ICE candidate initial offer, it is = not clear where RTP flow occurs. As per the current discussion, there are two well known issues in case = second offer is missing: 1) Separate Signaling device will not be able to properly maintain the = media resource and policy=20 2) On-path network device will not be able to programmed for the given = media flow by WebRTC/SIP server Thanks Partha > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Wednesday, October 15, 2014 10:10 PM > To: Parthasarathi R; 'Stach, Thomas'; 'I=C3=B1aki Baz Castillo' > Cc: mmusic@ietf.org; 'Roman Shpount'; 'Christer Holmberg' > Subject: Re: [MMUSIC] ICE updated offer >=20 >=20 >=20 > On 15.10.14, 18:36, Parthasarathi R wrote: > > Hi Thomas, > > > > I'm not seeing that the second offer is relevant only to SIP. Even = in > case WebRTC entity with (proprietary) signaling & media in the = separate > device, WebRTC signaling entity will not aware of the actual media IP, > port & transport. >=20 > That's not an ICE problem though. It's a WebRTC API problem though and > trying to solve it by triggering new SDPs would be quite daft really. >=20 > Emil >=20 > > Thanks > > Partha > > > >> -----Original Message----- > >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Stach, > >> Thomas > >> Sent: Wednesday, October 15, 2014 7:19 PM > >> To: Emil Ivov; I=C3=B1aki Baz Castillo > >> Cc: mmusic@ietf.org; Roman Shpount; Christer Holmberg > >> Subject: Re: [MMUSIC] ICE updated offer > >> > >> > >> > >> > >> I really don't think browsers have anything to do with this. It is > >> purely a matter of signalling. Nothing needs to be changed for > webrtc > >> one way or another. > >> [TS] I agree. ICE updated offer was introduced to accommodate > certain > >> SIP middleboxes. Its relevance outside of SIP is at least = debatable. > >> > >> --sent from my mobile > >> On 15 Oct 2014 12:18 PM, "I=C3=B1aki Baz Castillo" = wrote: > >> 2014-10-15 8:55 GMT+02:00 Christer Holmberg > >> : > >>> What I suggest has very little impact on ICE as defined today. It > >> only adds > >>> some kind of indicator (ice-options attribute value?) whether the > >> second > >>> offer is needed or not. Simple :) > >> > >> And in case the SDP says that the "second offer" is required, then > >> what? I mean, should the browser do samething (I mean natively)? or > is > >> it just up to the JS application? > >> > >> > >> -- > >> I=C3=B1aki Baz Castillo > >> > >> > >> _______________________________________________ > >> 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 > -- > https://jitsi.org From nobody Fri Oct 17 02:19:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD021ABD39 for ; Fri, 17 Oct 2014 02:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4-Tx35bkX4T for ; Fri, 17 Oct 2014 02:19:34 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C7DB31ABD3A for ; Fri, 17 Oct 2014 02:19:33 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 6C6931EB8928; Fri, 17 Oct 2014 11:19:32 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 11:19:32 +0200 From: "Stach, Thomas" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer - Back to the initial question Thread-Index: AQHP54cGuF9H8nwjukqj+Vm4R8Q5spw0BOTg Date: Fri, 17 Oct 2014 09:19:31 +0000 Message-ID: References: <543CDB90.7050509@ericsson.com> In-Reply-To: <543CDB90.7050509@ericsson.com> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jAiCkmH7T2sFp7njdyJlUG7yWrE Subject: [MMUSIC] ICE updated offer - Back to the initial question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 09:19:35 -0000 All, I don't have the impression Ari's question was aimed to challenge=20 the consensus for option #3 from IETF#90. However, it seems that now the arguments in favor or against=20 the ICE updated offer are going around in circles=20 without addressing Ari's initial question anymore. ---------------------------------- I would like to hear from people, who have issues making the updated o/a=20 optional, how bad the change would be and is there a way we could make=20 this work also in those scenarios? ---------------------------------- Trying make progress on that here is what I think are the 3 proposed remedi= es: Proposal A: Indicate in the ANSWER whether the second offer is needed or no= t.=20 Proposal B: If you need the update, send an offerless re-INVITE with a flag= =20 that suppresses an ICE restart,=20 but triggers the ICE updated offer instead. Proposal C: The signaling entity should inform the media entity about=20 the candidates. The media entity can then learn through the=20 STUN checks which address is eventually used for media. Are there additional proposals or do we want to choose from these? I might be biased, but Proposal A looks more like a=20 4th option - challenging the IETF90 result - than a remedy for option 3. Regards Thomas > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: Dienstag, 14. Oktober 2014 10:15 > To: mmusic > Subject: [MMUSIC] ICE updated offer >=20 > Hi all, >=20 > At the Toronto meeting we discussed whether we should change the > behavior with ICE updated offer. Currently, based on RFC 5245, when ICE > has finished, there is a new offer/answer with the selected candidate, > *if* they are different from the "default candidates", i.e., the ones in > original o/a m- and c-lines. >=20 > Based on the discussion there was strong desire to have an option of not > doing the updated o/a at all by indicating this in the original o/a. On > the other hand, for some, the updated o/a was seen as a requirement for > getting correct behavior from the network in certain scenarios (e.g., > with SIP-aware middle boxes). >=20 > I would like to hear from people, who have issues making the updated o/a > optional, how bad the change would be and is there a way we could make > this work also in those scenarios? >=20 >=20 > Cheers, > Ari >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Oct 17 03:01:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76081AC3B8 for ; Fri, 17 Oct 2014 03:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV-dDpFS9f-o for ; Fri, 17 Oct 2014 03:01:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A1D1AC3B6 for ; Fri, 17 Oct 2014 03:01:24 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-ab-5440e8f2712b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8A.C4.21334.2F8E0445; Fri, 17 Oct 2014 12:01:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 12:01:22 +0200 From: Christer Holmberg To: "Stach, Thomas" , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer - Back to the initial question Thread-Index: AQHP6et7tDzAK3kYo0S8I1kRwnsjT5w0CvkQ Date: Fri, 17 Oct 2014 10:01:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.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.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje6nFw4hBh2ftC2mLn/MYnFy5zZm ByaPJUt+Mnls73nMEsAUxWWTkpqTWZZapG+XwJUxa89MtoK3EhVf+qeyNDC+F+5i5OSQEDCR eLH9IiuELSZx4d56ti5GLg4hgaOMEt/3rWCCcJYwSiw4cZS5i5GDg03AQqL7nzZIXESgmVHi 0JRLbCDdwgLuEosWgDRwAiU8JK5NfM8OYRtJvP74ByzOIqAqcamvhRnE5hXwlThxuo8FxBYS KJBoPrsWrIZTwF/i8LL7YDWMQBd9P7UGLM4sIC5x68l8JohLBSSW7DnPDGGLSrx8/A/qAyWJ FdsvMULU60ncmDqFDcLWlli28DXUXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpx cW66kbFealFmcnFxfp5eXmrJJkZgpBzc8lt3B+Pq146HGAU4GJV4eBUqHEKEWBPLiitzDzFK c7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjUodAbtn+X2GrT1Y0LLyUvX5n yf7nMVVzrk4u3HLdzHZbhDL7iVmnKyfLpPIWbjxzd+WK1v8qPFUPTTacczf3+PqltmeWs6SI ig/HPMdXs9bLvku1533w/dQEyylv/E9vPt2vEnVhbVVj2eSruy53r53y3D4qM19tJ2vz/p9X ZPecr0gMrhSbp8RSnJFoqMVcVJwIANzktnt1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Rx6lw78x32eXz3YGvMzsg6KgJNg Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 10:01:27 -0000 Hi, Whatever decisions are made at the meetings must (or, at least that seem to= be de facto practise) be confirmed on the mailing list. So, it is ok to ch= allenge them (luckily that doesn't happen too often, though - at least not = within the groups where I participate). >Proposal A: Indicate in the ANSWER whether the second offer is needed or n= ot.=20 >Proposal B: If you need the update, send an offerless re-INVITE with a fla= g=20 > that suppresses an ICE restart,=20 > but triggers the ICE updated offer instead. Using SIP terminology (as this mechanism could only be used with SIP anyway= ), the second offer will almost always be send during an early dialog, whil= e the initial INVITE transaction is still ongoing. You cannot send a re-INV= ITE during that time, so it wouldn't work. Sending the re-INVITE once the c= all has been established could prevent early media, and any other informati= on transported on the media plane during the early dialog phase.=20 >Proposal C: The signaling entity should inform the media entity about=20 > the candidates. The media entity can then learn through the=20 > STUN checks which address is eventually used for media. That might work if the media entity is STUN aware (and if the interface/pro= tocol used to control the media entity supports transporting that kind of i= nformation). Often they are not. They are simply used to e.g. enforce bandw= idth (and other network resources) and gating.=20 > Are there additional proposals or do we want to choose from these? One is to keep everything as it is today, as nothing is broken. Nobody has = indicated that as a preference, though. Regards, Christer > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: Dienstag, 14. Oktober 2014 10:15 > To: mmusic > Subject: [MMUSIC] ICE updated offer >=20 > Hi all, >=20 > At the Toronto meeting we discussed whether we should change the=20 > behavior with ICE updated offer. Currently, based on RFC 5245, when=20 > ICE has finished, there is a new offer/answer with the selected=20 > candidate, > *if* they are different from the "default candidates", i.e., the ones=20 > in original o/a m- and c-lines. >=20 > Based on the discussion there was strong desire to have an option of=20 > not doing the updated o/a at all by indicating this in the original=20 > o/a. On the other hand, for some, the updated o/a was seen as a=20 > requirement for getting correct behavior from the network in certain=20 > scenarios (e.g., with SIP-aware middle boxes). >=20 > I would like to hear from people, who have issues making the updated=20 > o/a optional, how bad the change would be and is there a way we could=20 > make this work also in those scenarios? >=20 >=20 > Cheers, > Ari >=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 From nobody Fri Oct 17 03:58:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3730E1AC3D2 for ; Fri, 17 Oct 2014 03:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC-7VBPMdAVK for ; Fri, 17 Oct 2014 03:58:25 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7F23E1AC3D1 for ; Fri, 17 Oct 2014 03:58:25 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 7843C23F060B; Fri, 17 Oct 2014 12:58:24 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 12:58:24 +0200 From: "Stach, Thomas" To: Christer Holmberg , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer - Back to the initial question Thread-Index: AQHP6fFPMGbuqJCOVUmZ6/j1aMyvUJw0F2gg Date: Fri, 17 Oct 2014 10:58:24 +0000 Message-ID: References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/a8a9lmmd6VIadivNxR5nZXMOcrU Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 10:58:26 -0000 >=20 > Hi, >=20 > Whatever decisions are made at the meetings must (or, at least that seem = to > be de facto practise) be confirmed on the mailing list.=20 You're right I also haven't seen an explicit consensus call on the list.=20 But there also wasn't objection against the minutes and they say: "Chair calls consensus on option 3." Maybe the chairs can help where we are wrt to consensus or not consensus.=20 From nobody Fri Oct 17 04:09:05 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A3D1AC3D8 for ; Fri, 17 Oct 2014 04:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q30NeIvyo9SR for ; Fri, 17 Oct 2014 04:09:02 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767601AC3D6 for ; Fri, 17 Oct 2014 04:09:01 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-5a-5440f8cbf453 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5F.A5.04081.BC8F0445; Fri, 17 Oct 2014 13:08:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 13:08:59 +0200 From: Christer Holmberg To: "Stach, Thomas" , =?utf-8?B?QXJpIEtlcsOkbmVu?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer - Back to the initial question Thread-Index: AQHP6et7tDzAK3kYo0S8I1kRwnsjT5w0CvkQ///yNACAACR71w== Date: Fri, 17 Oct 2014 11:08:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D481271@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D481271ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje7pHw4hBvvmm1hMXf6YxeLkzm3M DkweS5b8ZPLY3vOYJYApissmJTUnsyy1SN8ugStj5/dHzAWT1Cr2nnrM3sDYoNrFyMkhIWAi sXzLUnYIW0ziwr31bF2MXBxCAkcZJbbPucYC4SxhlJj08hiQw8HBJmAh0f1PGyQuItDIKHH+ +zpWkG5hAXeJRQtWMIHYIgIeEtcmvmeHsJ0k9r85CVbDIqAqcXj2B7AaXgFfiYfzFjNBLPjO KHFgZSMLSIJTwF9iRtNvsGZGoJO+n1oD1sAsIC7R9GUlK8SpAhJL9pxnhrBFJV4+/scKUZMv sWX3L0aIBYISJ2c+YZnAKDwLSfssJGWzkJTNAvqNWUBTYv0ufYgSRYkp3Q/ZIWwNidY5c9mR xRcwsq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIygg1t+G+xgfPnc8RCjAAejEg+vYoVD iBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGTcValwum7T XP2DeSH9XZf0JYRnBr92mzjnbLJR+z7fkgc2x5aWvX2oMVGPo9fKgX9d0tqXE/fcSbvpHy58 yf9B7LKEOpFJL4Jm9ZzQTg9J2vef/2rX7Jn7D2VNX6L5w/qEn0LJ907n1k9i+qt23/+8OEzF q5RvL5OAvMn0Y082SqpkvvMPlFdiKc5INNRiLipOBAA5qdoBgQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jli_yykKTu-DP5P8hRZeSwF1cJA Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 11:09:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D481271ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIHdhcyBhIGNvbnNlbnN1cyBjYWxsIGZvciAzLCBzbyB0aGUgbWludXRlcyBh cmUgY29ycmVjdC4NCg0KSSBhcG9sb2dpemUgaWYgSSBzaG91bGQgaGF2ZSBjaGFsbGVuZ2VkIHRo ZSBtaW51dGVzLCByYXRoZXIgdGhhbiB3YWl0aW5nIGZvciBhbiBleHBsaWNpdCB2ZXJpZmljYXRp b24gY2FsbCBmcm9tIHRoZSBjaGFpcnMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQg ZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogU3RhY2gsIFRob21hczxtYWlsdG86dGhvbWFzLnN0YWNoQHVuaWZ5LmNvbT4NClNlbnQ6 IOKAjjE3L+KAjjEwL+KAjjIwMTQgMTM6NTgNClRvOiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgQXJpIEtlcsOkbmVuPG1haWx0bzphcmku a2VyYW5lbkBlcmljc3Nvbi5jb20+OyBtbXVzaWM8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJFOiBbTU1VU0lDXSAgSUNFIHVwZGF0ZWQgb2ZmZXIgLSBCYWNrIHRvIHRoZSBpbml0 aWFsIHF1ZXN0aW9uDQoNCj4NCj4gSGksDQo+DQo+IFdoYXRldmVyIGRlY2lzaW9ucyBhcmUgbWFk ZSBhdCB0aGUgbWVldGluZ3MgbXVzdCAob3IsIGF0IGxlYXN0IHRoYXQgc2VlbSB0bw0KPiBiZSBk ZSBmYWN0byBwcmFjdGlzZSkgYmUgY29uZmlybWVkIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQpZb3Un cmUgcmlnaHQgSSBhbHNvIGhhdmVuJ3Qgc2VlbiBhbiBleHBsaWNpdCBjb25zZW5zdXMgY2FsbCBv biB0aGUgbGlzdC4NCkJ1dCB0aGVyZSBhbHNvIHdhc24ndCBvYmplY3Rpb24gYWdhaW5zdCB0aGUg bWludXRlcyBhbmQgdGhleSBzYXk6DQoiQ2hhaXIgY2FsbHMgY29uc2Vuc3VzIG9uIG9wdGlvbiAz LiINCk1heWJlIHRoZSBjaGFpcnMgY2FuIGhlbHAgd2hlcmUgd2UgYXJlIHdydCB0byBjb25zZW5z dXMgb3Igbm90IGNvbnNlbnN1cy4NCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D481271ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SGksPGJyPg0KPGJyPg0KVGhlcmUgd2Fz IGEgY29uc2Vuc3VzIGNhbGwgZm9yIDMsIHNvIHRoZSBtaW51dGVzIGFyZSBjb3JyZWN0Ljxicj4N Cjxicj4NCkkgYXBvbG9naXplIGlmIEkgc2hvdWxkIGhhdmUgY2hhbGxlbmdlZCB0aGUgbWludXRl cywgcmF0aGVyIHRoYW4gd2FpdGluZyBmb3IgYW4gZXhwbGljaXQgdmVyaWZpY2F0aW9uIGNhbGwg ZnJvbSB0aGUgY2hhaXJzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8 YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxocj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5Gcm9tOg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0 Ij48YSBocmVmPSJtYWlsdG86dGhvbWFzLnN0YWNoQHVuaWZ5LmNvbSI+U3RhY2gsIFRob21hczwv YT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJp ZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPuKA jjE3L+KAjjEwL+KAjjIwMTQgMTM6NTg8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQi PlRvOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIj5DaHJpc3RlciBIb2xtYmVyZzwvYT47DQo8YSBocmVmPSJtYWlsdG86YXJpLmtlcmFu ZW5AZXJpY3Nzb24uY29tIj5BcmkgS2Vyw6RuZW48L2E+OyA8YSBocmVmPSJtYWlsdG86bW11c2lj QGlldGYub3JnIj4NCm1tdXNpYzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQi PlN1YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZjsgZm9udC1zaXplOjExcHQiPlJFOiBbTU1VU0lDXSZuYnNwOyBJQ0UgdXBkYXRlZCBvZmZl ciAtIEJhY2sgdG8gdGhlIGluaXRpYWwgcXVlc3Rpb248L3NwYW4+PGJyPg0KPGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPg0K PGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij4mZ3Q7IDxicj4NCiZndDsgSGksPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFdoYXRldmVyIGRlY2lzaW9ucyBhcmUgbWFkZSBhdCB0aGUgbWVldGluZ3MgbXVzdCAo b3IsIGF0IGxlYXN0IHRoYXQgc2VlbSB0bzxicj4NCiZndDsgYmUgZGUgZmFjdG8gcHJhY3Rpc2Up IGJlIGNvbmZpcm1lZCBvbiB0aGUgbWFpbGluZyBsaXN0LiA8YnI+DQpZb3UncmUgcmlnaHQgSSBh bHNvIGhhdmVuJ3Qgc2VlbiBhbiBleHBsaWNpdCBjb25zZW5zdXMgY2FsbCBvbiB0aGUgbGlzdC4g PGJyPg0KQnV0IHRoZXJlIGFsc28gd2Fzbid0IG9iamVjdGlvbiBhZ2FpbnN0IHRoZSBtaW51dGVz IGFuZCB0aGV5IHNheTo8YnI+DQomcXVvdDtDaGFpciBjYWxscyBjb25zZW5zdXMgb24gb3B0aW9u IDMuJnF1b3Q7PGJyPg0KTWF5YmUgdGhlIGNoYWlycyBjYW4gaGVscCB3aGVyZSB3ZSBhcmUgd3J0 IHRvIGNvbnNlbnN1cyBvciBub3QgY29uc2Vuc3VzLiA8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvc3Bh bj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D481271ESESSMB209erics_-- From nobody Fri Oct 17 05:29:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA711ACD3F for ; Fri, 17 Oct 2014 05:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3HLtxVqGwBo for ; Fri, 17 Oct 2014 05:29:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2973F1ACD43 for ; Fri, 17 Oct 2014 05:29:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141017122928.12618.89585.idtracker@ietfa.amsl.com> Date: Fri, 17 Oct 2014 05:29:28 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/BWPRxKiLl5_VA8QkgMrIhIaobLk Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 12:29:32 -0000 Changed milestone "Submit RTSP NAT considerations draft as a Proposed Standard", resolved as "Done". Changed milestone "Submit SDP considerations for G.723 Annex A and G.729 Annex B as Proposed Standard", resolved as "Done". Changed milestone "Submit a document describing current practices in hosted NAT traversal as Informational", resolved as "Done". Changed milestone "Submit UDPTL over DTLS as Proposed Standard", resolved as "Done". Changed milestone "Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard", set due date to November 2014 from April 2014. Changed milestone "Submit SDP extension for cross session stream identification as Proposed Standard", set due date to December 2014 from May 2014. Changed milestone "Submit a framework for SDP attributes when multiplexing as Proposed Standard", set due date to December 2014 from May 2014. Changed milestone "Submit SCTP-Based Media Transport in SDP as Proposed Standard.", set due date to January 2015 from December 2013. Changed milestone "Submit Trickle ICE as Proposed Standard", set due date to January 2015 from April 2014. Changed milestone "Submit SIP usage for Trickle ICE as Proposed Standard", set due date to February 2015 from April 2014, added draft-ietf-mmusic-trickle-ice-sip to milestone. Changed milestone "Submit SDP extensions to classify traffic as Proposed Standard", set due date to March 2015 from March 2014. Changed milestone "Submit revised SDP specification to IETF as Proposed Standard", set due date to March 2015 from June 2014. Changed milestone "Submit a revision of ICE (RFC 5245) as Proposed Standard", set due date to April 2015 from May 2014. URL: http://datatracker.ietf.org/wg/mmusic/charter/ From nobody Fri Oct 17 14:02:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1847A1A7016 for ; Fri, 17 Oct 2014 14:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POgzIUL5h6xp for ; Fri, 17 Oct 2014 14:02:03 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20F71A7017 for ; Fri, 17 Oct 2014 14:02:01 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-08v.sys.comcast.net with comcast id 4M0i1p00354zqzk01M21xt; Fri, 17 Oct 2014 21:02:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id 4M201p00S3Ge9ey01M20ZB; Fri, 17 Oct 2014 21:02:01 +0000 Message-ID: <544183C8.1070205@alum.mit.edu> Date: Fri, 17 Oct 2014 17:02:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Christer.Holmberg@ericsson.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413579721; bh=2JrHNg6M5i3EwturVzwfOvF0bMGMXkvBMiybKHfqVS8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EjQoptsIwn/3/bAbVldRe2SDifZ23EwBeL3Yl6SZ5auQykHzYg5jeUR1dRfz14oBu 5mTxBLx6UeJAgu7FXMOM+FTk6tideJDOc4sarOI8abMfSgGd5mtn7nSdeoS0gQbQpL S9gABbMz5CUQm+XVn1L6e5k+T08wOxhuiC8alvsGbVFZdpjzlh5zr1+5DXnRUoZ8NX Q8aQSlQ+boUoWNwzIQTYqQW7buf2vwtBHT8O1HSX8DrB1VgtzKjMfF91MHZ/ociWrX YDBUOih3abB102g321Gcjz03xv1LalidW4OuNEBE2Bl/JJliPNgfuKIkTJriWWgBLT UlAj5ZhFT3g9g== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Oz_B6E7t6yv5Ik2eafgkOmo3B0s Cc: IETF MMUSIC WG Subject: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 17 Oct 2014 21:02:07 -0000 I just did a fairly careful WGLC review of draft-ietf-mmusic-sdp-bundle-negotiation-12. I have quite a lot of comments, but most of them are editorial. (Note: others have commented on RTP/RTCP extension issues. I won't comment on those.) * Abstract: The following language is a little awkward: Both endpoints can negotiate the use of bundle and to support that negotiations, this specification ... How about the following: To assist endpoints in negotiating the use of bundle this specification ... In the same paragraph, s/allows/allow/ * Section 1: Introduction: In the third paragraph is: The BUNDLE address is used to send and receive all media associated with the BUNDLE group. In the above, s/address is/addresses are/ The 6th paragraph says: This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 [RFC3264]. The update allows an answerer to assign a non-zero port value to an "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer contained a zero port value. The statement of the update is overly broad, because it doesn't state that the relaxation on answering with a non-zero port only applies within a bundle. I suggest the following: This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 [RFC3264]. The update allows an answerer to assign a non-zero port value to a bundled "m=" line in an SDP answer, even if the "m=" line in the associated SDP offer contained a zero port value. * Section 2: Terminology In the following: BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer exchange, for which each endpoint uses a single 5-tuple to send and receive media. Each endpoint uses its BUNDLE address, associated with the BUNDLE group, to send and receive the media. are we *requiring* symmetric media usage? Certainly you must *receive* on your bundle address, but AFAIK *sending* on that address is, in general, optional though various options that might be used with it (such as ICE) may require it. * Section 6: SDP 'bundle-only' Attribute I would like to see the definition follow the new style introduced in draft-ietf-mmusic-rfc4566bis-12. This draft is nearer to completion to that one, and there is some risk that the new style will be revised in that draft. I don't propose to hold this draft up for that one - there should not be any formal dependency. * Section 7.3: Bandwidth Says: The total proposed bandwidth for a BUNDLE group is the sum of the proposed bandwidth for each bundled "m=" line. What if some of the bundled m-lines have no b= line, while others do? It probably doesn't make sense to treat them as having zero bandwidth. I guess maybe some default value should be used. But what? Or, I guess there could be a rule that if any of the bundled m-lines have b= then all of them must. Also, I guess there needs to be a separate sum for each bandwidth type. Note: this is also an issue for draft-ietf-mmusic-sdp-mux-attributes. I note that section 7.3 defers to draft-ietf-mmusic-sdp-mux-attributes for attribute bundling rules. Perhaps this section should similarly defer to that draft for bandwidth bundling. * Section 8.2.1: Generating the Initial SDP Offer: General The use of "assign" in the second bullet item seems inappropriate: o Assign an SDP 'group:BUNDLE' attribute to the offer; I suggest instead: o Add a new SDP 'group:BUNDLE' attribute to the offer for the new BUNDLE group; * Section 8.2.2: Request offerer BUNDLE address selection I think the name of this section is slightly confusing - "Request" could be a verb (intended) or a noun. I suggest changing it to: "Suggesting an offerer BUNDLE address" * Section 8.3.2: Answerer Selection of Offerer Bundle Address I have a few wording changes to suggest for clarity: In this section, the use of 'the "m=" line' seems a little vague. I think it would be better to change it to 'that "m=" line' throughout. Also - s/fulfils/fulfills/ - s/criteria above is fulfilled/criteria above are fulfilled/ - s/criteria is not fulfilled/criteria are not fulfilled/ - s/represents/identifies/ * Section 8.4.1: Offerer Processing of the SDP Answer: General In the following: When an offerer receives an answer, if the answer contains a BUNDLE group, the offerer MUST check that any bundled "m=" line in the answer was indicated as bundled in the associated offer. If there is no mismatch, the offerer MUST apply the offerer BUNDLE address, selected by the answerer [Section 8.3.2], to each bundled "m=" line. the use of the word "apply" is a little unclear. While the intent can be inferred, it isn't defined anywhere, or used in this way anywhere else. I suggest it could be written as: ... the offerer MUST use the offerer BUNDLE address, selected by the answerer [Section 8.3.2], as the address for each bundled "m=" line. * Section 9.2: STUN, DTLS, SRTP In the first paragraph, s/offer or answerer/offerer or answerer/ Replace the following: ... If an offer or answerer in offers or answers include bundled "m=" lines that represent these protocols, the offerer or answerer MUST support ... with: ... If an offer or answer includes bundled "m=" lines that represent these protocols, the offerer or answerer MUST support ... Another thing: I *think* that *plain* RTP can also coexist with STUN, DTLS, and SRTP using the rules of RFC5764. (Can somebody confirm if this is true?) Also, there is *no* mention of SCTP in this document. ISTM that there should be something. I guess the 2nd paragraph here is intended to cover that. If so, it is too subtle. IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't use DTLS payload packets. So *one* m-line with a protocol that uses DTLS payload packets (e.g., DTLS/SCTP) can coexist with STUN and SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines. * Section 10.1.1: Single RTP Session: General The second bullet: o The "proto" value in each bundled "m=" line MUST be identical (e.g. RTP/AVPF). should only apply to RTP m-lines. E.g.: o The "proto" value in each bundled RTP-based "m=" line MUST be identical (e.g. RTP/AVPF). * 10.3.2.2: Generating the Initial SDP Offer Similar comment to the previous one: s/each bundled "m=" line/each bundled RTP-based "m=" line/ (It occurs twice in the paragraph.) * 10.3.2.3: Generating the SDP Answer My comment for 10.3.2.2 applies here as well. The MUST NOT in the 2nd paragraph concerns me: If the answerer accepts usage of RTP/RTCP multiplexing within the BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each bundled "m=" line in the answer. The answerer MUST NOT assign an SDP 'rtcp' attribute to any bundled "m=" line in the answer. The answerer will use the port number of the selected offerer BUNDLE address for sending RTP and RTCP packets associated with each bundled "m=" line towards the offerer. I don't understand why the rtcp attribute MUST NOT be used. I understand that the port from the offer is used by the answerer to send RTCP. But without the attribute there is no explicit indication of where the offerer is to send RTCP. What is wrong with including the rtcp attribute in the answer??? Also, in general (ignoring bundle), isn't it valid to use the 'rtcp' attribute without the 'rtcp-mux'? (I thought it was invented for cases where NATs prevented getting an even/odd pair of ports.) So in bundle, shouldn't it also be valid to use the 'rtcp' attribute without the 'rtcp-mux' attribute? (Identical in all m-lines.) * Section 12: Update to RFC 3264 The way in which the changes are presented are great for somebody who is not familiar with 3264 and is truly reading this instead. (Or for somebody who is authoring 3264bis.) But it is quite difficult to understand what the differences are between the two. I had to copy the text out into separate old and new files and then diff them to clearly understand what has changed. I'd appreciate some sort of diff that highlights the fundamental distinctions. (But I'm not sure what kind would be clear and work with the constraints of a draft.) * Section 12.5: New text replacing section 8.2 (2nd paragraph) I take issue with one change here - the addition of "(like the offer)". I don't know if you intend it that way, but to me it seems to suggest that you can only omit attributes if they were omitted in the offer. So I think that particular part of the change should be removed. * Section 16: Examples The ordering of fields in the examples in not valid according to the rules of 4566. It requires "c=", "b=", "a=" in that order. * Section 16.3 I gather that this example is intended to continue on from the the example in 16.1. It would be helpful to say that. * Section 16.4 I gather that this example is intended to continue on from the the example in 16.3. It would be helpful to say that. * Section 16.5 I gather that this example is intended to continue on from the the example in 16.3. It would be helpful to say that. THE END Thanks, Paul From nobody Fri Oct 17 15:28:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CDD1A1BAC for ; Fri, 17 Oct 2014 15:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl0yWjZo8xg2 for ; Fri, 17 Oct 2014 15:28:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF5E1A1BB9 for ; Fri, 17 Oct 2014 15:28:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141017222826.30724.11722.idtracker@ietfa.amsl.com> Date: Fri, 17 Oct 2014 15:28:26 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-lP5axOFWo8C8Ra7E7rocA6paOA Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:28:28 -0000 Changed milestone "Submit Dual-stack Fairness with ICE as Proposed Standard ", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/mmusic/charter/ From nobody Sat Oct 18 12:51:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688321A01E5 for ; Sat, 18 Oct 2014 12:51:51 -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=[BAYES_50=0.8, GB_SUMOF=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yfjiE8BhjzN for ; Sat, 18 Oct 2014 12:51:48 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D681A020B for ; Sat, 18 Oct 2014 12:51:47 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-30-5442c4d00343 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E2.6C.04387.0D4C2445; Sat, 18 Oct 2014 21:51:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Sat, 18 Oct 2014 21:51:44 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments Thread-Index: Ac/quUI/xECKSzhxQBSQKARMMFph+A== Date: Sat, 18 Oct 2014 19:51:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje7FI04hBh8f8lpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGilMz2Aq+plV8nLmGvYHxcEAXIweHhICJ xLsZZV2MnECmmMSFe+vZuhi5OIQEjjJKTD7yEspZwihxY/4HJpAGNgELie5/2iCmiICGxKSt aiC9zAIqEq9OX2YFCQsLxEpsWl0OEhYRiJOYuvoJM4StJ3Hr8GE2EJtFQFVi9eql7CA2r4Cv xIXW5UwgNiPQCd9PrWGCGCkucevJfCaI0wQkluw5zwxhi0q8fPyPFcJWklh7eDsLRL2OxILd n9ggbG2JZQtfM0PMF5Q4OfMJywRGkVlIxs5C0jILScssJC0LGFlWMYoWpxYX56YbGemlFmUm Fxfn5+nlpZZsYgRGwsEtv612MB587niIUYCDUYmHd8FJxxAh1sSy4srcQ4zSHCxK4rwLz80L FhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDIx6n+/WaaxIlyr5KwBc/9SmLuGb6VeO9q0yC4 9bn6FG+5FPt9c9vmBu77JhDjV+yvK+3ztNZrffyP6gv2h9el/T2b6ef3LSUoru/VQTX9q2vE pS5LymZf2WuSOaG27PQuJjVt4cVfN6s2nzwgGl6366zXqui3VQcP/4qy23H6Nef5elvrX3uV WIozEg21mIuKEwHAuLiKZQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TGEFI-VuZrC84IAz9632nEpX7Jw Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 18 Oct 2014 19:51:51 -0000 Hi Paul, Thanks for your review! See inline. ------------------------- >*< Abstract: > >The following language is a little awkward: > > Both endpoints can negotiate the use of bundle and to support that > negotiations, this specification ... > >How about the following: > > To assist endpoints in negotiating the use of bundle this > specification ... OK. > In the same paragraph, s/allows/allow/ OK. ------------------------- >* Section 1: Introduction: > >In the third paragraph is: > > The BUNDLE address is used to send and receive > all media associated with the BUNDLE group. > >In the above, s/address is/addresses are/ OK. ------------------------- >The 6th paragraph says: > > This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 > [RFC3264]. The update allows an answerer to assign a non-zero port > value to an "m=3D" line in an SDP answer, even if the "m=3D" line in t= he > associated SDP offer contained a zero port value. > >The statement of the update is overly broad, because it doesn't state that= the relaxation on answering with a non-zero port only applies within a bun= dle. I suggest the following: > > This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 > [RFC3264]. The update allows an answerer to assign a non-zero port > value to a bundled "m=3D" line in an SDP answer, even if the "m=3D" li= ne > in the associated SDP offer contained a zero port value. I can do that change, but keep in mind that the new RFC 3264 text does not = talk about BUNDLE, but more generically say that an extension can define ne= w semantics for a port zero value in an offer. ------------------------- >* Section 2: Terminology > >In the following: > > BUNDLE group: A set of "m=3D" lines, created using an SDP Offer/Answer > exchange, for which each endpoint uses a single 5-tuple to send and > receive media. Each endpoint uses its BUNDLE address, associated > with the BUNDLE group, to send and receive the media. > > are we *requiring* symmetric media usage? Certainly you must *receive* on= your bundle address, but AFAIK *sending* on that address is, in general, o= ptional though various options that > might be used with it (such as ICE) m= ay require it. The definition of "BUNDLE address" states that the address is used for both= sending and receiving media. ------------------------- >* Section 6: SDP 'bundle-only' Attribute > >I would like to see the definition follow the new style introduced in draf= t-ietf-mmusic-rfc4566bis-12. This draft is nearer to completion to that one= , and there is some risk that the new style >will be revised in that draft.= I don't propose to hold this draft up for that one - there should not be a= ny formal dependency. I'll look into that. One comment, that I will provide in a separate e-mail, I have on the new st= yle is that it should define (or, at least refer to) the Offer/Answer proce= dures for the attribute. ------------------------- >* Section 7.3: Bandwidth > >Says: > > The total proposed bandwidth for a BUNDLE group is the sum of the > proposed bandwidth for each bundled "m=3D" line. > >What if some of the bundled m-lines have no b=3D line, while others do? It= probably doesn't make sense to treat them as having zero bandwidth. I gues= s maybe some default value should be >used. But what? You do whatever you'd do for a non-BUNDLED "m=3D" line. Normally I guess yo= u have a default value, or a value based on the media type and/or payload f= ormats. >Or, I guess there could be a rule that if any of the bundled m-lines have = b=3D then all of them must. > >Also, I guess there needs to be a separate sum for each bandwidth type. > >Note: this is also an issue for draft-ietf-mmusic-sdp-mux-attributes. > >I note that section 7.3 defers to draft-ietf-mmusic-sdp-mux-attributes >for attribute bundling rules.=20 I assume you mean section 7.4? >Perhaps this section should similarly defer to that draft for bandwidth bu= ndling. The "b=3D" parameter is not covered by that draft (as it's not an SDP attri= bute). ------------------------- >* Section 8.2.1: Generating the Initial SDP Offer: General > >The use of "assign" in the second bullet item seems inappropriate: > > o Assign an SDP 'group:BUNDLE' attribute to the offer; > >I suggest instead: > > o Add a new SDP 'group:BUNDLE' attribute to the offer > for the new BUNDLE group; OK. ------------------------- >* Section 8.2.2: Request offerer BUNDLE address selection > >I think the name of this section is slightly confusing - "Request" could b= e a verb (intended) or a noun. I suggest changing it to: > >"Suggesting an offerer BUNDLE address" I use "Request" in other places (e.g. "offerer requested the BUNDLE group")= so I'd like to keep the text. In addition, aren't you the one who suggested "Request" terminology in the = past? :) ------------------------- >* Section 8.3.2: Answerer Selection of Offerer Bundle Address > >I have a few wording changes to suggest for clarity: > >In this section, the use of 'the "m=3D" line' seems a little vague. I thin= k it would be better to change it to 'that "m=3D" line' throughout. I do agree that we could use the following modified sentence: "The answerer MUST check whether that "m=3D" line fulfils the following cr= iteria:" But, after that, I think all instances of 'the' refers to that 'that' :) >Also >- s/fulfils/fulfills/ >- s/criteria above is fulfilled/criteria above are fulfilled/ >- s/criteria is not fulfilled/criteria are not fulfilled/ >- s/represents/identifies/ OK. ------------------------- >* Section 8.4.1: Offerer Processing of the SDP Answer: General > >In the following: > > When an offerer receives an answer, if the answer contains a BUNDLE > group, the offerer MUST check that any bundled "m=3D" line in the > answer was indicated as bundled in the associated offer. If there is > no mismatch, the offerer MUST apply the offerer BUNDLE address, > selected by the answerer [Section 8.3.2], to each bundled "m=3D" line. > > the use of the word "apply" is a little unclear. While the intent can be = inferred, it isn't defined anywhere, or used in this way anywhere else.=20 >I suggest it could be written as: > > ... the offerer MUST use the offerer BUNDLE address, selected by > the answerer [Section 8.3.2], as the address for each bundled > "m=3D" line. OK. ------------------------- >* Section 9.2: STUN, DTLS, SRTP > >In the first paragraph, s/offer or answerer/offerer or answerer/ OK. >Replace the following: > > ... If an offer or answerer in offers or answers include > bundled "m=3D" lines that represent these protocols, the offerer or > answerer MUST support ... > >with: > > ... If an offer or answer includes bundled "m=3D" lines that represent > these protocols, the offerer or answerer MUST support ... OK. >Another thing: I *think* that *plain* RTP can also coexist with STUN, DTLS= , and SRTP using the rules of RFC5764. (Can somebody confirm if this is tru= e?) I'll ask Colin. >Also, there is *no* mention of SCTP in this document. ISTM that there shou= ld be something. I guess the 2nd paragraph here is intended to cover that. = If so, it is too subtle. The document does not cover SCTP - unless it is transported on top of DTLS,= in which case it is implicitly covered by the 2nd paragraph. What would you like to mention about SCTP? >IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't use DTLS= payload packets. So *one* m-line with a protocol that uses DTLS payload pa= ckets (e.g., >DTLS/SCTP) can coexist with STUN and SRTP. If there is more t= han one such m-line then some other specification is required to associate = those packets with m-lines. I think that is covered, as SRTP is distinguished from DTLS. But, if you think that needs to be more clear, maybe the following modified= sentence: "[RFC5764] does not describe how to identify different protocols transport= ed on DTLS (i.e. using DTLS payload packets), only how to..." ------------------------- >* Section 10.1.1: Single RTP Session: General > >The second bullet: > > o The "proto" value in each bundled "m=3D" line MUST be identical > (e.g. RTP/AVPF). > >should only apply to RTP m-lines. E.g.: > > o The "proto" value in each bundled RTP-based "m=3D" line MUST be > identical (e.g. RTP/AVPF). OK. ------------------------- >* 10.3.2.2: Generating the Initial SDP Offer > >Similar comment to the previous one: > > s/each bundled "m=3D" line/each bundled RTP-based "m=3D" line/ > >(It occurs twice in the paragraph.) OK. ------------------------- >* 10.3.2.3: Generating the SDP Answer > >My comment for 10.3.2.2 applies here as well. OK. >The MUST NOT in the 2nd paragraph concerns me: > > If the answerer accepts usage of RTP/RTCP multiplexing within the > BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each > bundled "m=3D" line in the answer. The answerer MUST NOT assign an SD= P > 'rtcp' attribute to any bundled "m=3D" line in the answer. The > answerer will use the port number of the selected offerer BUNDLE > address for sending RTP and RTCP packets associated with each bundled > "m=3D" line towards the offerer. > >I don't understand why the rtcp attribute MUST NOT be used. I understand t= hat the port from the offer is=20 >used by the answerer to send RTCP. But without the attribute there is no e= xplicit indication of where the=20 >offerer is to send RTCP. What is wrong with including the rtcp attribute i= n the answer??? > >Also, in general (ignoring bundle), isn't it valid to use the 'rtcp' attri= bute without the 'rtcp-mux'? (I thought=20 >it was invented for cases where NATs prevented getting an even/odd pair of= ports.) So in bundle, shouldn't=20 >it also be valid to use the 'rtcp' attribute without the 'rtcp-mux' attrib= ute? (Identical in all m-lines.) The reason we don't allow 'rtcp' in the answer (even if RTP/RTCP multiplexi= ng is not used) is because in the offer we only allow the value of the "m= =3D" line (i.e. the value used for RTP) for 'rtcp'.=20 So, either multiplexing is used, or port+1 is used. If we'd change that, we= should also allow the offerer to assign whatever value it wants to the 'rt= cp' attribute... ------------------------- >* Section 12: Update to RFC 3264 > >The way in which the changes are presented are great for somebody who is n= ot familiar with 3264 and is truly reading this instead. (Or for somebody w= ho is authoring >3264bis.) But it is quite difficult to understand what the= differences are between the two. I had to copy the text out into separate = old and new files and then diff them to >clearly understand what has change= d. > >I'd appreciate some sort of diff that highlights the fundamental distincti= ons. (But I'm not sure what kind would be clear and work with the constrain= ts of a draft.) The Introduction states that the change is related to the usage of port zer= o, so having that information I think it is not that difficult to see what = has been changed. Also, my experience from the IESG reviews is that there are always differen= t suggestions on how to update text. So, I'd prefer to keep it as it is, be= cause it may still come up as part of the IESG review. ------------------------- >* Section 12.5: New text replacing section 8.2 (2nd paragraph) > >I take issue with one change here - the addition of "(like the offer)".=20 >I don't know if you intend it that way, but to me it seems to suggest that= you can only omit attributes if they were omitted in the offer. > >So I think that particular part of the change should be removed. The intention is not to indicate that one can only omit attributes if they = were omitted in the offer. I am ok to remove "(like the offer)". ------------------------- >* Section 16: Examples > >The ordering of fields in the examples in not valid according to the rules= of 4566. It requires "c=3D", "b=3D", "a=3D" in that order. OK. The examples were provided by Harald, so I hope they are not based on a Chr= ome trace ;) ------------------------- >* Section 16.3 > >I gather that this example is intended to continue on from the the example= in 16.1. It would be helpful to say that. OK. ------------------------- >* Section 16.4 > >I gather that this example is intended to continue on from the the example= in 16.3. It would be helpful to say that. OK. ------------------------- >* Section 16.5 > >I gather that this example is intended to continue on from the the example= in 16.3. It would be helpful to say that. OK. ------------------------- Thanks! Regards, Christer From nobody Sun Oct 19 16:49:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67FD1A1A42 for ; Sun, 19 Oct 2014 16:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yktpr0Y0hUjC for ; Sun, 19 Oct 2014 16:49:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FFE1A1A39 for ; Sun, 19 Oct 2014 16:49:50 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-6e-54444e1cc4d7 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.A1.24955.C1E44445; Mon, 20 Oct 2014 01:49:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 01:49:48 +0200 From: Christer Holmberg To: IETF MMUSIC WG Thread-Topic: SDP Directorate Review: New SDP attribute sections in rfc4566bis Thread-Index: Ac/r90f99G+9E6sCTjqmqeYmTBonlQ== Date: Sun, 19 Oct 2014 23:49:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4AF4E7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4AF4E7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja6Mn0uIwev/phZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRNXcBa8EitYqN55+wNTB+UOxi5OSQEDCR mLHyJBOELSZx4d56ti5GLg4hgaOMEh0X/7JCOEsYJZac/cPSxcjBwSZgIdH9TxukQURAReLf uwdsIDazgLHEjc3XWEBsYQFPiTsTV7BD1ARIPOy4AWXrSWx+/5oVxGYRUJU4cfozWD2vgK/E 6lMQvYxAR3w/tYYJYqa4xK0n86GOE5BYsuc8M4QtKvHy8T9WCFtJYsX2S4wgpzEL5Ets2lwG MVJQ4uTMJywTGIVnIZk0C6FqFpIqiBIdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFq cVJuupGxXmpRZnJxcX6eXl5qySZGYOwc3PJbdQfj5TeOhxgFOBiVeHgXdDuHCLEmlhVX5h5i lOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxt4A5sS66UnCYabP85a7ud5R frPvX9/8RV33DdTVRAKZl7QULTvu/srpmPwHxWuxb2/45Uxv2bPSMnzjgaly08ykzssrRHmv sJ8hFSR/srBzgc8Fc/9Jd7zLJx2yqF4ltF7T7qcEk4bFuqPybLVmWXWLwxzy9qjlv/J/5MTT dlTpzOXDmRJ3lFiKMxINtZiLihMBOt76HH4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QhmlxfoaOflxvuDtvTpWQCaqYDs Cc: "pkyzivat@alum.mit.edu" Subject: [MMUSIC] SDP Directorate Review: New SDP attribute sections in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2014 23:49:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4AF4E7ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am performing an SDP directorate review of the SDP attribute sections (6 = and 8.2.4) of draft-ietf-mmusic-rfc4566bis-12. A couple of high level principle issues that needs to be discussed. Offer/Answer considerations: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Normally, when we define new SDP attributes, we are also supposed to define= the associated Offer/Answer procedures (following the rules in RFC 3264). However, the O/A procedures are missing from the attributes defined in the = draft, nor is it anywhere said that they must be defined for new attributes= . BUNDLE considerations: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Should we mandate to indicate which "category" [draft-ietf-mmusic-sdp-mux-a= ttributes] an attribute is associated with. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4AF4E7ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am performing an SDP directorate review of the SDP= attribute sections (6 and 8.2.4) of draft-ietf-mmusic-rfc4566bis-12.

 

A couple of high level principle issues that needs t= o be discussed.

 

 

Offer/Answer considerations:

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

 

Normally, when we define new SDP attributes, we are = also supposed to define the associated Offer/Answer procedures (following t= he rules in RFC 3264).

 

However, the O/A procedures are missing from the att= ributes defined in the draft, nor is it anywhere said that they must be def= ined for new attributes.

 

 

BUNDLE considerations:

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

 

Should we mandate to indicate which “category&= #8221; [draft-ietf-mmusic-sdp-mux-attributes] an attribute is associated wi= th.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D4AF4E7ESESSMB209erics_-- From nobody Sun Oct 19 20:24:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F531A1BCD for ; Sun, 19 Oct 2014 20:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JULE_pM-1cu for ; Sun, 19 Oct 2014 20:24:16 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61E61A6F91 for ; Sun, 19 Oct 2014 20:24:15 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-09v.sys.comcast.net with comcast id 5FQD1p00358ss0Y01FQFrE; Mon, 20 Oct 2014 03:24:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id 5FQE1p0073Ge9ey01FQEvF; Mon, 20 Oct 2014 03:24:15 +0000 Message-ID: <5444805E.8030104@alum.mit.edu> Date: Sun, 19 Oct 2014 23:24:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , IETF MMUSIC WG References: <7594FB04B1934943A5C02806D1A2204B1D4AF4E7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4AF4E7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413775455; bh=Hbm8ZBK8c1FUI8hXalVryha9e/jlhbtpUacd/Q1nZvs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XZgoXPg7MlxRg7FJUeaNbYTOul35//6a82FH0WmmgIMWPR6taJJRJRJz5MBdmE4AU kQ5s6pJrvOGt5vFvGoGsUqbEcenN+c18xoY+KLnOF7R+KuFkhYTci3ZXZcol8F607w Dn/K4+vkVDwjt3NouG5DGLxTEI55thOJdWGkQvrVUwE5esN704QnOzhJJt2gr8gs2S CKlTl14/gVGXmncHD0+Xvr2co1nSH0zdEWBy6Ha5W9FOAF/5rQtytn1xQjbDQcxJna E+R+6JQWlAQn0N+iRpNF5E+jhJFYpYS/ddaWf5ry7BcA5TgMZLL4WS1CpVeGylyYv+ w4RBtfaK12s5A== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yWx79hFAZzLRwduLamgTx99qK04 Subject: Re: [MMUSIC] SDP Directorate Review: New SDP attribute sections in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 03:24:18 -0000 On 10/19/14 7:49 PM, Christer Holmberg wrote: > Hi, > > I am performing an SDP directorate review of the SDP attribute sections > (6 and 8.2.4) of draft-ietf-mmusic-rfc4566bis-12. > > A couple of high level principle issues that needs to be discussed. Hmm. Interesting catch. > Offer/Answer considerations: > > ======================== > > Normally, when we define new SDP attributes, we are also supposed to > define the associated Offer/Answer procedures (following the rules in > RFC 3264). > > However, the O/A procedures are missing from the attributes defined in > the draft, nor is it anywhere said that they must be defined for new > attributes. Well, a number of them are covered in 3261 and 3264. But not all. Need to think about it. > BUNDLE considerations: > > ==================== > > Should we mandate to indicate which “category” > [draft-ietf-mmusic-sdp-mux-attributes] an attribute is associated with. I had the impression that the mux draft was going to do that specification for all the attributes it has considered. But attributes defined in the future will have to cover this. We could decide to fold that into this bis so that it provides an example for the future. Chairs - what do you think? Thanks, Paul From nobody Mon Oct 20 00:01:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886FC1A6FC4 for ; Mon, 20 Oct 2014 00:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4r-H8ySAucF for ; Mon, 20 Oct 2014 00:01:33 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC211A6FC3 for ; Mon, 20 Oct 2014 00:01:32 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-92-5444b34aa0b6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 29.58.24955.A43B4445; Mon, 20 Oct 2014 09:01:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 09:01:30 +0200 From: Christer Holmberg To: Paul Kyzivat , IETF MMUSIC WG Thread-Topic: SDP Directorate Review: New SDP attribute sections in rfc4566bis Thread-Index: Ac/r90f99G+9E6sCTjqmqeYmTBonlQADUb8AAAuSxWA= Date: Mon, 20 Oct 2014 07:01:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4B19C3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4AF4E7@ESESSMB209.ericsson.se> <5444805E.8030104@alum.mit.edu> In-Reply-To: <5444805E.8030104@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvja7XZpcQgyPTdS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj8tRHbAUruSoez7/J3sC4maOLkZNDQsBE 4nJXOxOELSZx4d56NhBbSOAoo8SDAyZdjFxA9hJGidtHf7N3MXJwsAlYSHT/0wapERHwkjjx 9zRYvbCAr0TD27/MEPEAiYcdN8DKRQSsJJq32oKEWQRUJeZf7wQr4QUq//5qMdSqfIlf264w gpRzCuhIPJ5XDRJmBLrm+6k1YJcxC4hL3HoyH+pKAYkle84zQ9iiEi8f/2OFsJUkVmy/xAhR ryOxYPcnNghbW2LZwtdQawUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFSbnpRsZ6 qUWZycXF+Xl6eaklmxiBEXJwy2/VHYyX3zgeYhTgYFTi4V2Q4xIixJpYVlyZe4hRmoNFSZx3 4bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY4+Mevwx6nFYiWqpsYSa4afaSHbE9pTc/ 1IjMtdPgna/e2Hr0i2Lu0ZwYp0/7N5iKRilvfHK+Vqh0yZHb9XGqGa9qVthnRXbpCbpKrmPi uXH0xbqDIXYSX6brSFU8FFwh0sFYH/Bqu/QHzbiAExMLlkRctPjUnCmcWhD/TJXFXSEp8rd8 0UolluKMREMt5qLiRADk7YeMcQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ixz13gEvT1SK5x_T4Q_iWRgJr0g Subject: Re: [MMUSIC] SDP Directorate Review: New SDP attribute sections in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 07:01:38 -0000 Hi Paul, >> Offer/Answer considerations: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Normally, when we define new SDP attributes, we are also supposed to=20 >> define the associated Offer/Answer procedures (following the rules in=20 >> RFC 3264). >> >> However, the O/A procedures are missing from the attributes defined in=20 >> the draft, nor is it anywhere said that they must be defined for new=20 >> attributes. > > Well, a number of them are covered in 3261 and 3264. Correct. My issue is more about the fact that that there is no text on specifying th= e O/A procedures for new attributes. Currently we rely on the MMUSIC partic= ipants/chairs and SDP directorate to make sure it's there. >> BUNDLE considerations: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Should we mandate to indicate which "category" >> [draft-ietf-mmusic-sdp-mux-attributes] an attribute is associated with. > > I had the impression that the mux draft was going to do that specificatio= n for all the > attributes it has considered. > But attributes defined in the future will have to cover this. Correct. So, again, the issue is more about the guidelines and procedures for defini= ng new attributes. Regards, Christer From nobody Mon Oct 20 05:26:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3065D1A86F4 for ; Mon, 20 Oct 2014 05:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBKcnVXHOLSM for ; Mon, 20 Oct 2014 05:26:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2BB1A86EF for ; Mon, 20 Oct 2014 05:26:01 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 59B9BF1702869 for ; Mon, 20 Oct 2014 12:25:57 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9KCPaif011234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Oct 2014 14:25:59 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 14:25:44 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" Thread-Index: Ac/sYPdzY/WKPBX1TKS3of9vHOLr0g== Date: Mon, 20 Oct 2014 12:25:44 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/otUXRebW1lxJFiHfVli0DrZYYTM Subject: [MMUSIC] (no subject) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 12:26:03 -0000 I have just posted the following which is the revision following the discus= sion in the London meeting. Additionally further updates have taken place to align with the latest vers= ions of other MMUSIC drafts. Regards Keith A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-01.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Name: draft-ejzak-mmusic-data-channel-sdpneg Revision: 01 Title: SDP-based "SCTP over DTLS" data channel negotiation Document date: 2014-10-20 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data= -channel-sdpneg-01.txt Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-ch= annel-sdpneg/ Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-= sdpneg-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-= channel-sdpneg-01 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP, where each data channel might be used to transport other protocols, called sub-protocols. Data channel setup can be done using either the internal in-band band (also referred to as 'internal' for the rest of the document) WebRTC Data Channel Establishment Protocol or some external out-of-band simply referred to as 'external negotiation' in the rest of the document . This document specifies how the SDP offer/answer exchange can be used to achieve such an external negotiation. Even though data channels are designed for RTCWeb use initially they may be used by other protocols like, but not limited to, the CLUE protocol. This document is intended to be used wherever data channels are used. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Oct 20 07:58:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562C71A8F3B for ; Mon, 20 Oct 2014 07:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPiBKzJqSMKw for ; Mon, 20 Oct 2014 07:58:01 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE761A86E6 for ; Mon, 20 Oct 2014 07:32:53 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id C50E81EB83FC; Mon, 20 Oct 2014 16:32:51 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 16:32:51 +0200 From: "Stach, Thomas" To: Christer Holmberg , =?iso-8859-1?Q?Ari_Ker=E4nen?= , mmusic Thread-Topic: [MMUSIC] ICE updated offer - Back to the initial question Thread-Index: AQHP7HK5lMa3/gEle0Ks8yDgFLAuew== Date: Mon, 20 Oct 2014 14:32:50 +0000 Message-ID: References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/lORWBcHNqXPlZqdvE2SDbVdAwc4 Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 14:58:02 -0000 Christer, I'm trying to understand ...=20 ... and disagree with your last point > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Freitag, 17. Oktober 2014 12:01 > To: Stach, Thomas; Ari Ker=E4nen; mmusic > Subject: RE: [MMUSIC] ICE updated offer - Back to the initial question >=20 > Hi, >=20 > Whatever decisions are made at the meetings must (or, at least that seem = to > be de facto practise) be confirmed on the mailing list. So, it is ok to > challenge them (luckily that doesn't happen too often, though - at least > not within the groups where I participate). >=20 > >Proposal A: Indicate in the ANSWER whether the second offer is needed or > not. > >Proposal B: If you need the update, send an offerless re-INVITE with a > flag > > that suppresses an ICE restart, > > but triggers the ICE updated offer instead. >=20 > Using SIP terminology (as this mechanism could only be used with SIP > anyway), the second offer will almost always be send during an early > dialog, while the initial INVITE transaction is still ongoing.=20 [TS] You seem to assume support for PRACK here.=20 Of course, the offerless re-INVITE could not be used as a trigger for the n= ew offer in this case. You would need "something else" in such an environment.=20 The offerless INVITE, nevertheless, sounds attractive to me for other envir= onments, since it only requires basic RFC3261 functionality.=20 > You cannot send a re-INVITE during that time, so it wouldn't work.=20 [TS] If PRACK is not supported, you also couldn't send that second offer du= ring the early dialog.=20 > Sending the re- > INVITE once the call has been established could prevent early media,=20 [TS] So, if the offerer does support ICE but not PRACK, it wouldn't get ear= ly media, even if the connectivity checks were successful? Do you assume support for preconditions in addition to PRACK? > and > any other information transported on the media plane during the early > dialog phase. >=20 > >Proposal C: The signaling entity should inform the media entity about > > the candidates. The media entity can then learn through the > > STUN checks which address is eventually used for media. >=20 > That might work if the media entity is STUN aware (and if the > interface/protocol used to control the media entity supports transporting > that kind of information). Often they are not. They are simply used to e.= g. > enforce bandwidth (and other network resources) and gating. >=20 > > Are there additional proposals or do we want to choose from these? >=20 > One is to keep everything as it is today, as nothing is broken.=20 [TS] I beg to disagree here. I repeatedly mentioned that certain 3PCC call = flows break _due_ to the updated offer. Regards Thomas > Nobody has indicated that as a preference, though. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4ne= n > > Sent: Dienstag, 14. Oktober 2014 10:15 > > To: mmusic > > Subject: [MMUSIC] ICE updated offer > > > > Hi all, > > > > At the Toronto meeting we discussed whether we should change the > > behavior with ICE updated offer. Currently, based on RFC 5245, when > > ICE has finished, there is a new offer/answer with the selected > > candidate, > > *if* they are different from the "default candidates", i.e., the ones > > in original o/a m- and c-lines. > > > > Based on the discussion there was strong desire to have an option of > > not doing the updated o/a at all by indicating this in the original > > o/a. On the other hand, for some, the updated o/a was seen as a > > requirement for getting correct behavior from the network in certain > > scenarios (e.g., with SIP-aware middle boxes). > > > > I would like to hear from people, who have issues making the updated > > o/a optional, how bad the change would be and is there a way we could > > make this work also in those scenarios? > > > > > > Cheers, > > Ari > > > > _______________________________________________ > > 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 nobody Mon Oct 20 10:12:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1C91A6FF9 for ; Mon, 20 Oct 2014 10:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrDVXWKuUVVM for ; Mon, 20 Oct 2014 10:11:54 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E841A88C2 for ; Mon, 20 Oct 2014 10:01:07 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-02v.sys.comcast.net with comcast id 5UyU1p00A4yXVJQ01V16sq; Mon, 20 Oct 2014 17:01:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id 5V151p00m3Ge9ey01V16PT; Mon, 20 Oct 2014 17:01:06 +0000 Message-ID: <54453FD1.9070207@alum.mit.edu> Date: Mon, 20 Oct 2014 13:01:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413824466; bh=+sqCgSlSvi0MXTtvBoZqWwsXzY2xpSlrKicwgy81g98=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZwJtcur7xr3gM4g7narzIt/B0RTSlAkD/rwD7sFbedlbr1LNs2zLRLZr+ZolGokVy XKkW7oAQLVqdPm7MPHKrIqGOIYXNCMD4+HWNi9jtA8xLJOVTBCHFlR0hPOdBxvngAc z5VnF8Ev6xJqQFdYfpUSV6EZgWgghLeFoSS6KezY3yUxrtcAQLa+PY6o6Ebw0g0Zg1 Q4ywEqKl9ydWiHZdmnK/RVqU4t894lhwR8Mu+/fwCMqJlglBXkSBtzPPF3naBWv5Sc 2kzBkYqKNqtVCsC+kfcD8Rlw5qSS8OE8TS5sHHwER0r0w40pQXp8UgBlAUfPgu7nA8 kuvo8zJXWeaNQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/uPN2ZUlFGIoUzo7NgGZcQIifb70 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 17:11:57 -0000 Replies inline On 10/18/14 3:51 PM, Christer Holmberg wrote: > Hi Paul, > > Thanks for your review! See inline. > > ------------------------- > >> *< Abstract: >> >> The following language is a little awkward: >> >> Both endpoints can negotiate the use of bundle and to support that >> negotiations, this specification ... >> >> How about the following: >> >> To assist endpoints in negotiating the use of bundle this >> specification ... > > OK. > >> In the same paragraph, s/allows/allow/ > > OK. > > ------------------------- > >> * Section 1: Introduction: >> >> In the third paragraph is: >> >> The BUNDLE address is used to send and receive >> all media associated with the BUNDLE group. >> >> In the above, s/address is/addresses are/ > > OK. > > ------------------------- > >> The 6th paragraph says: >> >> This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 >> [RFC3264]. The update allows an answerer to assign a non-zero port >> value to an "m=" line in an SDP answer, even if the "m=" line in the >> associated SDP offer contained a zero port value. >> >> The statement of the update is overly broad, because it doesn't state that the relaxation on answering with a non-zero port only applies within a bundle. I suggest the following: >> >> This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 >> [RFC3264]. The update allows an answerer to assign a non-zero port >> value to a bundled "m=" line in an SDP answer, even if the "m=" line >> in the associated SDP offer contained a zero port value. > > I can do that change, but keep in mind that the new RFC 3264 text does not talk about BUNDLE, but more generically say that an extension can define new semantics for a port zero value in an offer. Good point. While this statement is overly broad, it is only an overview, and the sections that formally update 3264 are more specific. So I take back this suggestion. > ------------------------- > >> * Section 2: Terminology >> >> In the following: >> >> BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer >> exchange, for which each endpoint uses a single 5-tuple to send and >> receive media. Each endpoint uses its BUNDLE address, associated >> with the BUNDLE group, to send and receive the media. >> >> are we *requiring* symmetric media usage? Certainly you must *receive* on your bundle address, but AFAIK *sending* on that address is, in general, optional though various options that > might be used with it (such as ICE) may require it. > > The definition of "BUNDLE address" states that the address is used for both sending and receiving media. This is a little fuzzy. That is mentioned in the Intro, but not in the Terminology definitions of Offerer/Answerer BUNDLE address. It is mentioned in the definition of BUNDLE group, but not in a normative way. If you really intend to require this, then it should be stated more clearly in a normative way. > ------------------------- > >> * Section 6: SDP 'bundle-only' Attribute >> >> I would like to see the definition follow the new style introduced in draft-ietf-mmusic-rfc4566bis-12. This draft is nearer to completion to that one, and there is some risk that the new style >will be revised in that draft. I don't propose to hold this draft up for that one - there should not be any formal dependency. > > I'll look into that. > > One comment, that I will provide in a separate e-mail, I have on the new style is that it should define (or, at least refer to) the Offer/Answer procedures for the attribute. > > ------------------------- > >> * Section 7.3: Bandwidth >> >> Says: >> >> The total proposed bandwidth for a BUNDLE group is the sum of the >> proposed bandwidth for each bundled "m=" line. >> >> What if some of the bundled m-lines have no b= line, while others do? It probably doesn't make sense to treat them as having zero bandwidth. I guess maybe some default value should be >used. But what? > > You do whatever you'd do for a non-BUNDLED "m=" line. Normally I guess you have a default value, or a value based on the media type and/or payload formats. I think this requires discussion with people that know more about this topic. AFAIK, with non-bundled m-lines that don't specify, there is no specific limit unless there is a session-level b-line. I don't know what happens if there is a session-level b-line. I guess there is supposed to be a default for every codec. >> Or, I guess there could be a rule that if any of the bundled m-lines have b= then all of them must. >> >> Also, I guess there needs to be a separate sum for each bandwidth type. >> >> Note: this is also an issue for draft-ietf-mmusic-sdp-mux-attributes. >> >> I note that section 7.3 defers to draft-ietf-mmusic-sdp-mux-attributes >> for attribute bundling rules. > > I assume you mean section 7.4? Yup. >> Perhaps this section should similarly defer to that draft for bandwidth bundling. > > The "b=" parameter is not covered by that draft (as it's not an SDP attribute). Ah! So this draft is on its own. It seems like more text is needed. Especially what to do with extension bandwidth types. > ------------------------- > >> * Section 8.2.1: Generating the Initial SDP Offer: General >> >> The use of "assign" in the second bullet item seems inappropriate: >> >> o Assign an SDP 'group:BUNDLE' attribute to the offer; >> >> I suggest instead: >> >> o Add a new SDP 'group:BUNDLE' attribute to the offer >> for the new BUNDLE group; > > OK. > > ------------------------- > >> * Section 8.2.2: Request offerer BUNDLE address selection >> >> I think the name of this section is slightly confusing - "Request" could be a verb (intended) or a noun. I suggest changing it to: >> >> "Suggesting an offerer BUNDLE address" > > I use "Request" in other places (e.g. "offerer requested the BUNDLE group") so I'd like to keep the text. > > In addition, aren't you the one who suggested "Request" terminology in the past? :) I don't remember. In any case it is a hard statement to parse. If you want to keep the term, how about "Requesting offerer BUNDLE address selection"? (But I still think "Suggesting" is clearer.) > ------------------------- > >> * Section 8.3.2: Answerer Selection of Offerer Bundle Address >> >> I have a few wording changes to suggest for clarity: >> >> In this section, the use of 'the "m=" line' seems a little vague. I think it would be better to change it to 'that "m=" line' throughout. > > I do agree that we could use the following modified sentence: > > "The answerer MUST check whether that "m=" line fulfils the following criteria:" s/fulfils/fulfills/ > But, after that, I think all instances of 'the' refers to that 'that' :) OK. >> Also >> - s/fulfils/fulfills/ >> - s/criteria above is fulfilled/criteria above are fulfilled/ >> - s/criteria is not fulfilled/criteria are not fulfilled/ >> - s/represents/identifies/ > > OK. > > ------------------------- > >> * Section 8.4.1: Offerer Processing of the SDP Answer: General >> >> In the following: >> >> When an offerer receives an answer, if the answer contains a BUNDLE >> group, the offerer MUST check that any bundled "m=" line in the >> answer was indicated as bundled in the associated offer. If there is >> no mismatch, the offerer MUST apply the offerer BUNDLE address, >> selected by the answerer [Section 8.3.2], to each bundled "m=" line. >> >> the use of the word "apply" is a little unclear. While the intent can be inferred, it isn't defined anywhere, or used in this way anywhere else. >> I suggest it could be written as: >> >> ... the offerer MUST use the offerer BUNDLE address, selected by >> the answerer [Section 8.3.2], as the address for each bundled >> "m=" line. > > OK. > > ------------------------- > >> * Section 9.2: STUN, DTLS, SRTP >> >> In the first paragraph, s/offer or answerer/offerer or answerer/ > > OK. > >> Replace the following: >> >> ... If an offer or answerer in offers or answers include >> bundled "m=" lines that represent these protocols, the offerer or >> answerer MUST support ... >> >> with: >> >> ... If an offer or answer includes bundled "m=" lines that represent >> these protocols, the offerer or answerer MUST support ... > > OK. > >> Another thing: I *think* that *plain* RTP can also coexist with STUN, DTLS, and SRTP using the rules of RFC5764. (Can somebody confirm if this is true?) > > I'll ask Colin. Sounds good. >> Also, there is *no* mention of SCTP in this document. ISTM that there should be something. I guess the 2nd paragraph here is intended to cover that. If so, it is too subtle. > > The document does not cover SCTP - unless it is transported on top of DTLS, in which case it is implicitly covered by the 2nd paragraph. > > What would you like to mention about SCTP? > >> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't use DTLS payload packets. So *one* m-line with a protocol that uses DTLS payload packets (e.g., >DTLS/SCTP) can coexist with STUN and SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines. > > I think that is covered, as SRTP is distinguished from DTLS. > > But, if you think that needs to be more clear, maybe the following modified sentence: > > "[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..." I think this document should bite the bullet and define how SCTP coexists with SRTP in a bundle. > ------------------------- > >> * Section 10.1.1: Single RTP Session: General >> >> The second bullet: >> >> o The "proto" value in each bundled "m=" line MUST be identical >> (e.g. RTP/AVPF). >> >> should only apply to RTP m-lines. E.g.: >> >> o The "proto" value in each bundled RTP-based "m=" line MUST be >> identical (e.g. RTP/AVPF). > > OK. > > ------------------------- > >> * 10.3.2.2: Generating the Initial SDP Offer >> >> Similar comment to the previous one: >> >> s/each bundled "m=" line/each bundled RTP-based "m=" line/ >> >> (It occurs twice in the paragraph.) > > OK. > > ------------------------- > >> * 10.3.2.3: Generating the SDP Answer >> >> My comment for 10.3.2.2 applies here as well. > > OK. > >> The MUST NOT in the 2nd paragraph concerns me: >> >> If the answerer accepts usage of RTP/RTCP multiplexing within the >> BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each >> bundled "m=" line in the answer. The answerer MUST NOT assign an SDP >> 'rtcp' attribute to any bundled "m=" line in the answer. The >> answerer will use the port number of the selected offerer BUNDLE >> address for sending RTP and RTCP packets associated with each bundled >> "m=" line towards the offerer. >> >> I don't understand why the rtcp attribute MUST NOT be used. I understand that the port from the offer is >> used by the answerer to send RTCP. But without the attribute there is no explicit indication of where the >> offerer is to send RTCP. What is wrong with including the rtcp attribute in the answer??? >> >> Also, in general (ignoring bundle), isn't it valid to use the 'rtcp' attribute without the 'rtcp-mux'? (I thought >> it was invented for cases where NATs prevented getting an even/odd pair of ports.) So in bundle, shouldn't >> it also be valid to use the 'rtcp' attribute without the 'rtcp-mux' attribute? (Identical in all m-lines.) > > The reason we don't allow 'rtcp' in the answer (even if RTP/RTCP multiplexing is not used) is because in the offer we only allow the value of the "m=" line (i.e. the value used for RTP) for 'rtcp'. > > So, either multiplexing is used, or port+1 is used. If we'd change that, we should also allow the offerer to assign whatever value it wants to the 'rtcp' attribute... OK. > ------------------------- > >> * Section 12: Update to RFC 3264 >> >> The way in which the changes are presented are great for somebody who is not familiar with 3264 and is truly reading this instead. (Or for somebody who is authoring >3264bis.) But it is quite difficult to understand what the differences are between the two. I had to copy the text out into separate old and new files and then diff them to >clearly understand what has changed. >> >> I'd appreciate some sort of diff that highlights the fundamental distinctions. (But I'm not sure what kind would be clear and work with the constraints of a draft.) > > The Introduction states that the change is related to the usage of port zero, so having that information I think it is not that difficult to see what has been changed. > > Also, my experience from the IESG reviews is that there are always different suggestions on how to update text. So, I'd prefer to keep it as it is, because it may still come up as part of the IESG review. OK. > ------------------------- > >> * Section 12.5: New text replacing section 8.2 (2nd paragraph) >> >> I take issue with one change here - the addition of "(like the offer)". >> I don't know if you intend it that way, but to me it seems to suggest that you can only omit attributes if they were omitted in the offer. >> >> So I think that particular part of the change should be removed. > > The intention is not to indicate that one can only omit attributes if they were omitted in the offer. > > I am ok to remove "(like the offer)". Thanks. Paul > ------------------------- > >> * Section 16: Examples >> >> The ordering of fields in the examples in not valid according to the rules of 4566. It requires "c=", "b=", "a=" in that order. > > OK. > > The examples were provided by Harald, so I hope they are not based on a Chrome trace ;) > > ------------------------- > >> * Section 16.3 >> >> I gather that this example is intended to continue on from the the example in 16.1. It would be helpful to say that. > > OK. > > ------------------------- > >> * Section 16.4 >> >> I gather that this example is intended to continue on from the the example in 16.3. It would be helpful to say that. > > OK. > > ------------------------- > >> * Section 16.5 >> >> I gather that this example is intended to continue on from the the example in 16.3. It would be helpful to say that. > > OK. > > ------------------------- > > Thanks! > > Regards, > > Christer > From nobody Mon Oct 20 10:16:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6A71A8718 for ; Mon, 20 Oct 2014 10:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn1x5cKJmnBK for ; Mon, 20 Oct 2014 10:16:34 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87B81A6F5A for ; Mon, 20 Oct 2014 10:07:21 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-11v.sys.comcast.net with comcast id 5V6n1p0075Clt1L01V7MSC; Mon, 20 Oct 2014 17:07:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-17v.sys.comcast.net with comcast id 5V7L1p00E3Ge9ey01V7LRN; Mon, 20 Oct 2014 17:07:21 +0000 Message-ID: <54454148.7070407@alum.mit.edu> Date: Mon, 20 Oct 2014 13:07:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mmusic-chairs@tools.ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D4AF4E7@ESESSMB209.ericsson.se> <5444805E.8030104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4B19C3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4B19C3@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413824841; bh=RH3wlNM2h01PWxkRJg+tI1EGIz4ivg1SU1kPMnuiXWo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YdfRpNENZbkqdvnhJSXieW2va2fCY+I4XL/lZjgLNYLnM4FJ8ew/+X1MI41TOTps2 m0cIgOzCDAU0ahQvk0uxRorOW+VBQaqAvxrkXgB8XRtdyva1TA6ZW3HPq/UrHbslLb 35rYeTRu4nzlz8Ef7UAB/zndr3p9e5fFgokz1sqB8nuAzFMvK9pRuaGUOyXp/Sbe/Z YAClR5ijYMN9c/gLbBqfQU+IQy1WpIx0reJE9pSX8V6jfOgi9PirSRVa4iBnFo1cdo ULgqSa3JKiKF4IhGLfduguW2lRTPiNS/21oo5Cdr62993r2tEr1nDkKpAg4c9EeGtR GFOSILSJ++2mw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YUc0Zo1p910U9WMIRjdyxbsWJ2Q Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] SDP Directorate Review: New SDP attribute sections in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 20 Oct 2014 17:16:36 -0000 Chairs: Do you want to expand the scope of this effort to include O/A and BUNDLE considerations for the attributes defined in this draft? The pro is that this will further set an example for how future attributes should be defined. The con is that this will require reproducing, or moving, information that is currently defined in other drafts. Thanks, Paul On 10/20/14 3:01 AM, Christer Holmberg wrote: > Hi Paul, > >>> Offer/Answer considerations: >>> >>> ======================== >>> >>> Normally, when we define new SDP attributes, we are also supposed to >>> define the associated Offer/Answer procedures (following the rules in >>> RFC 3264). >>> >>> However, the O/A procedures are missing from the attributes defined in >>> the draft, nor is it anywhere said that they must be defined for new >>> attributes. >> >> Well, a number of them are covered in 3261 and 3264. > > Correct. > > My issue is more about the fact that that there is no text on specifying the O/A procedures for new attributes. Currently we rely on the MMUSIC participants/chairs and SDP directorate to make sure it's there. > > >>> BUNDLE considerations: >>> >>> ==================== >>> >>> Should we mandate to indicate which "category" >>> [draft-ietf-mmusic-sdp-mux-attributes] an attribute is associated with. >> >> I had the impression that the mux draft was going to do that specification for all the > attributes it has considered. >> But attributes defined in the future will have to cover this. > > Correct. > > So, again, the issue is more about the guidelines and procedures for defining new attributes. > > Regards, > > Christer > From nobody Mon Oct 20 17:24:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F961ACE81 for ; Mon, 20 Oct 2014 17:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.769 X-Spam-Level: * X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4oSX-IJazRa for ; Mon, 20 Oct 2014 17:24:04 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id 451211ACE74 for ; Mon, 20 Oct 2014 17:24:04 -0700 (PDT) Received: from userPC (unknown [122.172.254.167]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 45DB5E28053; Tue, 21 Oct 2014 00:23:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1413851043; bh=6Lag7JuEsD9wHhfrDXLqxGYx41y46XadRt8QKPMNAfY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=i15Cc+FckRhsMMmlPCMNqeBleI1Xr2J9DDL2pxd+EPzo4SMOT7Vxbf7pylr1mdOLW vMeSfu8JtYg3spmsre0nB9J1zqjCZsquC73vo46XpkN3/Fm7Y2TgDEdbnEcq2ll+4l Yx30Kw82OkbWFKJAU0bdY/6w8bvFVVNejg2XB1qc= From: "Parthasarathi R" To: "'Stach, Thomas'" , "'Christer Holmberg'" , =?iso-8859-1?Q?'Ari_Ker=E4nen'?= , "'mmusic'" References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se> In-Reply-To: Date: Tue, 21 Oct 2014 05:53:40 +0530 Message-ID: <009501cfecc5$48d513f0$da7f3bd0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP7HK5lMa3/gEle0Ks8yDgFLAue5w5rXIg Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.5445A7A3.0130, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Cumgy-sUG691HCHQiPHUYa12zv0 Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 00:24:06 -0000 Hi Thomas, Could you please mention the exact 3PCC callflow which breaks because of = the ICE second offer. Of course ideally, it should have covered in ICE (RFC 5245).=20 Early dialog will not work without PRACK (RFC 3264) in the single offer/answer itself. In case you assume that 18x is reliable without = PRACK then it has lot of caveat as the intermediate SIP entities may use UDP = as a transport wherein UAS has no control over. I assume that you intent to = say that UPDATE (RFC 3311) is mandated in case of RFC 5245 second offer. Thanks Partha > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Stach, > Thomas > Sent: Monday, October 20, 2014 8:03 PM > To: Christer Holmberg; Ari Ker=E4nen; mmusic > Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question >=20 > Christer, >=20 > I'm trying to understand ... > ... and disagree with your last point >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Freitag, 17. Oktober 2014 12:01 > > To: Stach, Thomas; Ari Ker=E4nen; mmusic > > Subject: RE: [MMUSIC] ICE updated offer - Back to the initial > question > > > > Hi, > > > > Whatever decisions are made at the meetings must (or, at least that > seem to > > be de facto practise) be confirmed on the mailing list. So, it is ok > to > > challenge them (luckily that doesn't happen too often, though - at > least > > not within the groups where I participate). > > > > >Proposal A: Indicate in the ANSWER whether the second offer is > needed or > > not. > > >Proposal B: If you need the update, send an offerless re-INVITE = with > a > > flag > > > that suppresses an ICE restart, > > > but triggers the ICE updated offer instead. > > > > Using SIP terminology (as this mechanism could only be used with SIP > > anyway), the second offer will almost always be send during an early > > dialog, while the initial INVITE transaction is still ongoing. > [TS] You seem to assume support for PRACK here. > Of course, the offerless re-INVITE could not be used as a trigger for > the new offer in this case. > You would need "something else" in such an environment. > The offerless INVITE, nevertheless, sounds attractive to me for other > environments, since it only requires basic RFC3261 functionality. > > You cannot send a re-INVITE during that time, so it wouldn't work. > [TS] If PRACK is not supported, you also couldn't send that second > offer during the early dialog. > > Sending the re- > > INVITE once the call has been established could prevent early media, > [TS] So, if the offerer does support ICE but not PRACK, it wouldn't = get > early media, even if the connectivity checks were successful? > Do you assume support for preconditions in addition to PRACK? > > and > > any other information transported on the media plane during the = early > > dialog phase. > > > > >Proposal C: The signaling entity should inform the media entity > about > > > the candidates. The media entity can then learn through > the > > > STUN checks which address is eventually used for media. > > > > That might work if the media entity is STUN aware (and if the > > interface/protocol used to control the media entity supports > transporting > > that kind of information). Often they are not. They are simply used > to e.g. > > enforce bandwidth (and other network resources) and gating. > > > > > Are there additional proposals or do we want to choose from these? > > > > One is to keep everything as it is today, as nothing is broken. > [TS] I beg to disagree here. I repeatedly mentioned that certain 3PCC > call flows break _due_ to the updated offer. > Regards > Thomas > > Nobody has indicated that as a preference, though. > > > > Regards, > > > > Christer > > > > > > > > > -----Original Message----- > > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari > Ker=E4nen > > > Sent: Dienstag, 14. Oktober 2014 10:15 > > > To: mmusic > > > Subject: [MMUSIC] ICE updated offer > > > > > > Hi all, > > > > > > At the Toronto meeting we discussed whether we should change the > > > behavior with ICE updated offer. Currently, based on RFC 5245, = when > > > ICE has finished, there is a new offer/answer with the selected > > > candidate, > > > *if* they are different from the "default candidates", i.e., the > ones > > > in original o/a m- and c-lines. > > > > > > Based on the discussion there was strong desire to have an option > of > > > not doing the updated o/a at all by indicating this in the = original > > > o/a. On the other hand, for some, the updated o/a was seen as a > > > requirement for getting correct behavior from the network in > certain > > > scenarios (e.g., with SIP-aware middle boxes). > > > > > > I would like to hear from people, who have issues making the > updated > > > o/a optional, how bad the change would be and is there a way we > could > > > make this work also in those scenarios? > > > > > > > > > Cheers, > > > Ari > > > > > > _______________________________________________ > > > 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 From nobody Mon Oct 20 19:35:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8F51ACED6 for ; Mon, 20 Oct 2014 19:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82N9mU-lk1eR for ; Mon, 20 Oct 2014 19:35:09 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ADF1ACE27 for ; Mon, 20 Oct 2014 19:35:09 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-07v.sys.comcast.net with comcast id 5eaq1p00258ss0Y01eb8R1; Tue, 21 Oct 2014 02:35:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id 5eb71p00E3Ge9ey01eb7E9; Tue, 21 Oct 2014 02:35:08 +0000 Message-ID: <5445C65B.6040804@alum.mit.edu> Date: Mon, 20 Oct 2014 22:35:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413858908; bh=U9lTfdjrrQxpzQFONNWbzPTnCGiTXI0JReJMCdU6XyA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Kz5+iHv5fZmUr1gE/9fWGKqMHB7fES1cP2xTBB49d5f2UY+MSn7YuI1okVOa6KDb4 8Q6sD3y8x7fyXUxeuLYLQ7F5cTPXiNgXfFigMCdGtHtK3aXCpV4Z1OrHJh+MCkSljP PYShT/l3KXPscTZM4NdafYQrLexhcnO/C4LBNLyVNRCMtFtmzxPj5Ury1qapdIziHF SEtMcScZzuW0nnYgRd2eeDjTVhRZ4z4LTFyJCVvwVTsl0tvmN/7vphV18XznTmbYI0 nta7lkLJq3uadncCArYFhe74NjYnbfYFQueBElJu9tTi9gA6l2vsChWMWuRtbqCtcL 8DtfzJHXjBv2A== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/t1_-LAagDv_d2uGRKx3tNh5keNk Cc: IETF MMUSIC WG Subject: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 02:35:11 -0000 This is in much better shape now - having caught up with changes in the related drafts. Here are a few comments and suggestions: * Section 5.1.1.1: Rather than using 'unordered=1' for unordered, and 'unordered=0' for ordered, it would be more obvious to simply use 'ordered' and 'unordered'. Are all combinations of max_retr, max-time, unordered, [ordered] allowed? (There are 8 such combinations, but there are only 6 data channel types in rtcweb-data-protocol.) (The syntax for the dcmap attribute suggests that all combinations are valid.) Also, the syntax forces the fields to be entered in a particular order. That is likely to be a source of errors. * Sections 5.1.1.2 & 5.1.1.3 the definition 'text = byte-string' has to be wrong. That will suck up the rest of the line, including following ";" separated items. The examples show that you mean a quoted string, but 4566 doesn't have a definition for that. * Section 5.1.1.4 The section title (and usage through the document) calls this parameter 'max_retr", but the syntax defines it as 'maxretr'. IMO a separator in this is good, but I would prefer it to be "-" rather than "_". I think maxretrvalue could be defined using 'integer' from 4566. That is almost the same, but can't start with a zero. It would be good to specify the valid range for this this parameter. That could be specified by reference to rtcweb-data-protocol. * Section 5.1.1.5 My comments on 5.1.1.4 apply here as well. Here is a proposal for updating the syntax to deal with all of the above. (Note that I've also changed to use the format I have proposed in rfc4566bis.) Name: dcmap Value: dcmap-value Usage Level: media Charset Dependent: no Syntax: dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ] dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt dcmap-stream-id = 1*DIGIT ordering-opt = "ordered" / "unordered" subprotocol-opt = "subprotocol=" quoted-string label-opt = "label=" quoted-string maxretr-opt = "max-retr=" maxretr-value maxretr-value = integer maxtime-opt = "max-time=" maxtime-value maxtime-value = integer ; milliseconds quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char = SP / quoted-visible quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % escaped = "%" HEXDIG HEXDIG DQUOTE = integer = Examples: a=dcmap:0 a=dcmap:1 subprotocol="BFCP";max-time=60000 a=dcmap:2 subprotocol="MSRP";ordered;label="MSRP" a=dcmap:3 label="Label 1";unordered;max-retr=5 a=dcmap:4 label="foo%09bar";ordered;max-time=15000;max-retr=3 Note that I made subprotocol optional, like the others. Also, I defined quoted-string so that it can only contain SP and visible ascii characters other that " and % as literals. Anything else must be in hex. There are lots of other possibilities for how to do that, but at least that one is clear when you look at it. * Section 5.1.2 Each sub-protocol specific SDP attribute that would normally be used to negotiate the subprotocol using SDP is replaced with an attribute of the form "a=dcsa:sctp-port:stream-id original-attribute", ... None of the examples include the sctp-port. I guess this should have said: "a=dcsa:stream-id original-attribute". But that highlights the need for of a formal specification of the dcsa attribute. E.g., Name: dcsa Value: dcsa-value Usage Level: media Charset Dependent: no Syntax: dcsa-value = stream-id SP attribute attribute = Example: a=dcsa:2 accept-types:text/plain * Section 5.2.1 This specification allows simultaneous use of external and internal negotiation. However, a single stream is managed using one method at a time. Stream ids that are not currently used in SDP can be used for internal negotiation. Stream id determination per external negotiation may not align with DTLS based termination. This could cause glare conditions when one side trying to do external negotiation on a stream id while the other end trying to open data channel on the same stream id using internal negotiation. To avoid these glare conditions this specification recommends that the data channel stack user always selects stream ids per SDP offer/answer rule even when internal negotiation is used. To avoid glare conditions, it is possible to come up with a different stream id allocation scheme, but such schemes are outside the scope of this specification I can't quite grok what the above paragraph is trying to tell me. Thanks, Paul On 10/20/14 8:25 AM, DRAGE, Keith (Keith) wrote: > I have just posted the following which is the revision following the discussion in the London meeting. > > Additionally further updates have taken place to align with the latest versions of other MMUSIC drafts. > > Regards > > Keith > > > A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-01.txt > has been successfully submitted by Keith Drage and posted to the IETF repository. > > Name: draft-ejzak-mmusic-data-channel-sdpneg > Revision: 01 > Title: SDP-based "SCTP over DTLS" data channel negotiation > Document date: 2014-10-20 > Group: Individual Submission > Pages: 21 > URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-01.txt > Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/ > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-01 > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) working group is > charged to provide protocols to support direct interactive rich > communications using audio, video, and data between two peers' web- > browsers. For the support of data communication, the RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. Data channel setup > can be done using either the internal in-band band (also referred to > as 'internal' for the rest of the document) WebRTC Data Channel > Establishment Protocol or some external out-of-band simply referred > to as 'external negotiation' in the rest of the document . This > document specifies how the SDP offer/answer exchange can be used to > achieve such an external negotiation. Even though data channels are > designed for RTCWeb use initially they may be used by other protocols > like, but not limited to, the CLUE protocol. This document is > intended to be used wherever data channels are used. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Oct 20 21:33:26 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045D21AD03C; Mon, 20 Oct 2014 21:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpZTVFEINvU8; Mon, 20 Oct 2014 21:33:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 775471AD032; Mon, 20 Oct 2014 21:33:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021043319.14340.16448.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 21:33:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/wa0npfNPvavDv6m1AN-aA5NmyfQ Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 04:33:21 -0000 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 Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-03.txt Pages : 87 Date : 2014-10-20 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 20 21:38:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3300F1AD007; Mon, 20 Oct 2014 21:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxdPH98_kXVi; Mon, 20 Oct 2014 21:38:35 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FBA1AD040; Mon, 20 Oct 2014 21:38:31 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id m15so379168wgh.14 for ; Mon, 20 Oct 2014 21:38:30 -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=IydvRtyWvvNbA8w5CJ8exkDEBcDJwtn6bmreflivyZQ=; b=nrq+ZFdS/QrFu8lbCOTcXGStbfRGfoP2LM/f6xX6JEm16Q2G823ytChJU+uX3drNe6 rvc3NUGDz6CITYK/6SLCEqDvbv9tfUucEbPUTy16bE6TGAEnloYEWQedPCqE0Td9G9W2 +Aa8FGBjfk5gNcMn1BV6aOrl0nXOUrjmu6TgHnD4zsW2RjrUPU7bGM/hH5udkJjNu78N wxA94dlrshnl3xkOgG/y5sET1mZ8McfvmX6lD1jlGwpqMxfcA2npkG00vGZB6GBFgYJj OCdiBRCBFj1xnFNkfTW/Fn8iyvE1CiDl+5xnoxrKaDOSHJ3Cj1U0tVwzxMl02ohh7Nfu nW+Q== MIME-Version: 1.0 X-Received: by 10.180.221.129 with SMTP id qe1mr25724081wic.21.1413866309859; Mon, 20 Oct 2014 21:38:29 -0700 (PDT) Received: by 10.194.60.134 with HTTP; Mon, 20 Oct 2014 21:38:29 -0700 (PDT) In-Reply-To: <20141021043319.14340.16448.idtracker@ietfa.amsl.com> References: <20141021043319.14340.16448.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 21:38:29 -0700 Message-ID: From: Suhas Nandakumar To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a1133c8fa28bf2a0505e76738 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/bSmYmr9pF_1xdYJfmi0GKwbLdAE Cc: mmusic WG , i-d-announce@ietf.org Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 04:38:37 -0000 --001a1133c8fa28bf2a0505e76738 Content-Type: text/plain; charset=UTF-8 Hello All I have submitted an interim version of the "A Framework for SDP Attributes when Multiplexing" draft to get the working group inputs on handling the IANA considerations section. Please note that , this version is not yet ready for a full review as I plan to submit another version by the draft deadline. Hence i request the reviewers to provide thoughts on "Section 15" which deals with IANA considerations. Link: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-03 Many Thanks Suhas On Mon, Oct 20, 2014 at 9:33 PM, 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 Framework for SDP Attributes when Multiplexing > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-sdp-mux-attributes-03.txt > Pages : 87 > Date : 2014-10-20 > > Abstract: > The Session Description Protocol (SDP) provides mechanisms to > describe attributes of multimedia sessions and of individual media > streams (e.g., Real-time Transport Protocol (RTP) sessions) within a > multimedia session. In the RTCWeb WG, there is a need to use a > single 5-tuple for sending and receiving media associated with > multiple media descriptions ("m=" lines). Such a requirement has > raised concerns over the semantic implications of the SDP attributes > associated with the RTP Media Streams multiplexed over a single > transport layer flow. > > The scope of this specification is to provide a framework for > analyzing the multiplexing characteristics of SDP attributes. The > specification also categorizes existing attributes based on the > framework described herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 > --001a1133c8fa28bf2a0505e76738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 20, 2014 at 9:3= 3 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 87
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-20

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 In the RTCWeb WG, there is a need to= use a
=C2=A0 =C2=A0single 5-tuple for sending and receiving media associated with=
=C2=A0 =C2=A0multiple media descriptions ("m=3D" lines).=C2=A0 Su= ch a requirement has
=C2=A0 =C2=A0raised concerns over the semantic implications of the SDP attr= ibutes
=C2=A0 =C2=A0associated with the RTP Media Streams multiplexed over a singl= e
=C2=A0 =C2=A0transport layer flow.

=C2=A0 =C2=A0The scope of this specification is to provide a framework for<= br> =C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 The
=C2=A0 =C2=A0specification also categorizes existing attributes based on th= e
=C2=A0 =C2=A0framework described herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusi= c-sdp-mux-attributes/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-= attributes-03

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

--001a1133c8fa28bf2a0505e76738-- From nobody Mon Oct 20 21:39:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296461AD040 for ; Mon, 20 Oct 2014 21:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrsykxTW_yT9 for ; Mon, 20 Oct 2014 21:38:57 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CDE1AD045 for ; Mon, 20 Oct 2014 21:38:56 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x13so365355wgg.30 for ; Mon, 20 Oct 2014 21:38:55 -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=xHibf8JDlnhnMRx7NdUkIzN5kc8NnsZkM9xLTYmhckY=; b=ZcXkDb44dtWo0YQCzebPvpQN+GNRcTkVU+bSIcPxnYWWVAeP27FuQ143d4wQFd5Tso QjrWW8wpFR5lNGuccXyejJnFzTKJOAG7D3tzIF5ThYtm9dT2m2qVlHal6pXMXtqBxbyo 6ay6cI4nsv+8lViVcCjm0opR++4T0YGEMjSV4Gwt8rWb9ww7bt4SBANI8Je1goEHgv+x Uaj2gA4Uuv12Uo1t8J6gd4tCYj72VdpDnyTnnSnq0dOZre2cpWxxUdDMoX+Czz25jfSv s3wZDZDExAhk9TcN80mMsHFlfScK1ju8GMtWrrDJ5LHA6Eu4A9C0krU94Zuj+0nsHXbM CB1w== MIME-Version: 1.0 X-Received: by 10.180.211.226 with SMTP id nf2mr25027973wic.61.1413866335458; Mon, 20 Oct 2014 21:38:55 -0700 (PDT) Received: by 10.194.60.134 with HTTP; Mon, 20 Oct 2014 21:38:55 -0700 (PDT) Date: Mon, 20 Oct 2014 21:38:55 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG Content-Type: multipart/alternative; boundary=001a11c3847aaf58b70505e76873 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kdOp7-NRpLB0IoAxZG54SqwktTI Subject: [MMUSIC] SDP Mux Attributes and IANA Section - Review Section 15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 04:39:02 -0000 --001a11c3847aaf58b70505e76873 Content-Type: text/plain; charset=UTF-8 Hello All I have submitted an interim version of the "A Framework for SDP Attributes when Multiplexing" draft to get the working group inputs on handling the IANA considerations section. Please note that , this version is not yet ready for a full review as I plan to submit another version by the draft deadline. Hence i request the reviewers to provide thoughts on "Section 15" which deals with IANA considerations. Link: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-03 Many Thanks Suhas --001a11c3847aaf58b70505e76873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All
=C2=A0
=C2=A0 =C2=A0I have submitt= ed an interim version of the "A Framework for SDP Attributes when Multiplexing&= quot; draft to get the working group inputs on handling the IANA considerat= ions section.

Please note that , this version is not y= et ready for a full review as I plan to submit another version by the draft= deadline.


Hence i request the reviewers = to provide thoughts on "Section 15" which deals with IANA conside= rations.



Many Thanks
Suhas
=

--001a11c3847aaf58b70505e76873-- From nobody Mon Oct 20 23:24:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AB21AD060 for ; Mon, 20 Oct 2014 23:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHCkWcBTRGKT for ; Mon, 20 Oct 2014 23:24:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EE41A6F9D for ; Mon, 20 Oct 2014 23:24:31 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-82-5445fc1d1ddb Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.50.21334.D1CF5445; Tue, 21 Oct 2014 08:24:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 08:24:29 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic-chairs@tools.ietf.org" Thread-Topic: SDP Directorate Review: New SDP attribute sections in rfc4566bis Thread-Index: AQHP7IhQtF1PCWenvkyggMXFdC4opJw6FcMQ Date: Tue, 21 Oct 2014 06:24:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4BAC0F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4AF4E7@ESESSMB209.ericsson.se> <5444805E.8030104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4B19C3@ESESSMB209.ericsson.se> <54454148.7070407@alum.mit.edu> In-Reply-To: <54454148.7070407@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja7sH9cQg70tShb/9iZZTF3+mMVi xYYDrA7MHn/ff2DyWLLkJ5PHl8uf2QKYo7hsUlJzMstSi/TtErgyZs7/wlSwh7+icecW1gbG 7TxdjJwcEgImEldfXGeBsMUkLtxbz9bFyMUhJHCUUeL5wl4oZwmjxO4Nd9m7GDk42AQsJLr/ aYM0iAhkShw6cpwRxGYWUJF4dfoyK4gtLOAr0fD2LzNETYDEw44b7BC2kcT/oxvB6lkEVCXW NveCLeYFql/x9y0zxK6rjBJN80+DJTgFdCQ+vFsD1swIdN33U2uYIJaJS9x6Mp8J4moBiSV7 zjND2KISLx//Y4WwlSRWbL8EdZyOxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG1MEtv3V3MK5+7XiIUYCDUYmH V2Gfa4gQa2JZcWXuIUZpDhYlcd5F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBs8prs sjvF8RJ/9U6+6ClCb1cllmenLo2/2MW3vrHk4M6GI1EPb1zd1s/xPOHHxM1WIT843gktuhHV IZk8of3Kg5CHUuKNWYxPrS40cE/1XqimdCb+XL8xe8Krde1GLcVeq+fuMs+6dfMuSxXjZa/Q 7V5Bjuohr25J1rUzyQb43XJvP/7gOKcSS3FGoqEWc1FxIgBGA81+igIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ycisT38tPMw9Ym1IzgkqkwmEk0o Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] SDP Directorate Review: New SDP attribute sections in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 06:24:33 -0000 Hi, >Do you want to expand the scope of this effort to include O/A and BUNDLE >= considerations for the attributes defined in this draft? > >The pro is that this will further set an example for how future attributes= should be >defined. > >The con is that this will require reproducing, or moving, information that= is currently >defined in other drafts. If the O/A procedures for the attributes already exist elsewhere, I don't t= hink we have to move them into 4566bis. Having a reference should be enough= . Regards, Christer On 10/20/14 3:01 AM, Christer Holmberg wrote: > Hi Paul, > >>> Offer/Answer considerations: >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>> >>> Normally, when we define new SDP attributes, we are also supposed to=20 >>> define the associated Offer/Answer procedures (following the rules=20 >>> in RFC 3264). >>> >>> However, the O/A procedures are missing from the attributes defined=20 >>> in the draft, nor is it anywhere said that they must be defined for=20 >>> new attributes. >> >> Well, a number of them are covered in 3261 and 3264. > > Correct. > > My issue is more about the fact that that there is no text on specifying = the O/A procedures for new attributes. Currently we rely on the MMUSIC part= icipants/chairs and SDP directorate to make sure it's there. > > >>> BUNDLE considerations: >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Should we mandate to indicate which "category" >>> [draft-ietf-mmusic-sdp-mux-attributes] an attribute is associated with. >> >> I had the impression that the mux draft was going to do that specificati= on for all the > attributes it has considered. >> But attributes defined in the future will have to cover this. > > Correct. > > So, again, the issue is more about the guidelines and procedures for defi= ning new attributes. > > Regards, > > Christer > From nobody Mon Oct 20 23:28:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5431AD062 for ; Mon, 20 Oct 2014 23:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r74e0lkB2du6 for ; Mon, 20 Oct 2014 23:28:36 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC46B1AD060 for ; Mon, 20 Oct 2014 23:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2575; q=dns/txt; s=iport; t=1413872917; x=1415082517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yVD31FPNftJtd8bVTHvqz6I+yz0dm1xIklyLVDcfc/c=; b=CBs5wKOoZ1vUTU/arDU+l4EwdbtXB+7XKVENGUbH39IRvXzmSUx0TjgP lXzd3NAmYe4cuzq33U0z+8TWWlFcPJ/byw1QDO1F893d9BCsuNfdCIB0F nfVya0uOjlMfU/gwywyfRMcnflnBMttK/gdA17kBOsuzf+v0gKZnJVzDO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAKj6RVStJV2a/2dsb2JhbABcgmsjU1gEzAUKhnlUAoEOFgF9hAIBAQEDAQEBATc0CwULAgEIGB4QJwslAQEEDgWINwgBDMR0AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQHjMHgy2BHgWSAYtZliKDd2yBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,760,1406592000"; d="scan'208";a="88876696" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 21 Oct 2014 06:28:36 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9L6SaLM020091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 06:28:36 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 01:28:35 -0500 From: "Ali C. Begen (abegen)" To: Christer Holmberg Thread-Topic: [MMUSIC] SDP Directorate Review: New SDP attribute sections in rfc4566bis Thread-Index: Ac/r90f99G+9E6sCTjqmqeYmTBonlQAR/NcAAAeWhAAAFSiTAAAb1u0AAAAkzoA= Date: Tue, 21 Oct 2014 06:28:35 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4AF4E7@ESESSMB209.ericsson.se> <5444805E.8030104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4B19C3@ESESSMB209.ericsson.se> <54454148.7070407@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BAC0F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4BAC0F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.104.176] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jAo7KY4kB9C8PJvnaEj9_53qMAo Cc: "mmusic-chairs@tools.ietf.org" , IETF MMUSIC WG , Paul Kyzivat Subject: Re: [MMUSIC] SDP Directorate Review: New SDP attribute sections in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 06:28:38 -0000 > On Oct 21, 2014, at 8:24 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >> Do you want to expand the scope of this effort to include O/A and BUNDLE= >considerations for the attributes defined in this draft? >>=20 >> The pro is that this will further set an example for how future attribut= es should be >defined. >>=20 >> The con is that this will require reproducing, or moving, information th= at is currently >defined in other drafts. >=20 > If the O/A procedures for the attributes already exist elsewhere, I don't= think we have to move them into 4566bis. Having a reference should be enou= gh. Except 3264 I am not aware of any. And individual attributes defined their = own stuff. I think Paul is asking for an example or some sort of illustrati= on for the new drafts defining attributes. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 10/20/14 3:01 AM, Christer Holmberg wrote: >> Hi Paul, >>=20 >>>> Offer/Answer considerations: >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>>=20 >>>> Normally, when we define new SDP attributes, we are also supposed to=20 >>>> define the associated Offer/Answer procedures (following the rules=20 >>>> in RFC 3264). >>>>=20 >>>> However, the O/A procedures are missing from the attributes defined=20 >>>> in the draft, nor is it anywhere said that they must be defined for=20 >>>> new attributes. >>>=20 >>> Well, a number of them are covered in 3261 and 3264. >>=20 >> Correct. >>=20 >> My issue is more about the fact that that there is no text on specifying= the O/A procedures for new attributes. Currently we rely on the MMUSIC par= ticipants/chairs and SDP directorate to make sure it's there. >>=20 >>=20 >>>> BUNDLE considerations: >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> Should we mandate to indicate which "category" >>>> [draft-ietf-mmusic-sdp-mux-attributes] an attribute is associated with= . >>>=20 >>> I had the impression that the mux draft was going to do that specificat= ion for all the > attributes it has considered. >>> But attributes defined in the future will have to cover this. >>=20 >> Correct. >>=20 >> So, again, the issue is more about the guidelines and procedures for def= ining new attributes. >>=20 >> Regards, >>=20 >> Christer >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Oct 21 00:53:47 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5B91AD0C5 for ; Tue, 21 Oct 2014 00:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sgwe47pUF6f for ; Tue, 21 Oct 2014 00:53:44 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 331331AD0A8 for ; Tue, 21 Oct 2014 00:53:04 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 1DF891EB8469; Tue, 21 Oct 2014 09:53:04 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 09:53:03 +0200 From: "Stach, Thomas" To: Parthasarathi R , 'Christer Holmberg' , =?iso-8859-1?Q?=27Ari_Ker=E4nen=27?= , 'mmusic' Thread-Topic: [MMUSIC] ICE updated offer - Back to the initial question Thread-Index: AQHP7MVSXZxlbIIG/kKVaQY9SbghrJw6K5PA Date: Tue, 21 Oct 2014 07:53:02 +0000 Message-ID: References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se> <009501cfecc5$48d513f0$da7f3bd0$@co.in> In-Reply-To: <009501cfecc5$48d513f0$da7f3bd0$@co.in> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tfJCunS8dllTCDUwuNxW72cEG_c Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 07:53:46 -0000 Partha, >=20 > Hi Thomas, >=20 > Could you please mention the exact 3PCC callflow which breaks because of > the ICE second offer.=20 You might want to look into http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#section= -3.1 > Of course ideally, it should have covered in ICE (RFC > 5245). We could cover this in ICEbis though. >=20 > Early dialog will not work without PRACK (RFC 3264) in the single > offer/answer itself. In case you assume that 18x is reliable without PRAC= K > then it has lot of caveat as the intermediate SIP entities may use UDP as= a > transport wherein UAS has no control over.=20 RC5245 has already covered this Regards Thomas > I assume that you intent to say > that UPDATE (RFC 3311) is mandated in case of RFC 5245 second offer. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Stach, > > Thomas > > Sent: Monday, October 20, 2014 8:03 PM > > To: Christer Holmberg; Ari Ker=E4nen; mmusic > > Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question > > > > Christer, > > > > I'm trying to understand ... > > ... and disagree with your last point > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Freitag, 17. Oktober 2014 12:01 > > > To: Stach, Thomas; Ari Ker=E4nen; mmusic > > > Subject: RE: [MMUSIC] ICE updated offer - Back to the initial > > question > > > > > > Hi, > > > > > > Whatever decisions are made at the meetings must (or, at least that > > seem to > > > be de facto practise) be confirmed on the mailing list. So, it is ok > > to > > > challenge them (luckily that doesn't happen too often, though - at > > least > > > not within the groups where I participate). > > > > > > >Proposal A: Indicate in the ANSWER whether the second offer is > > needed or > > > not. > > > >Proposal B: If you need the update, send an offerless re-INVITE with > > a > > > flag > > > > that suppresses an ICE restart, > > > > but triggers the ICE updated offer instead. > > > > > > Using SIP terminology (as this mechanism could only be used with SIP > > > anyway), the second offer will almost always be send during an early > > > dialog, while the initial INVITE transaction is still ongoing. > > [TS] You seem to assume support for PRACK here. > > Of course, the offerless re-INVITE could not be used as a trigger for > > the new offer in this case. > > You would need "something else" in such an environment. > > The offerless INVITE, nevertheless, sounds attractive to me for other > > environments, since it only requires basic RFC3261 functionality. > > > You cannot send a re-INVITE during that time, so it wouldn't work. > > [TS] If PRACK is not supported, you also couldn't send that second > > offer during the early dialog. > > > Sending the re- > > > INVITE once the call has been established could prevent early media, > > [TS] So, if the offerer does support ICE but not PRACK, it wouldn't get > > early media, even if the connectivity checks were successful? > > Do you assume support for preconditions in addition to PRACK? > > > and > > > any other information transported on the media plane during the early > > > dialog phase. > > > > > > >Proposal C: The signaling entity should inform the media entity > > about > > > > the candidates. The media entity can then learn through > > the > > > > STUN checks which address is eventually used for media. > > > > > > That might work if the media entity is STUN aware (and if the > > > interface/protocol used to control the media entity supports > > transporting > > > that kind of information). Often they are not. They are simply used > > to e.g. > > > enforce bandwidth (and other network resources) and gating. > > > > > > > Are there additional proposals or do we want to choose from these? > > > > > > One is to keep everything as it is today, as nothing is broken. > > [TS] I beg to disagree here. I repeatedly mentioned that certain 3PCC > > call flows break _due_ to the updated offer. > > Regards > > Thomas > > > Nobody has indicated that as a preference, though. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > -----Original Message----- > > > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari > > Ker=E4nen > > > > Sent: Dienstag, 14. Oktober 2014 10:15 > > > > To: mmusic > > > > Subject: [MMUSIC] ICE updated offer > > > > > > > > Hi all, > > > > > > > > At the Toronto meeting we discussed whether we should change the > > > > behavior with ICE updated offer. Currently, based on RFC 5245, when > > > > ICE has finished, there is a new offer/answer with the selected > > > > candidate, > > > > *if* they are different from the "default candidates", i.e., the > > ones > > > > in original o/a m- and c-lines. > > > > > > > > Based on the discussion there was strong desire to have an option > > of > > > > not doing the updated o/a at all by indicating this in the original > > > > o/a. On the other hand, for some, the updated o/a was seen as a > > > > requirement for getting correct behavior from the network in > > certain > > > > scenarios (e.g., with SIP-aware middle boxes). > > > > > > > > I would like to hear from people, who have issues making the > > updated > > > > o/a optional, how bad the change would be and is there a way we > > could > > > > make this work also in those scenarios? > > > > > > > > > > > > Cheers, > > > > Ari > > > > > > > > _______________________________________________ > > > > 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 nobody Tue Oct 21 02:46:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632C31A049A for ; Tue, 21 Oct 2014 02:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO9W9GOqZ-MC for ; Tue, 21 Oct 2014 02:46:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5042B1A026A for ; Tue, 21 Oct 2014 02:44:05 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-1a-54462ae3cc2d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 80.34.21334.3EA26445; Tue, 21 Oct 2014 11:44:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 11:44:03 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments Thread-Index: Ac/quUI/xECKSzhxQBSQKARMMFph+ABvWmSAACBV85A= Date: Tue, 21 Oct 2014 09:44:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4BB448@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> <54453FD1.9070207@alum.mit.edu> In-Reply-To: <54453FD1.9070207@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje4TLbcQg3VH+C2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjz4xpjAWTrSv2/lvD1MB4T6+LkZNDQsBE 4syk9YwQtpjEhXvr2boYuTiEBI4ySux7toAJwlnCKNF84BZQhoODTcBCovufNogpIqAhMWmr Gkgvs4CKxKvTl1lBwsICsRKbVpeDhEUE4iSmrn7CDGFbSew8tpoNxGYRUJXo+zKXFcTmFfCV aH7QCRYXEsiXOHFrJ9g5nAI6EheePgCzGYFO+35qDRPEKnGJW0/mM0GcLCCxZM95ZghbVOLl 43+sELaSxNrD21kg6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzUIydhaSlllIWmYhaVnA yLKKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzB2Dm75rbuDcfVrx0OMAhyMSjy8CvtcQ4RY E8uKK3MPMUpzsCiJ8y46Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6P8EgkZlw2eDO/4 476F/jv/WLLzs+/lt1azr9WJH7RuivnScOXLjI7WJT+rP1yXl04smTjhQsSEYMOVegclakOP zbF0e3y8Vf2YQeYl4eo+xr9ROyO588MEFvR5XI5a/OKlYeX73YyzA3esD+Xsm3BP09Rah+ts sXPt/vZcfQuHc/1HL/DWvVViKc5INNRiLipOBABaem8UfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2jA6_FI9qYNnZYyxlchZfh6KCq4 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 09:46:50 -0000 Hi, ------------------------- >>> * Section 2: Terminology >>> >>> In the following: >>> >>> BUNDLE group: A set of "m=3D" lines, created using an SDP Offer/Ans= wer >>> exchange, for which each endpoint uses a single 5-tuple to send and >>> receive media. Each endpoint uses its BUNDLE address, associated >>> with the BUNDLE group, to send and receive the media. >>> >>> are we *requiring* symmetric media usage? Certainly you must *receive* = on your bundle=20 >>> address, but AFAIK *sending* on that address is, in general, optional t= hough various=20 >>> options that might be used with it (such as ICE) may require it. >> >> The definition of "BUNDLE address" states that the address is used for b= oth sending and receiving media. > > This is a little fuzzy. That is mentioned in the Intro, but not in the Te= rminology definitions of Offerer/Answerer=20 > BUNDLE address. It is mentioned in the definition of BUNDLE group, but no= t in a normative way. > > If you really intend to require this, then it should be stated more clear= ly in a normative way. I checked the definitions for "Offerer BUNDLE address" and "Answerer BUNDLE= address", and you are correct that the text only talks about receiving med= ia. So, that would have to be fixed. ...unless, of course, we'd choose to NOT mandate symmetric media (obviously= , the sender would still need to use a single address:port for sending all = media associated with the BUNDLE group). ------------------------- >>> * Section 7.3: Bandwidth >>> >>> Says: >>> >>> The total proposed bandwidth for a BUNDLE group is the sum of the >>> proposed bandwidth for each bundled "m=3D" line. >>> >>> What if some of the bundled m-lines have no b=3D line, while others do?= It probably=20 >>> doesn't make sense to treat them as having zero bandwidth. I guess mayb= e some=20 >>> default value should be used. But what? >> >> You do whatever you'd do for a non-BUNDLED "m=3D" line. Normally I guess= you have=20 >> a default value, or a value based on the media type and/or payload forma= ts. > > I think this requires discussion with people that know more about this to= pic. I think we had discussions about this in the past, and the outcome was that= you calculate the bandwidth in the same way as you would for non-bundled m= - lines. > AFAIK, with non-bundled m-lines that don't specify, there is no specific = limit unless there=20 > is a session-level b-line. I don't know what happens if there is a sessio= n-level b-line. I guess there is supposed to be a default for every codec. I don't think it's up to the BUNDLE spec to define what a missing b- line m= eans. ------------------------- >>> Or, I guess there could be a rule that if any of the bundled m-lines ha= ve b=3D then all of them must. >>> >>> Also, I guess there needs to be a separate sum for each bandwidth type. >>> >>> Note: this is also an issue for draft-ietf-mmusic-sdp-mux-attributes. >>> >>> I note that section 7.3 defers to=20 >>> draft-ietf-mmusic-sdp-mux-attributes >>> for attribute bundling rules. >> >> I assume you mean section 7.4? > > Yup. >=20 >>> Perhaps this section should similarly defer to that draft for bandwidth= bundling. >> >> The "b=3D" parameter is not covered by that draft (as it's not an SDP at= tribute). > > Ah! So this draft is on its own. It seems like more text is needed.=20 > Especially what to do with extension bandwidth types. I'm not really sure what text would have to be added, so I'd need some inpu= t on that. ------------------------- >>> * Section 8.2.2: Request offerer BUNDLE address selection >>> >>> I think the name of this section is slightly confusing - "Request" coul= d be a verb (intended) or a noun. I suggest changing it to: >>> >>> "Suggesting an offerer BUNDLE address" >> >> I use "Request" in other places (e.g. "offerer requested the BUNDLE grou= p") so I'd like to keep the text. >> >> In addition, aren't you the one who suggested "Request" terminology in=20 >> the past? :) > > I don't remember. In any case it is a hard statement to parse. If you wan= t to keep the term, how=20 > about "Requesting offerer BUNDLE address selection"? (But I still think "= Suggesting" is clearer.) Then we would have to change the section 8.5.2 title ("Request a new offere= r BUNDLE address") too. And, in section 8.5.1 there is a sentence saying: "o The offerer wants to request the answerer to select a new offerer BUNDLE address [Section 8.5.2];" And, there is other text where "request" is used, e.g. when talking about r= equesting a BUNDLE group to be created etc. Etc. One option, which is also more aligned with the 8.5.2 title, would be to sa= y: "Request an offerer BUNDLE address" (or "Request the offerer BUNDLE addre= ss") ...i.e. add "an" (or "the") and remove "selection".=20 ------------------------- >>> * Section 8.3.2: Answerer Selection of Offerer Bundle Address >>> >>> I have a few wording changes to suggest for clarity: >>> >>> In this section, the use of 'the "m=3D" line' seems a little vague. I t= hink it would be better to change it to 'that "m=3D" line' throughout. >> >> I do agree that we could use the following modified sentence: >> >> "The answerer MUST check whether that "m=3D" line fulfils the following= criteria:" > > s/fulfils/fulfills/ Correct. >>> Also >>> - s/fulfils/fulfills/ >>> - s/criteria above is fulfilled/criteria above are fulfilled/ >>> - s/criteria is not fulfilled/criteria are not fulfilled/ >>> - s/represents/identifies/ >> >> OK. Here I'd actually like to keep "represents", because that is the wording us= ed elsewhere in the document. ------------------------- >>> Another thing: I *think* that *plain* RTP can also coexist with STUN,=20 >>> DTLS, and SRTP using the rules of RFC5764. (Can somebody confirm if=20 >>> this is true?) >> >> I'll ask Colin. > > Sounds good. I've sent him an e-mail. ------------------------- >>> Also, there is *no* mention of SCTP in this document. ISTM that there s= hould be=20 >>> something. I guess the 2nd paragraph here is intended to cover that. If= so, it is too subtle. >> >> The document does not cover SCTP - unless it is transported on top of DT= LS, in which case it is implicitly covered by the 2nd paragraph. >> >> What would you like to mention about SCTP? >> >>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't use D= TLS payload=20 >>> packets. So *one* m-line with a protocol that uses DTLS payload packets= (e.g., >DTLS/SCTP) can=20 >>> coexist with STUN and SRTP. If there is more than one such m-line then = some other specification is=20 >>> required to associate those packets with m-lines. >> >> I think that is covered, as SRTP is distinguished from DTLS. >> >> But, if you think that needs to be more clear, maybe the following modif= ied sentence: >> >> "[RFC5764] does not describe how to identify different protocols transp= orted on DTLS (i.e. using DTLS payload packets), only how to..." > > I think this document should bite the bullet and define how SCTP coexists= with SRTP in a bundle. Personally, I would not want to do that at this stage. We decided earlier t= hat the draft will cover DTLS, SRTP and STUN, and that any other protocols/= combinations have to be defined elsewhere. ------------------------- Regards, Christer From nobody Tue Oct 21 03:12:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC461A0262 for ; Tue, 21 Oct 2014 03:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqStH0B383or for ; Tue, 21 Oct 2014 03:11:55 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135E21A0172 for ; Tue, 21 Oct 2014 03:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1212; q=dns/txt; s=iport; t=1413886315; x=1415095915; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Bwo4c36JGU0sIU136ahA3TTvS1xF3rp9uuFo4XGTfTY=; b=QT5teKik2txC6a6D8hUZTC0PPeGJYQ5EQ0unLv9Lny84LxknedLvstyI LgLQJ9m2VlW0e9jmtMer0r5mURAsSvl4gSTSYD3nwrF3VdzkG4IMgN8IK GIUEbBiqiLgCTlJxnjmPl6r2OXnYUSikOsZGzHm5g67y72FUhQTkyy6Re I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgNAMQjRlStJV2d/2dsb2JhbABcgw5TWATMDAyGd08BAgEBAoEPFgF9hAMBAQMBAQEBaxALAgFOJwslAgQTiDcIDcNJAQEBAQEBBAEBAQEBAQEBAQEBF5BYgy2BHgWLJIZdhEaHE4FslDaDd2yBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,761,1406592000"; d="scan'208";a="88934861" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 21 Oct 2014 10:11:55 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9LABsmW004028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Oct 2014 10:11:54 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 05:11:54 -0500 From: "Pal Martinsen (palmarti)" To: mmusic Thread-Topic: ICE Dual Stack Fairness (was: [MMUSIC] Milestones changed for mmusic WG) Thread-Index: AQHP7Rdw/rYu3a0WH0m6pm54RFTv1w== Date: Tue, 21 Oct 2014 10:11:53 +0000 Message-ID: <761C04CA-32BA-4BF9-87DE-A8EFED61105C@cisco.com> References: <20141017222826.30724.11722.idtracker@ietfa.amsl.com> In-Reply-To: <20141017222826.30724.11722.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.85.122] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YraXgWHiPkUCZSqqvElSyf9npVE Subject: [MMUSIC] ICE Dual Stack Fairness (was: Milestones changed for mmusic WG) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 10:12:01 -0000 Hi mmusic, We submitted a new draft that we believe cover the new milestone. https://tools.ietf.org/html/draft-martinsen-mmusic-ice-dualstack-fairness-0= 0 It is a renamed version of the ICE Happy Eyeballs draft. We move away from = what people usually regard as happy eyeball functionality so a name change = seemed to be appropriate. Also added the following text: Implementations are encouraged to prioritize IPv6 candidates by putting some of them first in the the intermingled checklist. This increases the chance of a IPv6 connectivity checks to complete first and be ready for nomination or usage. Seems like a good idea to at least hint that IPv6 is coming and we should d= o what we can to help adoption. .-. P=E5l-Erik =20 On 18 Oct 2014, at 00:28, IETF Secretariat wrote: > Changed milestone "Submit Dual-stack Fairness with ICE as Proposed > Standard ", set state to active from review, accepting new milestone. >=20 > URL: http://datatracker.ietf.org/wg/mmusic/charter/ >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Oct 21 03:18:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4B71A0372 for ; Tue, 21 Oct 2014 03:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-L4P-ZiOuDd for ; Tue, 21 Oct 2014 03:18:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D041A02BE for ; Tue, 21 Oct 2014 03:18:29 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-b4-544632f32afc Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 64.1A.21334.3F236445; Tue, 21 Oct 2014 12:18:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 12:18:27 +0200 From: Christer Holmberg To: "Stach, Thomas" , Parthasarathi R , =?iso-8859-1?Q?Ari_Ker=E4nen?= , 'mmusic' Thread-Topic: [MMUSIC] ICE updated offer - Back to the initial question Thread-Index: AQHP7MVS4aHJyTDnkUCd35W9NL3+Xpw6DQIAgABG0OA= Date: Tue, 21 Oct 2014 10:18:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4BB52D@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se> <009501cfecc5$48d513f0$da7f3bd0$@co.in> 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.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje5nI7cQgzn3jSymLn/MYjH5Ux+r xcmd25gdmD2WLPnJ5PFh/hd2j+09j1kCmKO4bFJSczLLUov07RK4Mt427GQp2G9SceJQdQPj Ro0uRg4OCQETiRuPLLsYOYFMMYkL99azdTFycQgJHGWU+HbkO5SzhFFiwvOD7CANbAIWEt3/ tEHiIgJbGSV2PF3GBNItLOAmsfboLFYQW0TAXWJhyzJ2CNtK4nBfOyOIzSKgKvGi6wzYHF4B X4lPu8oh5r9gknh2/TQLSA2ngL9E4/qZbCA2I9BF30+tAZvPLCAucevJfCaISwUkluw5zwxh i0q8fPyPFcJWklh7eDsLRL2exI2pU9ggbG2JZQtfg9XzCghKnJz5hGUCo+gsJGNnIWmZhaRl FpKWBYwsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECI+fglt+6OxhXv3Y8xCjAwajEw6uw zzVEiDWxrLgy9xCjNAeLkjjvonPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwprQcKQtV NvV4l7b4xdfzeWbBvYU3ldZ97ax+sD3f7r77j3+d11T+pqceaPto+tPsm4HO8tcqXj7T9hmI f2cxqXgreu311/7JJnb3LQxOlYn2d79kv2Vdtk/B+NlJuf9WZ+wVbXzlNV9+Crf7otB49N09 2wmcS5d8jdZM4WdocL35PnP1HY5JSizFGYmGWsxFxYkAxWRHAH0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/s95L-4VagjrTluojSQyFBkM6Zn0 Subject: Re: [MMUSIC] ICE updated offer - Back to the initial question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 10:18:33 -0000 Hi, >> Could you please mention the exact 3PCC callflow which breaks because=20 >> of the ICE second offer. > You might want to look into > http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#secti= on-3.1 The text in that draft says: "The B2BUA cannot pass that request on until the INVITE transaction=20 with UA2 has completed." This is only true if PRACK is not supported. In 5245 we did a hack, allowing to send the "answer" in unreliable 18x. The= justification was that "people don't implement PRACK". Perhaps, as part of= the bis work, we should check whether that justification is still valid.=20 Regards, Christer > Of course ideally, it should have covered in ICE (RFC 5245). We could cover this in ICEbis though. >=20 > Early dialog will not work without PRACK (RFC 3264) in the single=20 > offer/answer itself. In case you assume that 18x is reliable without=20 > PRACK then it has lot of caveat as the intermediate SIP entities may=20 > use UDP as a transport wherein UAS has no control over. RC5245 has already covered this Regards Thomas > I assume that you intent to say > that UPDATE (RFC 3311) is mandated in case of RFC 5245 second offer. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Stach,=20 > > Thomas > > Sent: Monday, October 20, 2014 8:03 PM > > To: Christer Holmberg; Ari Ker=E4nen; mmusic > > Subject: Re: [MMUSIC] ICE updated offer - Back to the initial=20 > > question > > > > Christer, > > > > I'm trying to understand ... > > ... and disagree with your last point > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Freitag, 17. Oktober 2014 12:01 > > > To: Stach, Thomas; Ari Ker=E4nen; mmusic > > > Subject: RE: [MMUSIC] ICE updated offer - Back to the initial > > question > > > > > > Hi, > > > > > > Whatever decisions are made at the meetings must (or, at least=20 > > > that > > seem to > > > be de facto practise) be confirmed on the mailing list. So, it is=20 > > > ok > > to > > > challenge them (luckily that doesn't happen too often, though - at > > least > > > not within the groups where I participate). > > > > > > >Proposal A: Indicate in the ANSWER whether the second offer is > > needed or > > > not. > > > >Proposal B: If you need the update, send an offerless re-INVITE=20 > > > >with > > a > > > flag > > > > that suppresses an ICE restart, > > > > but triggers the ICE updated offer instead. > > > > > > Using SIP terminology (as this mechanism could only be used with=20 > > > SIP anyway), the second offer will almost always be send during an=20 > > > early dialog, while the initial INVITE transaction is still ongoing. > > [TS] You seem to assume support for PRACK here. > > Of course, the offerless re-INVITE could not be used as a trigger=20 > > for the new offer in this case. > > You would need "something else" in such an environment. > > The offerless INVITE, nevertheless, sounds attractive to me for=20 > > other environments, since it only requires basic RFC3261 functionality. > > > You cannot send a re-INVITE during that time, so it wouldn't work. > > [TS] If PRACK is not supported, you also couldn't send that second=20 > > offer during the early dialog. > > > Sending the re- > > > INVITE once the call has been established could prevent early=20 > > > media, > > [TS] So, if the offerer does support ICE but not PRACK, it wouldn't=20 > > get early media, even if the connectivity checks were successful? > > Do you assume support for preconditions in addition to PRACK? > > > and > > > any other information transported on the media plane during the=20 > > > early dialog phase. > > > > > > >Proposal C: The signaling entity should inform the media entity > > about > > > > the candidates. The media entity can then learn=20 > > > > through > > the > > > > STUN checks which address is eventually used for media. > > > > > > That might work if the media entity is STUN aware (and if the=20 > > > interface/protocol used to control the media entity supports > > transporting > > > that kind of information). Often they are not. They are simply=20 > > > used > > to e.g. > > > enforce bandwidth (and other network resources) and gating. > > > > > > > Are there additional proposals or do we want to choose from these? > > > > > > One is to keep everything as it is today, as nothing is broken. > > [TS] I beg to disagree here. I repeatedly mentioned that certain=20 > > 3PCC call flows break _due_ to the updated offer. > > Regards > > Thomas > > > Nobody has indicated that as a preference, though. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > -----Original Message----- > > > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari > > Ker=E4nen > > > > Sent: Dienstag, 14. Oktober 2014 10:15 > > > > To: mmusic > > > > Subject: [MMUSIC] ICE updated offer > > > > > > > > Hi all, > > > > > > > > At the Toronto meeting we discussed whether we should change the=20 > > > > behavior with ICE updated offer. Currently, based on RFC 5245,=20 > > > > when ICE has finished, there is a new offer/answer with the=20 > > > > selected candidate, > > > > *if* they are different from the "default candidates", i.e., the > > ones > > > > in original o/a m- and c-lines. > > > > > > > > Based on the discussion there was strong desire to have an=20 > > > > option > > of > > > > not doing the updated o/a at all by indicating this in the=20 > > > > original o/a. On the other hand, for some, the updated o/a was=20 > > > > seen as a requirement for getting correct behavior from the=20 > > > > network in > > certain > > > > scenarios (e.g., with SIP-aware middle boxes). > > > > > > > > I would like to hear from people, who have issues making the > > updated > > > > o/a optional, how bad the change would be and is there a way we > > could > > > > make this work also in those scenarios? > > > > > > > > > > > > Cheers, > > > > Ari > > > > > > > > _______________________________________________ > > > > 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 nobody Tue Oct 21 07:53:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210E01A86EE for ; Tue, 21 Oct 2014 07:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToxRrN0Qb9pW for ; Tue, 21 Oct 2014 07:53:51 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CDB1A86F6 for ; Tue, 21 Oct 2014 07:53:51 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so1197473lab.16 for ; Tue, 21 Oct 2014 07:53:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rxWcphY8tBfbX8k1zrwPI/z4a67fzFUGcJYgzC8XRro=; b=KfVFhuplxutxMtdOHTjjsbIavWDlXg8UuhYD4p64zymZhWBY1YmCZhDoMjAu6S8Lcc LKOJdmm7WDzn13N4vyrtFShB2kMdNAXOefgFHWXZC7VVT71Jd2Rr2d7qlScyxvVidAnz Nx3xMEY2ipoE+M+TF0mBwZP8yw19T2OZlpl4cwobhrQKrSdOeVbY8QiaPW+dXWuK/a3x FWj+kFpUo+Gytuns1QDh2cSGrJpFFSBGLsbyTYEPwlHFzL0a/36jh0XuLmi7sed5Jmqd GLBPxrOHkAqqjv6gfK7bY1xaMI/RtFA6KuDn4MPJvGQADDH9IOPBFk0a44xyIBbuSbi+ 493Q== X-Gm-Message-State: ALoCoQkuoH3p7g9oRzBRHmzcuc016OV7ZvbFvoyyGD291Lg3jtDf6fY6hMnH2rn8opN25O9CjXQd MIME-Version: 1.0 X-Received: by 10.152.5.129 with SMTP id s1mr16174324las.59.1413903227730; Tue, 21 Oct 2014 07:53:47 -0700 (PDT) Received: by 10.25.137.9 with HTTP; Tue, 21 Oct 2014 07:53:47 -0700 (PDT) In-Reply-To: <761C04CA-32BA-4BF9-87DE-A8EFED61105C@cisco.com> References: <20141017222826.30724.11722.idtracker@ietfa.amsl.com> <761C04CA-32BA-4BF9-87DE-A8EFED61105C@cisco.com> Date: Tue, 21 Oct 2014 08:53:47 -0600 Message-ID: From: Simon Perreault To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=089e013d175ca2d6bf0505efff0c Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ogdYKSSHE5p1_8XkT2XKXn433Fc Cc: mmusic Subject: Re: [MMUSIC] ICE Dual Stack Fairness (was: Milestones changed for mmusic WG) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 14:53:54 -0000 --089e013d175ca2d6bf0505efff0c Content-Type: text/plain; charset=UTF-8 On Tue, Oct 21, 2014 at 4:11 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > We submitted a new draft that we believe cover the new milestone. > > > https://tools.ietf.org/html/draft-martinsen-mmusic-ice-dualstack-fairness-00 > I just read this for the first time. Forgive me if this has been discussed before... As an implementer I would prefer if there was "the one true" algorithm that I can go and implement and not have to think. Having an example algorithm in an appendix makes me uneasy. If the algorithm is not contentious, why not make it normative? Thanks, Simon --089e013d175ca2d6bf0505efff0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Oct 21, 2014 at 4:11 AM, Pal Martinsen (palmarti) <palmarti@cisco= .com> wrote:
We submitted a new draft that we= believe cover the new milestone.

https://tools.ietf.org/html/draft-martinsen= -mmusic-ice-dualstack-fairness-00

I just re= ad this for the first time. Forgive me if this has been discussed before...= As an implementer I would prefer if there was "the one true" alg= orithm that I can go and implement and not have to think. Having an example= algorithm in an appendix makes me uneasy. If the algorithm is not contenti= ous, why not make it normative?

<= div class=3D"gmail_extra">Thanks,
Simon
--089e013d175ca2d6bf0505efff0c-- From nobody Tue Oct 21 08:48:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15011A88BC for ; Tue, 21 Oct 2014 08:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRw_sRtr4PFM for ; Tue, 21 Oct 2014 08:48:39 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3E81A8882 for ; Tue, 21 Oct 2014 08:48:14 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-09v.sys.comcast.net with comcast id 5roA1p00C54zqzk01roENk; Tue, 21 Oct 2014 15:48:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id 5roD1p0093Ge9ey01roDJ9; Tue, 21 Oct 2014 15:48:14 +0000 Message-ID: <5446803D.80405@alum.mit.edu> Date: Tue, 21 Oct 2014 11:48:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> <54453FD1.9070207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BB448@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4BB448@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413906494; bh=Gf0QhBYTUi2tVmfxpanobeYOqorWJra08RpO+bnCgk0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IOumFhIGTosj5gJnJgbpcZ8yDXmckLBcx/sz+UwG+mIw6A+fA44C/EULRPeVF/tfY EhNQq4TKSmYDJ/NGo9+hGXGoqq5xvhIFe2pry0ZC4GBgjEFLGLHQ3B5NBHo7vxdGS/ OrBvotWmO9MqBP2744RJW1BxKQo7DeUHMR2aqT2kSQ3dWbt16od4Q/TOz1qFlW/g8l VOVoHGho571paRPlr5vuuXOnL4VpVriBUK/yLtxdoAR4sLRJTooCsV54rYp4gsJeqw DMZ16pHBjaunXE6G71sMTB0M4DdrNy6xZ5fvZTPSNipFZNhjCINzb1tapuHnlzMNQA rsUkgQGqDv7tA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ogijdQo-HAHJIhbHpRqSnmvgnHk Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 15:48:41 -0000 Christer, More inline. On 10/21/14 5:44 AM, Christer Holmberg wrote: > Hi, > > ------------------------- > >>>> * Section 2: Terminology >>>> >>>> In the following: >>>> >>>> BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer >>>> exchange, for which each endpoint uses a single 5-tuple to send and >>>> receive media. Each endpoint uses its BUNDLE address, associated >>>> with the BUNDLE group, to send and receive the media. >>>> >>>> are we *requiring* symmetric media usage? Certainly you must *receive* on your bundle >>>> address, but AFAIK *sending* on that address is, in general, optional though various >>>> options that might be used with it (such as ICE) may require it. >>> >>> The definition of "BUNDLE address" states that the address is used for both sending and receiving media. >> >> This is a little fuzzy. That is mentioned in the Intro, but not in the Terminology definitions of Offerer/Answerer >> BUNDLE address. It is mentioned in the definition of BUNDLE group, but not in a normative way. >> >> If you really intend to require this, then it should be stated more clearly in a normative way. > > I checked the definitions for "Offerer BUNDLE address" and "Answerer BUNDLE address", and you are correct that the text only talks about receiving media. > > So, that would have to be fixed. > > ...unless, of course, we'd choose to NOT mandate symmetric media (obviously, the sender would still need to use a single address:port for sending all media associated with the BUNDLE group). In general I prefer not to impose unnecessary restrictions. So unless there is come compelling reason to require symmetric media I would rather not. Of course some usages (e.g., ICE) will still require it, but that is up to them, not bundle. But I'm willing to listen to reasons why this is required for bundle. > ------------------------- > >>>> * Section 7.3: Bandwidth >>>> >>>> Says: >>>> >>>> The total proposed bandwidth for a BUNDLE group is the sum of the >>>> proposed bandwidth for each bundled "m=" line. >>>> >>>> What if some of the bundled m-lines have no b= line, while others do? It probably >>>> doesn't make sense to treat them as having zero bandwidth. I guess maybe some >>>> default value should be used. But what? >>> >>> You do whatever you'd do for a non-BUNDLED "m=" line. Normally I guess you have >>> a default value, or a value based on the media type and/or payload formats. >> >> I think this requires discussion with people that know more about this topic. > > I think we had discussions about this in the past, and the outcome was that you calculate the bandwidth in the same way as you would for non-bundled m- lines. > >> AFAIK, with non-bundled m-lines that don't specify, there is no specific limit unless there >> is a session-level b-line. I don't know what happens if there is a session-level b-line. I guess there is supposed to be a default for every codec. > > I don't think it's up to the BUNDLE spec to define what a missing b- line means. If bundle forces a new concern, where there was none in the past, then bundle needs to say what to do about it. So I think *something* needs to be said. It might not be complicated. > ------------------------- > >>>> Or, I guess there could be a rule that if any of the bundled m-lines have b= then all of them must. >>>> >>>> Also, I guess there needs to be a separate sum for each bandwidth type. >>>> >>>> Note: this is also an issue for draft-ietf-mmusic-sdp-mux-attributes. >>>> >>>> I note that section 7.3 defers to >>>> draft-ietf-mmusic-sdp-mux-attributes >>>> for attribute bundling rules. >>> >>> I assume you mean section 7.4? >> >> Yup. >> >>>> Perhaps this section should similarly defer to that draft for bandwidth bundling. >>> >>> The "b=" parameter is not covered by that draft (as it's not an SDP attribute). >> >> Ah! So this draft is on its own. It seems like more text is needed. >> Especially what to do with extension bandwidth types. > > I'm not really sure what text would have to be added, so I'd need some input on that. The current text says to sum the bandwidth across all the m-lines in the bundle. At the least, it should say that the sum must be done separately for bandwidth types CT and AS, and if any other types have been defined then for them too. I don't really understand these, or how they are used. From reading 4566 I *think* that CT is only used at session level. If so, then it is not a concern for bundle. So that should be stated (if it is true). So maybe it is only AT type that can appear in a bundle. I don't find anything in 4566 about summing bandwidth values across m-lines. It says "CT gives a total bandwidth figure for all the media at all sites", but I don't think there is any expectation that the sum of the AT values for individual m-lines are bounded by that. My impression is that it might be quite reasonable for that sum to exceed the CT value, because they may not all be used concurrently. I'm out of my depth regarding bandwidth specification and enforcement. Can we get somebody who knows about this stuff to comment? > ------------------------- > >>>> * Section 8.2.2: Request offerer BUNDLE address selection >>>> >>>> I think the name of this section is slightly confusing - "Request" could be a verb (intended) or a noun. I suggest changing it to: >>>> >>>> "Suggesting an offerer BUNDLE address" >>> >>> I use "Request" in other places (e.g. "offerer requested the BUNDLE group") so I'd like to keep the text. >>> >>> In addition, aren't you the one who suggested "Request" terminology in >>> the past? :) >> >> I don't remember. In any case it is a hard statement to parse. If you want to keep the term, how >> about "Requesting offerer BUNDLE address selection"? (But I still think "Suggesting" is clearer.) > > Then we would have to change the section 8.5.2 title ("Request a new offerer BUNDLE address") too. > > And, in section 8.5.1 there is a sentence saying: > > "o The offerer wants to request the answerer to select a new offerer > BUNDLE address [Section 8.5.2];" > > And, there is other text where "request" is used, e.g. when talking about requesting a BUNDLE group to be created etc. > > Etc. > > One option, which is also more aligned with the 8.5.2 title, would be to say: > > "Request an offerer BUNDLE address" (or "Request the offerer BUNDLE address") > > ...i.e. add "an" (or "the") and remove "selection". I'm just going to give up on this. It isn't important enough to devote this much effort to. > ------------------------- > >>>> * Section 8.3.2: Answerer Selection of Offerer Bundle Address >>>> >>>> I have a few wording changes to suggest for clarity: >>>> >>>> In this section, the use of 'the "m=" line' seems a little vague. I think it would be better to change it to 'that "m=" line' throughout. >>> >>> I do agree that we could use the following modified sentence: >>> >>> "The answerer MUST check whether that "m=" line fulfils the following criteria:" >> >> s/fulfils/fulfills/ > > Correct. > >>>> Also >>>> - s/fulfils/fulfills/ >>>> - s/criteria above is fulfilled/criteria above are fulfilled/ >>>> - s/criteria is not fulfilled/criteria are not fulfilled/ >>>> - s/represents/identifies/ >>> >>> OK. > > Here I'd actually like to keep "represents", because that is the wording used elsewhere in the document. OK. > ------------------------- > >>>> Another thing: I *think* that *plain* RTP can also coexist with STUN, >>>> DTLS, and SRTP using the rules of RFC5764. (Can somebody confirm if >>>> this is true?) >>> >>> I'll ask Colin. >> >> Sounds good. > > I've sent him an e-mail. > > ------------------------- > >>>> Also, there is *no* mention of SCTP in this document. ISTM that there should be >>>> something. I guess the 2nd paragraph here is intended to cover that. If so, it is too subtle. >>> >>> The document does not cover SCTP - unless it is transported on top of DTLS, in which case it is implicitly covered by the 2nd paragraph. >>> >>> What would you like to mention about SCTP? >>> >>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't use DTLS payload >>>> packets. So *one* m-line with a protocol that uses DTLS payload packets (e.g., >DTLS/SCTP) can >>>> coexist with STUN and SRTP. If there is more than one such m-line then some other specification is >>>> required to associate those packets with m-lines. >>> >>> I think that is covered, as SRTP is distinguished from DTLS. >>> >>> But, if you think that needs to be more clear, maybe the following modified sentence: >>> >>> "[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..." >> >> I think this document should bite the bullet and define how SCTP coexists with SRTP in a bundle. > > Personally, I would not want to do that at this stage. We decided earlier that the draft will cover DTLS, SRTP and STUN, and that any other protocols/combinations have to be defined elsewhere. If it isn't here, then it needs to be somewhere else. Where? It shouldn't be hard. Thanks, Paul From nobody Tue Oct 21 09:29:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2201A8963 for ; Tue, 21 Oct 2014 09:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30nxqqdlk7Ue for ; Tue, 21 Oct 2014 09:29:31 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF291A8904 for ; Tue, 21 Oct 2014 09:29:30 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-6c-544689e9ac4d Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 58.9F.21334.9E986445; Tue, 21 Oct 2014 18:29:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 18:29:28 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments Thread-Index: Ac/quUI/xECKSzhxQBSQKARMMFph+ABvWmSAACBV85AAD2ktgAAE/u1A Date: Tue, 21 Oct 2014 16:29:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4BFA92@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> <54453FD1.9070207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BB448@ESESSMB209.ericsson.se> <5446803D.80405@alum.mit.edu> In-Reply-To: <5446803D.80405@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje7LTrcQg097pSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjz6mT7AVtVhUzJz9mbmB8p9vFyMkhIWAi MefLA3YIW0ziwr31bF2MXBxCAkcZJU5P+8IK4SxhlJj/7SpLFyMHB5uAhUT3P20QU0RAQ2LS VjWQXmYBFYlXpy+zgoSFBWIlNq0uBwmLCMRJTF39hBnCdpP4+vc/mM0ioCrx8e4VZpByXgFf iadLoBZdZpQ4MPEQK0gNp4CWxP3dN8FsRqDTvp9awwSxSlzi1pP5TBAnC0gs2XOeGcIWlXj5 +B8rhK0ksej2Z6h6HYkFuz+xQdjaEssWvgar5xUQlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBMbOwS2/dXcwrn7teIhRgINRiYdXYZ9riBBr YllxZe4hRmkOFiVx3kXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYEy2kPx54cJN5pXH dnYcLvz/JsY284zg76S6M4l9KlP/Sbmf2vLLMJVb+1SZi3+4+e5jr/d/fScoJMvNs7/CYeGB DZcD/nRffNs+Z7WGacL0CWxsL6cxvVU4w+nmOMHHuWO+dO20GRFy3jJ7vXosji8787f4kbrM yZ7pj1eyz81/bnXj/tOjTDxKLMUZiYZazEXFiQCu9iwqfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7jawjDQWbgZ_hwc8uVPuyzY5gYA Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 16:29:34 -0000 Hi Paul, See inline. >>>>> * Section 2: Terminology >>>>> >>>>> In the following: >>>>> >>>>> BUNDLE group: A set of "m=3D" lines, created using an SDP Offer/= Answer >>>>> exchange, for which each endpoint uses a single 5-tuple to send = and >>>>> receive media. Each endpoint uses its BUNDLE address, associate= d >>>>> with the BUNDLE group, to send and receive the media. >>>>> >>>>> are we *requiring* symmetric media usage? Certainly you must=20 >>>>> *receive* on your bundle address, but AFAIK *sending* on that=20 >>>>> address is, in general, optional though various options that might be= used with it (such as ICE) may require it. >>>> >>>> The definition of "BUNDLE address" states that the address is used for= both sending and receiving media. >>> >>> This is a little fuzzy. That is mentioned in the Intro, but not in=20 >>> the Terminology definitions of Offerer/Answerer BUNDLE address. It is m= entioned in the definition of BUNDLE group, but not in a normative way. >>> >>> If you really intend to require this, then it should be stated more cle= arly in a normative way. >> >> I checked the definitions for "Offerer BUNDLE address" and "Answerer BUN= DLE address", and you are correct that the text only talks about receiving = media. >> >> So, that would have to be fixed. >> >> ...unless, of course, we'd choose to NOT mandate symmetric media (obviou= sly, the sender would=20 >> still need to use a single address:port for sending all media associated= with the BUNDLE group). > > In general I prefer not to impose unnecessary restrictions. So unless the= re is come compelling reason to require=20 > symmetric media I would rather not. Of course some usages (e.g., ICE) wil= l still require it, but that is up to them, not bundle. > > But I'm willing to listen to reasons why this is required for bundle. I don't remember whether we ever discussed that. Perhaps people have had th= at assumption, since the biggest customer of BUNDLE so far has been RTCWEB,= where usage of ICE is mandatory. So, let's try to get some input from others. ------------------------- >>>>> * Section 7.3: Bandwidth >>>>> >>>>> Says: >>>>> >>>>> The total proposed bandwidth for a BUNDLE group is the sum of th= e >>>>> proposed bandwidth for each bundled "m=3D" line. >>>>> >>>>> What if some of the bundled m-lines have no b=3D line, while others=20 >>>>> do? It probably doesn't make sense to treat them as having zero=20 >>>>> bandwidth. I guess maybe some default value should be used. But what? >>>> >>>> You do whatever you'd do for a non-BUNDLED "m=3D" line. Normally I=20 >>>> guess you have a default value, or a value based on the media type and= /or payload formats. >>> >>> I think this requires discussion with people that know more about this = topic. >> >> I think we had discussions about this in the past, and the outcome was t= hat you calculate the bandwidth in the same way as you would for non-bundle= d m- lines. >> >>> AFAIK, with non-bundled m-lines that don't specify, there is no=20 >>> specific limit unless there is a session-level b-line. I don't know wha= t happens if there is a session-level b-line. I guess there is supposed to = be a default for every codec. >> >> I don't think it's up to the BUNDLE spec to define what a missing b- lin= e means. > > If bundle forces a new concern, where there was none in the past, then bu= ndle needs to say what to do about it. > > So I think *something* needs to be said. It might not be complicated. > >>>>> Or, I guess there could be a rule that if any of the bundled m-lines = have b=3D then all of them must. >>>>> >>>>> Also, I guess there needs to be a separate sum for each bandwidth typ= e. >>>>> >>>>> Note: this is also an issue for draft-ietf-mmusic-sdp-mux-attributes. >>>>> >>>>> I note that section 7.3 defers to >>>>> draft-ietf-mmusic-sdp-mux-attributes >>>>> for attribute bundling rules. >>>> >>>> I assume you mean section 7.4? >>> >>> Yup. >>> >>>>> Perhaps this section should similarly defer to that draft for bandwid= th bundling. >>>> >>>> The "b=3D" parameter is not covered by that draft (as it's not an SDP = attribute). >>> >>> Ah! So this draft is on its own. It seems like more text is needed. >>> Especially what to do with extension bandwidth types. >> >> I'm not really sure what text would have to be added, so I'd need some i= nput on that. > > The current text says to sum the bandwidth across all the m-lines in the = bundle. At the least, it=20 > should say that the sum must be done separately for bandwidth types CT an= d AS, and if any other=20 > types have been defined then for them too. > > I don't really understand these, or how they are used. From reading 4566 = I *think* that CT is only=20 > used at session level. If so, then it is not a concern for bundle. So tha= t should be stated (if it is true). > > So maybe it is only AT type that can appear in a bundle. > > I don't find anything in 4566 about summing bandwidth values across m-lin= es. It says "CT gives a total=20 > bandwidth figure for all the media at all sites", but I don't think there= is any expectation that the sum=20 > of the AT values for individual m-lines are bounded by that. My impressio= n is that it might be quite=20 > reasonable for that sum to exceed the CT value, because they may not all = be used concurrently. > > I'm out of my depth regarding bandwidth specification and enforcement.=20 > Can we get somebody who knows about this stuff to comment? Yeah, I think we need input and guidance from the media plane folks here :) ------------------------- >>>>> Also, there is *no* mention of SCTP in this document. ISTM that=20 >>>>> there should be something. I guess the 2nd paragraph here is intended= to cover that. If so, it is too subtle. >>>> >>>> The document does not cover SCTP - unless it is transported on top of = DTLS, in which case it is implicitly covered by the 2nd paragraph. >>>> >>>> What would you like to mention about SCTP? >>>> >>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't=20 >>>>> use DTLS payload packets. So *one* m-line with a protocol that uses=20 >>>>> DTLS payload packets (e.g., >DTLS/SCTP) can coexist with STUN and=20 >>>>> SRTP. If there is more than one such m-line then some other specifica= tion is required to associate those packets with m-lines. >>>> >>>> I think that is covered, as SRTP is distinguished from DTLS. >>>> >>>> But, if you think that needs to be more clear, maybe the following mod= ified sentence: >>>> >>>> "[RFC5764] does not describe how to identify different protocols tran= sported on DTLS (i.e. using DTLS payload packets), only how to..." >>> >>> I think this document should bite the bullet and define how SCTP coexis= ts with SRTP in a bundle. >> >> Personally, I would not want to do that at this stage. We decided earlie= r that the draft will cover=20 >> DTLS, SRTP and STUN, and that any other protocols/combinations have to b= e defined elsewhere. > > If it isn't here, then it needs to be somewhere else. Where? In a separate draft. > It shouldn't be hard. Who is asking for it? RTCWEB will not support SCTP transport (they will sup= port SCTP over DTLS). Regards, Christer From nobody Tue Oct 21 09:33:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35B1A6FD7 for ; Tue, 21 Oct 2014 09:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBiW9TkliNQU for ; Tue, 21 Oct 2014 09:33:33 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B431A8914 for ; Tue, 21 Oct 2014 09:33:29 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so1704391igc.6 for ; Tue, 21 Oct 2014 09:33:28 -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=QBAdac/qlog2TXPshh9e95f70MP6IY3GkG+X/P79rTA=; b=leik8CEsjr0CmcmT8IUvV0G8KpMnJQPy6RbgERxDfT9AsWk0sDwz7sfBwe/VGqmKef QIMUSVHRhq6gvN4qoabce0MgmOvxOv4CLB1305rP/ywIGQGXDl98BkiQEKxrFPssjBkK 1bYogPRYDx3t8ri1ti66mAMlMAKmTDdO9p7AZtk3aFro/5ZtFbOgNs9BOhY4GklUSr/w 8BnJHNYf7tmVic6CQe9VhC1mmkjh65qlsLJquGTZZGYOzRikrmOoEpzVEJFiAUbYsNzm i5NS3cbm2x9Nc4j72UfApwxLGfVtMF5xrpD5k4ETPILKTchrnlZg+gTRgGpWmdHrXz1q KaFg== MIME-Version: 1.0 X-Received: by 10.43.90.198 with SMTP id bj6mr11130984icc.4.1413909208631; Tue, 21 Oct 2014 09:33:28 -0700 (PDT) Received: by 10.43.3.4 with HTTP; Tue, 21 Oct 2014 09:33:28 -0700 (PDT) Date: Tue, 21 Oct 2014 09:33:28 -0700 Message-ID: From: Ted Hardie To: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5196bdd2010100505f1648e Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kNdh6FfgGW3Ak7YkrT8v0KBq634 Subject: [MMUSIC] Review of draft-ietf-mmusic-msid-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 16:33:36 -0000 --bcaec5196bdd2010100505f1648e Content-Type: text/plain; charset=UTF-8 Some time ago I promised a review of this draft, wrote one, and then never sent it; Ari kindly reminded me that I owed to the group, without properly berating me for the idiocy. I've done a quick review of the updates since the original and updated it. I followed the template for the Apps Area Directorate reviews, but this is not a review from that team (and not part of their archives, etc.) My apologies for the delay. Ted Document: draft-ietf-mmusic-msid Title: WebRTC MediaStream Identification in the Session Description Protocol Reviewer: Ted Hardie Summary: No basic concerns with the mechanism described. Comments: Because the document currently describes the WebRTC semantics and makes specific references to JSEP, it's not clear that it can safely go forward with JSEP not yet approved. JSEP, on the other hand, needs this and BUNDLE to be stable. Rather than deadlock on this at the WG level, I suggest that this document (and Bundle) go forward even if JSEP is not yet approved, but with an explicit note that they are not requesting downrefs. That will hold them for a final check by authors at the RFC Editor Major Issues: Minor Issues: Section 4 consistently describes the requirements in terms of what the entity implements, e.g.: An entity implmementing an MSID semantic MUST add one or more "msid- semantic" attributes to its session level attributes, indicating the MSID semantic it supports. It's not clear this formulation is correct, as there may be cases where an implementation supports a specific semantic,but does not wish to use it. This hinges, I guess, on what "entity" means here (the implementation or the instance in which it is used). I'd suggest changing these formulations to something like "An implementation supporting an MSID semantic for a specific offer/answer MUST add..." unless there is a strong reason to believe that it must be offered if implemented. Later, in section 5.1, the document says: "If an entity implementing the WMS semantic sends a description, it MUST include the msid-semantic:WMS attribute, even if no media streams are sent. This allows us to distinguish between the case of no media streams at the moment and the case of legacy SDP generation." It's not clear what legacy SDP generation means here. It seems that the presence of any msid-semantic session level attribute would indicate that it was not "legacy SDP generation", for at least some values of legacy. I think the point here is that you want to know at beginning of the session whether or not WMS semantics will be used, even if there no media to bear the MSIDs yet. I'd suggest recasting this to say that, with something like "In an entity intends to use WMS semantics in a session, it should the msid-semantic on sending a description, even if no media are sent" In the IANA considerations, the document says: This document requests IANA to create a new registry called "Semantics for the msid-semantic SDP attribute", which should have exactly the same rules as for the "Semantics for the ssrc-group SDP attribute" registry (Expert Review), and to register the "WMS" semantic within this new registry. Generally, IANA seems to be asking for guidance to the expert when you create a registry with expert review; if the intent is to repeat the guidance given for ssrc-group SDP attribute registry, then a pointer to the guidance may be necessary. Alternatively, it may be enough to suggest that the working group expects this to be a sparsely used registry Nits: --bcaec5196bdd2010100505f1648e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some time ago I promised a review of this draft,= wrote one, and then never sent it; Ari kindly reminded me that I owed to t= he group, without properly berating me for the idiocy.=C2=A0 I've done = a quick review of the updates since the original and updated it.=C2=A0 I fo= llowed the template for the Apps Area Directorate reviews, but this is not = a review from that team (and not part of their archives, etc.)

My apologies for the delay.

Ted

=

Document: draft-ietf-mmusic-msid
Title: WebRTC MediaStream Identification in the Session Descripti= on Protocol

Reviewer: Ted Hardie

Summary: No basic concerns with the mechanism described.

Comm= ents:
Because the document currently describes the WebRTC semantics and= makes specific
references to JSEP, it's not clear that it can safel= y go forward with JSEP not yet approved.=C2=A0
JSEP, on the other hand,= needs this and BUNDLE to be stable.=C2=A0 Rather than deadlock on
this = at the WG level, I suggest that this document (and Bundle) go forward even = if JSEP is not yet
approved, but with an explicit note that they are no= t requesting downrefs.=C2=A0 That will
hold them for a final check by au= thors at the RFC Editor

Major Issues:

Minor Issues:

Section 4 consistently describes the requirements = in terms of what the entity implements, e.g.:

 =C2=A0 An en=
tity implmementing an MSID semantic MUST add one or more "msid-
=C2=
=A0 =C2=A0semantic" attributes to its session level attributes, indica=
ting the
=C2=A0 =C2=A0MSID semantic it supports.

It's not cle=
ar this formulation is correct, as there may be cases where an implementati=
on 
supports a specific semantic,but does not wish to use it.=C2=A0 This=
 hinges, I guess, on what 
"entity" means here (the implementa=
tion or the instance in which it is used).=C2=A0 I'd suggest 
changi=
ng these formulations to something like "An implementation supporting =
an MSID semantic 
for a specific offer/answer MUST add..." unless t=
here is a strong reason to believe that
it must be offered if implemente=
d.

Later, in section 5.1, the document says:=


  "If an entity implementing the WMS seman=
tic sends a description, 
   it MUST include the msid-semantic:WMS attri=
bute, even if no media 
   streams are sent. This allows us to distingui=
sh between the case 
   of no media streams at the moment and the case o=
f legacy SDP generation."


It's not clear wha=
t legacy SDP generation means here. It seems that the
presence of any ms=
id-semantic session level attribute would indicate
that it was not "=
;legacy SDP generation", for at least some values of legacy.
= 
I think the point here is that you want to know at beginning of the se=
ssion
whether or not WMS semantics will be used, even if there no media =
to bear
the MSIDs yet.  I'd suggest recasting this to say that, with=
 something like
"In an entity intends to use WMS semanti=
cs in a session, it should the msid-semantic
on sending a description, e=
ven if no media are sent"

In the IANA considerations=
, the document says:

   This document requests IANA to create a new =
registry called
   "Semantics for the msid-semantic SDP attribute", which should =
have
   exactly the same rules as for the "Semantics for the ssrc-group SDP
   attribute" registry (Expert Review), and to register the "WMS&=
quot;
   semantic within this new registry.
Generally, IANA seems to be=
 asking for guidance to the expert when
you create a registry with exper=
t review; if the intent is to repeat 
the guidance given for ssrc-group =
SDP attribute registry, then a pointer 
to the guidance may be necessary=
.  Alternatively, it may be enough to 
suggest that the working group ex=
pects this to be a sparsely used registry

= Nits:




--bcaec5196bdd2010100505f1648e-- From nobody Tue Oct 21 10:04:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51C71A8033 for ; Tue, 21 Oct 2014 10:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxp0JtjhxcWL for ; Tue, 21 Oct 2014 10:04:23 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64FB1A6FD1 for ; Tue, 21 Oct 2014 10:04:23 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id D140D35CB8080; Tue, 21 Oct 2014 17:04:19 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9LH4MW4009735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 13:04:22 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 13:04:22 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "DRAGE, Keith (Keith)" Thread-Topic: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 Thread-Index: AQHP7NemWaWCYcXI9U6748OuwSozPJw6vsdw Date: Tue, 21 Oct 2014 17:04:21 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5445C65B.6040804@alum.mit.edu> In-Reply-To: <5445C65B.6040804@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ifif59_Ag5sC0o_LdOsI_GBo6MA Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 17:04:26 -0000 Hi Paul, Thanks for the detailed and thorough comments. Please see my inline responses below. > This is in much better shape now - having caught up with changes in the > related drafts. Here are a few comments and suggestions: >=20 > * Section 5.1.1.1: >=20 > Rather than using 'unordered=3D1' for unordered, and 'unordered=3D0' for > ordered, it would be more obvious to simply use 'ordered' and 'unordered'= . Though I am ok with this style, but to my knowledge, so far none of the SDP= properties are defined this way. The related properties are always defined= as prop=3Dvalue style (e.g. AMR octet-align=3D0/1, OPUS usedtx=3D0/1). If unordered is confusing, how about using ordered=3D0 or 1 and make 1 as t= he default value? >=20 > Are all combinations of max_retr, max-time, unordered, [ordered] > allowed? (There are 8 such combinations, but there are only 6 data > channel types in rtcweb-data-protocol.) >=20 > (The syntax for the dcmap attribute suggests that all combinations are > valid.) Agreed. We will add text to indicate the combinations should be allowed per= rtcweb-data-protocol spec. =20 > Also, the syntax forces the fields to be entered in a particular order. > That is likely to be a source of errors. Agreed. We will take the suggestion made below on new syntax which allows a= ny order. =20 >=20 > * Sections 5.1.1.2 & 5.1.1.3 >=20 > the definition 'text =3D byte-string' has to be wrong. That will suck up > the rest of the line, including following ";" separated items. The > examples show that you mean a quoted string, but 4566 doesn't have a > definition for that. Good point. Will change it to quoted string. =20 > * Section 5.1.1.4 >=20 > The section title (and usage through the document) calls this parameter > 'max_retr", but the syntax defines it as 'maxretr'. Will fix it. > IMO a separator in this is good, but I would prefer it to be "-" rather > than "_". Will change it. >=20 > I think maxretrvalue could be defined using 'integer' from 4566. That is > almost the same, but can't start with a zero. It would be good to > specify the valid range for this this parameter. That could be specified > by reference to rtcweb-data-protocol. Will add the reference. =20 > * Section 5.1.1.5 >=20 > My comments on 5.1.1.4 apply here as well. >=20 > Here is a proposal for updating the syntax to deal with all of the > above. (Note that I've also changed to use the format I have proposed in > rfc4566bis.) Thanks. We will take this proposal. =20 > Name: dcmap >=20 > Value: dcmap-value >=20 > Usage Level: media >=20 > Charset Dependent: no >=20 > Syntax: >=20 > dcmap-value =3D dcmap-stream-id > [ SP dcmap-opt *(";" dcmap-opt) ] > dcmap-opt =3D ordering-opt / subprotocol-opt / label-opt > / maxretr-opt / maxtime-opt >=20 > dcmap-stream-id =3D 1*DIGIT > ordering-opt =3D "ordered" / "unordered" > subprotocol-opt =3D "subprotocol=3D" quoted-string > label-opt =3D "label=3D" quoted-string > maxretr-opt =3D "max-retr=3D" maxretr-value > maxretr-value =3D integer > maxtime-opt =3D "max-time=3D" maxtime-value > maxtime-value =3D integer ; milliseconds >=20 > quoted-string =3D DQUOTE *(quoted-char / escaped-char) DQUOTE > quoted-char =3D SP / quoted-visible > quoted-visible =3D %21 / %23-24 / %26-7E ; VCHAR without " or % > escaped =3D "%" HEXDIG HEXDIG > DQUOTE =3D > integer =3D >=20 > Examples: >=20 > a=3Ddcmap:0 > a=3Ddcmap:1 subprotocol=3D"BFCP";max-time=3D60000 > a=3Ddcmap:2 subprotocol=3D"MSRP";ordered;label=3D"MSRP" > a=3Ddcmap:3 label=3D"Label 1";unordered;max-retr=3D5 > a=3Ddcmap:4 label=3D"foo%09bar";ordered;max-time=3D15000;max-retr= =3D3 >=20 > Note that I made subprotocol optional, like the others. Also, I defined > quoted-string so that it can only contain SP and visible ascii > characters other that " and % as literals. Anything else must be in hex. > There are lots of other possibilities for how to do that, but at least > that one is clear when you look at it. Making subprotocol optional is a good idea. This allows data channels to be= negotiated without specifying the subprotocol for middle box use cases tha= t is being discussed at rtcweb http://www.ietf.org/mail-archive/web/rtcweb/= current/msg13206.html =20 >=20 > * Section 5.1.2 >=20 > Each sub-protocol specific SDP attribute that would normally be used > to negotiate the subprotocol using SDP is replaced with an attribute > of the form "a=3Ddcsa:sctp-port:stream-id original-attribute", ... >=20 > None of the examples include the sctp-port. I guess this should have > said: "a=3Ddcsa:stream-id original-attribute". Will fix that. >=20 > But that highlights the need for of a formal specification of the dcsa > attribute. E.g., We will use this syntax. >=20 > Name: dcsa >=20 > Value: dcsa-value >=20 > Usage Level: media >=20 > Charset Dependent: no >=20 > Syntax: >=20 > dcsa-value =3D stream-id SP attribute > attribute =3D >=20 > Example: >=20 > a=3Ddcsa:2 accept-types:text/plain >=20 > * Section 5.2.1 >=20 > This specification allows simultaneous use of external and internal > negotiation. However, a single stream is managed using one method at > a time. Stream ids that are not currently used in SDP can be used > for internal negotiation. Stream id determination per external > negotiation may not align with DTLS based termination. This could > cause glare conditions when one side trying to do external > negotiation on a stream id while the other end trying to open data > channel on the same stream id using internal negotiation. To avoid > these glare conditions this specification recommends that the data > channel stack user always selects stream ids per SDP offer/answer > rule even when internal negotiation is used. To avoid glare > conditions, it is possible to come up with a different stream id > allocation scheme, but such schemes are outside the scope of this > specification =20 The intention of this section is to make it clear that external data channe= l negotiation does not preclude use of inband/internal DCEP. Both can be used simultaneously; but care should be taken while allocating stream ids. How about the following updated text? Hope this makes it clear. This specification allows simultaneous use of external and internal negotiation. However, a single stream is managed using one method at a time. Stream ids that are not currently used in SDP can be used for internal negotiation. Stream id allocation per SDP based external negotiation may not align with DTLS role based allocation. This could cause glare conditions when one side trying to do external negotiation on a stream id while the other end trying to open data channel on the same stream id using internal negotiation. To avoid these glare conditions this specification recommends that the data channel stack user always selects stream ids per SDP offer/answer rule even when internal negotiation is used. To avoid glare conditions, it is possible to come up with a different stream id allocation scheme, but such schemes are outside the scope of this specification. Thanks Raju From nobody Tue Oct 21 10:09:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916AF1A03AB for ; Tue, 21 Oct 2014 10:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBBUQB1WvQOp for ; Tue, 21 Oct 2014 10:09:13 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2178C1A03FF for ; Tue, 21 Oct 2014 10:09:06 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-03v.sys.comcast.net with comcast id 5t8d1p0044yXVJQ01t96ka; Tue, 21 Oct 2014 17:09:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id 5t951p00R3Ge9ey01t954z; Tue, 21 Oct 2014 17:09:06 +0000 Message-ID: <54469331.4080307@alum.mit.edu> Date: Tue, 21 Oct 2014 13:09:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> <54453FD1.9070207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BB448@ESESSMB209.ericsson.se> <5446803D.80405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BFA92@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4BFA92@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413911346; bh=iBfTmw6ylZOeTF2QxXHcjbf1E3UPyd3Fo9oj7a8gsD0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eNWr0k6gdcvvkyZ4ayfwOX0wLOLFr1ypCa23GURQbiFzCcJflVprD06tQgy+i/Uzd +3JZr5iY95GhOrFZn6b8o/U3T/YVxcUzmGiKJ4I0gxGaEl2Bto37GY5wXEG71AmDIM tAExU4eOsQMjr5WZtq1LlN7kVdjFA6rnYPprhcuyoDixlbriD1EOYK+LWu1quRV5vP RTERMsEBdRg5Y/TLQE8LHAM/FvbVBxx4eedlXnVnhERCv2/p63UGazOAXUcrKCnBda szeUlC1kiElBFYv5rCNlbTJ7xejTK4PfdPpXZJVD8qgbVUixj48xwDe+KD1Z+7jhMm C1+G5GAebyRiA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f7CJFoXgQGTfZjnU7Fl0p92CNbY Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 17:09:17 -0000 On 10/21/14 12:29 PM, Christer Holmberg wrote: >>>>> What would you like to mention about SCTP? >>>>> >>>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't >>>>>> use DTLS payload packets. So *one* m-line with a protocol that uses >>>>>> DTLS payload packets (e.g., >DTLS/SCTP) can coexist with STUN and >>>>>> SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines. >>>>> >>>>> I think that is covered, as SRTP is distinguished from DTLS. >>>>> >>>>> But, if you think that needs to be more clear, maybe the following modified sentence: >>>>> >>>>> "[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..." >>>> >>>> I think this document should bite the bullet and define how SCTP coexists with SRTP in a bundle. >>> >>> Personally, I would not want to do that at this stage. We decided earlier that the draft will cover >>> DTLS, SRTP and STUN, and that any other protocols/combinations have to be defined elsewhere. >> >> If it isn't here, then it needs to be somewhere else. Where? > > In a separate draft. > >> It shouldn't be hard. > > Who is asking for it? RTCWEB will not support SCTP transport (they will support SCTP over DTLS). I'll be satisfied if it covers SCTP over DTLS. That is the case where it needs to be able to coexist with RTP. Thanks, Paul From nobody Tue Oct 21 10:57:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D401A7011 for ; Tue, 21 Oct 2014 10:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.765 X-Spam-Level: X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_45=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzz9Bz-h5v6O for ; Tue, 21 Oct 2014 10:57:11 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4751A1B58 for ; Tue, 21 Oct 2014 10:57:11 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-03v.sys.comcast.net with comcast id 5twr1p00154zqzk01txBks; Tue, 21 Oct 2014 17:57:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id 5txA1p00K3Ge9ey01txAiE; Tue, 21 Oct 2014 17:57:11 +0000 Message-ID: <54469E76.1010806@alum.mit.edu> Date: Tue, 21 Oct 2014 13:57:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "DRAGE, Keith (Keith)" References: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5445C65B.6040804@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413914231; bh=S5erjDg7q9Rlo2XRjUX8Zs8mtRTQz3djOP1orpl8q08=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RyGtJECPdpKnVqlo6deA1dbPxqo5H2s+SuDNP+hkRCzRDsHJEWcmnEUWvJqNdKksl xXIF4GZg4im3vkfJF444+AFEzsRUdmoVw19CxyfbzV3tu8/qjOiqKP3uCE4NqaSTNa Ocu7UlTif3c3NXbaBpvOX9lPfVrZ+ycb2k470iVT9+d00bhb0L0LH4FqhwVffkarBM yIqVcT5+kJCAFj/UKXAbu24DjVwTtv90vJ3qlHsp8JadkHjic/VXAH5bSLpur3ITbK cceIIvV7W+MYdkBfAQ+vljBP2FFfPdVVQI3q9H/tAjqq3z3XERpU0wtLyLeXRhwE4L uAfXC25tFcg6A== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/zQQ-e__XBB69CAtbIoap09JFyOE Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 17:57:14 -0000 Hi Raju, On 10/21/14 1:04 PM, Makaraju, Maridi Raju (Raju) wrote: > Hi Paul, > > Thanks for the detailed and thorough comments. > Please see my inline responses below. > >> This is in much better shape now - having caught up with changes in the >> related drafts. Here are a few comments and suggestions: >> >> * Section 5.1.1.1: >> >> Rather than using 'unordered=1' for unordered, and 'unordered=0' for >> ordered, it would be more obvious to simply use 'ordered' and 'unordered'. > > Though I am ok with this style, but to my knowledge, so far none of the SDP properties are defined this way. The related properties are always defined as prop=value style (e.g. AMR octet-align=0/1, OPUS usedtx=0/1). For attributes there are: sendrecv / sendonly / recvonly / inactive rather than sendrecv={0/1/2/3} or direction={sendrecv/sendonly/recvonly/inactive}. > If unordered is confusing, how about using ordered=0 or 1 and make 1 as the default value? That would be an improvement. It is similar to boolean callee capabilities. ('isfocus' is short for 'isfocus=true'.) IMO this is mostly an esthetic choice. I'd appreciate hearing what others think. > > >> >> Are all combinations of max_retr, max-time, unordered, [ordered] >> allowed? (There are 8 such combinations, but there are only 6 data >> channel types in rtcweb-data-protocol.) >> >> (The syntax for the dcmap attribute suggests that all combinations are >> valid.) > > > Agreed. We will add text to indicate the combinations should be allowed per rtcweb-data-protocol spec. > The two excluded ones are those that have both max-retr and max-time (ordered or unordered). Does SCTP exclude those combinations? (I don't think so.) Is there a reason to exclude those? Perhaps simply note that webrtc doesn't support those two combinations. >> Also, the syntax forces the fields to be entered in a particular order. >> That is likely to be a source of errors. > > Agreed. We will take the suggestion made below on new syntax which allows any order. > > >> >> * Sections 5.1.1.2 & 5.1.1.3 >> >> the definition 'text = byte-string' has to be wrong. That will suck up >> the rest of the line, including following ";" separated items. The >> examples show that you mean a quoted string, but 4566 doesn't have a >> definition for that. > > > Good point. Will change it to quoted string. > > >> * Section 5.1.1.4 >> >> The section title (and usage through the document) calls this parameter >> 'max_retr", but the syntax defines it as 'maxretr'. > > > Will fix it. > > >> IMO a separator in this is good, but I would prefer it to be "-" rather >> than "_". > > > Will change it. > > >> >> I think maxretrvalue could be defined using 'integer' from 4566. That is >> almost the same, but can't start with a zero. It would be good to >> specify the valid range for this this parameter. That could be specified >> by reference to rtcweb-data-protocol. > > > Will add the reference. > > >> * Section 5.1.1.5 >> >> My comments on 5.1.1.4 apply here as well. >> >> Here is a proposal for updating the syntax to deal with all of the >> above. (Note that I've also changed to use the format I have proposed in >> rfc4566bis.) > > > Thanks. We will take this proposal. > > >> Name: dcmap >> >> Value: dcmap-value >> >> Usage Level: media >> >> Charset Dependent: no >> >> Syntax: >> >> dcmap-value = dcmap-stream-id >> [ SP dcmap-opt *(";" dcmap-opt) ] >> dcmap-opt = ordering-opt / subprotocol-opt / label-opt >> / maxretr-opt / maxtime-opt >> >> dcmap-stream-id = 1*DIGIT >> ordering-opt = "ordered" / "unordered" >> subprotocol-opt = "subprotocol=" quoted-string >> label-opt = "label=" quoted-string >> maxretr-opt = "max-retr=" maxretr-value >> maxretr-value = integer >> maxtime-opt = "max-time=" maxtime-value >> maxtime-value = integer ; milliseconds >> >> quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE >> quoted-char = SP / quoted-visible >> quoted-visible = %21 / %23-24 / %26-7E ; VCHAR without " or % >> escaped = "%" HEXDIG HEXDIG >> DQUOTE = >> integer = >> >> Examples: >> >> a=dcmap:0 >> a=dcmap:1 subprotocol="BFCP";max-time=60000 >> a=dcmap:2 subprotocol="MSRP";ordered;label="MSRP" >> a=dcmap:3 label="Label 1";unordered;max-retr=5 >> a=dcmap:4 label="foo%09bar";ordered;max-time=15000;max-retr=3 >> >> Note that I made subprotocol optional, like the others. Also, I defined >> quoted-string so that it can only contain SP and visible ascii >> characters other that " and % as literals. Anything else must be in hex. >> There are lots of other possibilities for how to do that, but at least >> that one is clear when you look at it. > > > Making subprotocol optional is a good idea. This allows data channels to be negotiated without specifying the subprotocol for middle box use cases that is being discussed at rtcweb http://www.ietf.org/mail-archive/web/rtcweb/current/msg13206.html > > >> >> * Section 5.1.2 >> >> Each sub-protocol specific SDP attribute that would normally be used >> to negotiate the subprotocol using SDP is replaced with an attribute >> of the form "a=dcsa:sctp-port:stream-id original-attribute", ... >> >> None of the examples include the sctp-port. I guess this should have >> said: "a=dcsa:stream-id original-attribute". > > > Will fix that. > > >> >> But that highlights the need for of a formal specification of the dcsa >> attribute. E.g., > > > We will use this syntax. > > >> >> Name: dcsa >> >> Value: dcsa-value >> >> Usage Level: media >> >> Charset Dependent: no >> >> Syntax: >> >> dcsa-value = stream-id SP attribute >> attribute = >> >> Example: >> >> a=dcsa:2 accept-types:text/plain >> >> * Section 5.2.1 >> >> This specification allows simultaneous use of external and internal >> negotiation. However, a single stream is managed using one method at >> a time. Stream ids that are not currently used in SDP can be used >> for internal negotiation. Stream id determination per external >> negotiation may not align with DTLS based termination. This could >> cause glare conditions when one side trying to do external >> negotiation on a stream id while the other end trying to open data >> channel on the same stream id using internal negotiation. To avoid >> these glare conditions this specification recommends that the data >> channel stack user always selects stream ids per SDP offer/answer >> rule even when internal negotiation is used. To avoid glare >> conditions, it is possible to come up with a different stream id >> allocation scheme, but such schemes are outside the scope of this >> specification > > > The intention of this section is to make it clear that external data channel > negotiation does not preclude use of inband/internal DCEP. Both can be > used simultaneously; but care should be taken while allocating stream ids. > How about the following updated text? Hope this makes it clear. > > This specification allows simultaneous use of external and internal > negotiation. However, a single stream is managed using one method at > a time. Stream ids that are not currently used in SDP can be used > for internal negotiation. Stream id allocation per SDP based external > negotiation may not align with DTLS role based allocation. This could > cause glare conditions when one side trying to do external > negotiation on a stream id while the other end trying to open data > channel on the same stream id using internal negotiation. To avoid > these glare conditions this specification recommends that the data > channel stack user always selects stream ids per SDP offer/answer > rule even when internal negotiation is used. To avoid glare > conditions, it is possible to come up with a different stream id > allocation scheme, but such schemes are outside the scope of this > specification. OK. Thanks, Paul From nobody Tue Oct 21 11:50:48 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C5B1A87ED for ; Tue, 21 Oct 2014 11:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBGGuNkOXdID for ; Tue, 21 Oct 2014 11:50:45 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DAA1A87E9 for ; Tue, 21 Oct 2014 11:50:45 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id EC7F8EFA32EC3; Tue, 21 Oct 2014 18:50:41 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9LIoisX017109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 14:50:44 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 14:50:43 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "DRAGE, Keith (Keith)" Thread-Topic: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 Thread-Index: AQHP7NemWaWCYcXI9U6748OuwSozPJw6vsdwgABbdgD//736gA== Date: Tue, 21 Oct 2014 18:50:43 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5445C65B.6040804@alum.mit.edu> <54469E76.1010806@alum.mit.edu> In-Reply-To: <54469E76.1010806@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/NzJmrTSdWb5Bnn6kX8U_CgfWEu0 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 18:50:46 -0000 Hi Paul, > Hi Raju, >=20 > On 10/21/14 1:04 PM, Makaraju, Maridi Raju (Raju) wrote: > > Hi Paul, > > > > Thanks for the detailed and thorough comments. > > Please see my inline responses below. > > > >> This is in much better shape now - having caught up with changes in th= e > >> related drafts. Here are a few comments and suggestions: > >> > >> * Section 5.1.1.1: > >> > >> Rather than using 'unordered=3D1' for unordered, and 'unordered=3D0' f= or > >> ordered, it would be more obvious to simply use 'ordered' and > 'unordered'. > > > > Though I am ok with this style, but to my knowledge, so far none of the > SDP properties are defined this way. The related properties are always > defined as prop=3Dvalue style (e.g. AMR octet-align=3D0/1, OPUS usedtx=3D= 0/1). >=20 > For attributes there are: sendrecv / sendonly / recvonly / inactive > rather than sendrecv=3D{0/1/2/3} or > direction=3D{sendrecv/sendonly/recvonly/inactive}. >=20 > > If unordered is confusing, how about using ordered=3D0 or 1 and make 1 = as > the default value? >=20 > That would be an improvement. It is similar to boolean callee > capabilities. ('isfocus' is short for 'isfocus=3Dtrue'.) >=20 > IMO this is mostly an esthetic choice. I'd appreciate hearing what > others think. Sure, let's wait for comments. If no major objections we want to keep order= ed=3D0/1 syntax. >=20 > > > > > >> > >> Are all combinations of max_retr, max-time, unordered, [ordered] > >> allowed? (There are 8 such combinations, but there are only 6 data > >> channel types in rtcweb-data-protocol.) > >> > >> (The syntax for the dcmap attribute suggests that all combinations are > >> valid.) > > > > > > Agreed. We will add text to indicate the combinations should be allowed > per rtcweb-data-protocol spec. > > >=20 > The two excluded ones are those that have both max-retr and max-time > (ordered or unordered). Does SCTP exclude those combinations? (I don't > think so.) I believe max-retr and max-time are application level concepts but not SCTP= transport. In both the cases retransmissions of SCTP data chunks does happen but the p= oint at which retransmissions are stopped is different; for "retransmit" ty= pe they are stopped when # of retransmissions exceed 'max-retr' value; for = "timed" typed are stopped when total elapsed time reaches 'max-time'. So, they are mutually exclusive. >=20 > Is there a reason to exclude those? Perhaps simply note that webrtc > doesn't support those two combinations. As mentioned, by definition max-retr and max-time are mutually exclusive. Section "5.1.2 Methods" of http://w3c.github.io/webrtc-pc/ says: > 5. If both the maxPacketLifeTime and maxRetransmits attributes are set (n= ot null),=20 > then throw a SyntaxError exception and abort these steps. So, I think rejecting such an SDP offer is acceptable here. Thanks Raju From nobody Tue Oct 21 15:23:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCF61A8748 for ; Tue, 21 Oct 2014 15:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9nAGjUtMuhG for ; Tue, 21 Oct 2014 15:23:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30DA1A874C for ; Tue, 21 Oct 2014 15:23:24 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9LMNNKO020779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Oct 2014 17:23:24 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5446DCDB.6070409@nostrum.com> Date: Tue, 21 Oct 2014 17:23:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "mmusic@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030200060004010100080009" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/02BXt6UYiw370oQs6Rwpoccknr4 Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-msid-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 21 Oct 2014 22:23:28 -0000 This is a multi-part message in MIME format. --------------030200060004010100080009 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/21/14 11:33, Ted Hardie wrote: > Some time ago I promised a review of this draft, wrote one, and then > never sent it; Ari kindly reminded me that I owed to the group, > without properly berating me for the idiocy. I, too, promised a review; and, like Ted, didn't ever send one. I don't even have the excuse of writing one and forgetting about it. I just didn't make the time to get to it. My comments below are largely in document order. I find no major issues in this document, but I believe that it requires quite a few editorial (and a few slightly-more-than editorial) changes before it's ready to progress. ---------------------------------------------------------------------- Section 1.2 starts with an assertion that the document describes a new RFC 5888 grouping type. This no longer appears to eb true, and it should be removed. ---------------------------------------------------------------------- Section 2: The sentence " The attribute also allows application-specific information to the association" appears to be missing some words. Implementors are likely to find the statements " The identifier... MUST be unique among the identifier values used in the same SDP session" and " There may... be multiple media descriptions that have the same value for identifier" to be confusing, when taken together. I think the conceptual thing that must be unique here needs to be more clearly defined. In fact, I'm a bit confused myself -- the way the mechanism is defined, I believe it is impossible to violate this MUST: using the same ID simply puts things in the same group. Is this intended to be some kind of temporal constraint? ---------------------------------------------------------------------- Section 2: msid-attr = "msid:" msid-id There's some unfortunate interaction between ABNF and SDP here. RFC 4566 states "In general, is either a number of fields delimited by a single space character or a free format string, and is CASE-SIGNIFICANT unless a specific field defines otherwise." Section 5.13, which defines the syntax for a=, does not carve out an exception. So, attribute names are case sensitive. RFC 5234 states "ABNF strings are case insensitive and the character set for these strings is US-ASCII." So, the definition above is overly lax in defining the syntax. Historically, the solution has been to do something like: msid-attr = %x6D.73.69.64 ":" msid-id But that's pretty horrible. Luckily, this is in the RFC Editors' queue: http://datatracker.ietf.org/doc/draft-kyzivat-case-sensitive-abnf/ If you're willing to cite it in this document, it makes things much easier to read: msid-attr = %s"msid:" msid-id This comment also applies to "msid-semantic:" in section 3. ---------------------------------------------------------------------- In section 3, there's not a clear prohibition against an MSID appearing in more than one "msid-semantic" line, but I'm pretty sure that's what we want. In any case, we need to be explicit about whether this is allowed, or you _will_ have implementors arguing about it. Similarly, I think we want a statement that each MSID MUST appear in an msid-semantic line somewhere, right? Otherwise, they're pretty useless. ---------------------------------------------------------------------- Section 4 should probably go into a bit more detail about what is mean by the fact that MSID is not negotiated; in particular, the document needs to point out somewhere the consequences that (a) the session has to "work" (for some definition of "work") if the remote party does not understand the MSID semantic being advertised, and (b) you won't necessarily know if the remote party has applied the semantics you indicate in an msid-semantic attribute. ---------------------------------------------------------------------- Section 4.2 is titled "Answerer processing of the offer," but appears to describe the offerer processing of the answer (in fact, its text is identical to section 4.4). ---------------------------------------------------------------------- Section 5: The mention of "recvonly" without address "sendonly" and "inactive" is going to cause implementors confusion. ---------------------------------------------------------------------- Section 5.1: I honestly don't know what is meant in the final paragraph by "default media stream". This needs to be clarified. ---------------------------------------------------------------------- Section 5.2.2 leaves out a step: the recipient needs to only do these things for MSIDs that are listed in the session-level "a=msid-semantic:WMS" line. ---------------------------------------------------------------------- Section 5.2.5 doesn't talk about signaling to the application that a MediaStream is gone once it no longer appears in any MSID lines. Certainly that's the intention, right? ---------------------------------------------------------------------- The MSID purpose in section 6 seems oddly specific ("It can be used to signal the relationship between a WebRTC MediaStream and a set of m-lines") for a mechanism that otherwise seems to be intended to be generic. Perhaps this can be made more general? ---------------------------------------------------------------------- General, tiny nit: tools.ietf.org requires citations to have a space before the bracket; otherwise, they're not turned into hotlinks. So, e.g., "Grouping[RFC5888]" won't be linked because there is no space after the "g". This happens at least twice in the document. ---------------------------------------------------------------------- I have not reviewed the appendices. /a --------------030200060004010100080009 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/21/14 11:33, Ted Hardie wrote:
Some time ago I promised a review of this draft, wrote one, and then never sent it; Ari kindly reminded me that I owed to the group, without properly berating me for the idiocy.

I, too, promised a review; and, like Ted, didn't ever send one. I don't even have the excuse of writing one and forgetting about it. I just didn't make the time to get to it. My comments below are largely in document order.

I find no major issues in this document, but I believe that it requires quite a few editorial (and a few slightly-more-than editorial) changes before it's ready to progress.

----------------------------------------------------------------------

Section 1.2 starts with an assertion that the document describes a new RFC 5888 grouping type. This no longer appears to eb true, and it should be removed.

----------------------------------------------------------------------

Section 2: The sentence " The attribute also allows application-specific information to the association" appears to be missing some words.

Implementors are likely to find the statements " The identifier... MUST be unique among the identifier values used in the same SDP session" and " There may... be multiple media descriptions that have the same value for identifier" to be confusing, when taken together. I think the conceptual thing that must be unique here needs to be more clearly defined. In fact, I'm a bit confused myself -- the way the mechanism is defined, I believe it is impossible to violate this MUST: using the same ID simply puts things in the same group. Is this intended to be some kind of temporal constraint?

----------------------------------------------------------------------

Section 2:

  msid-attr = "msid:" msid-id

There's some unfortunate interaction between ABNF and SDP here.

RFC 4566 states "In general, <value> is either a number of fields delimited by a single space character or a free format string, and is CASE-SIGNIFICANT unless a specific field defines otherwise." Section 5.13, which defines the syntax for a=, does not carve out an exception. So, attribute names are case sensitive.

RFC 5234 states "ABNF strings are case insensitive and the character set for these strings is US-ASCII." So, the definition above is overly lax in defining the syntax.

Historically, the solution has been to do something like:

  msid-attr = %x6D.73.69.64 ":" msid-id

But that's pretty horrible. Luckily, this is in the RFC Editors' queue: http://datatracker.ietf.org/doc/draft-kyzivat-case-sensitive-abnf/

If you're willing to cite it in this document, it makes things much easier to read:

  msid-attr = %s"msid:" msid-id

This comment also applies to "msid-semantic:" in section 3.

----------------------------------------------------------------------

In section 3, there's not a clear prohibition against an MSID appearing in more than one "msid-semantic" line, but I'm pretty sure that's what we want. In any case, we need to be explicit about whether this is allowed, or you _will_ have implementors arguing about it.

Similarly, I think we want a statement that each MSID MUST appear in an msid-semantic line somewhere, right? Otherwise, they're pretty useless.

----------------------------------------------------------------------

Section 4 should probably go into a bit more detail about what is mean by the fact that MSID is not negotiated; in particular, the document needs to point out somewhere the consequences that (a) the session has to "work" (for some definition of "work") if the remote party does not understand the MSID semantic being advertised, and (b) you won't necessarily know if the remote party has applied the semantics you indicate in an msid-semantic attribute.

----------------------------------------------------------------------

Section 4.2 is titled "Answerer processing of the offer," but appears to describe the offerer processing of the answer (in fact, its text is identical to section 4.4).

----------------------------------------------------------------------

Section 5: The mention of "recvonly" without address "sendonly" and "inactive" is going to cause implementors confusion.

----------------------------------------------------------------------

Section 5.1: I honestly don't know what is meant in the final paragraph by "default media stream". This needs to be clarified.

----------------------------------------------------------------------

Section 5.2.2 leaves out a step: the recipient needs to only do these things for MSIDs that are listed in the session-level "a=msid-semantic:WMS" line.

----------------------------------------------------------------------

Section 5.2.5 doesn't talk about signaling to the application that a MediaStream is gone once it no longer appears in any MSID lines. Certainly that's the intention, right?

----------------------------------------------------------------------

The MSID purpose in section 6 seems oddly specific ("It can be used to signal the relationship between a WebRTC MediaStream and a set of m-lines") for a mechanism that otherwise seems to be intended to be generic. Perhaps this can be made more general?

----------------------------------------------------------------------

General, tiny nit: tools.ietf.org requires citations to have a space before the bracket; otherwise, they're not turned into hotlinks. So, e.g., "Grouping[RFC5888]" won't be linked because there is no space after the "g". This happens at least twice in the document.

----------------------------------------------------------------------

I have not reviewed the appendices.

/a
--------------030200060004010100080009-- From nobody Tue Oct 21 19:10:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C16B1A898E for ; Tue, 21 Oct 2014 19:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8QQv0QRfHVy for ; Tue, 21 Oct 2014 19:10:09 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38651A89E0 for ; Tue, 21 Oct 2014 19:10:08 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with comcast id 629L1p00452QWKC012A8et; Wed, 22 Oct 2014 02:10:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id 62A71p00H3Ge9ey012A7R1; Wed, 22 Oct 2014 02:10:08 +0000 Message-ID: <544711FF.9020607@alum.mit.edu> Date: Tue, 21 Oct 2014 22:10:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5446DCDB.6070409@nostrum.com> In-Reply-To: <5446DCDB.6070409@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413943808; bh=Pk2umpmEJDRdmELJqwVauaODnb2fjaLqN8T679QL7QA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QDYKvGi4YTvy0nFwGNXORg3vjc0tBk/f9lk2zX7YDK9qRtbhrFV3v3YgLkZmX+NRK 5xh3YFJ778zJYWfvnbcZcT9IGzrZghM+u4/c4PfbzpvOX85BsFfGyrVk5zYXNnhpsP O/M602gQLPSIgWBL9kzobjJaujcSvExT2R6N1CJyo2aZzcpONJv73wttGqQ9Rs8aHf 3g9bQWWNgfzhoiGpAB9Qw2FcjdR1GiLlZpRH/Lnk9CxxBz5b7tlgLKZVgMSfTe6klx BOVzTXi03z8OgFqpBOXJpj7ojYHaKHVQPIsV4pNtVUeTfTKAEY1KYXsahBvgwv52wF dDK2Tqf3VfaJQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RRmkOD0kpVwvnXtggwOTLSY6dbU Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-msid-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 02:10:10 -0000 On 10/21/14 6:23 PM, Adam Roach wrote: > Section 2: > > msid-attr = "msid:" msid-id > > There's some unfortunate interaction between ABNF and SDP here. > > RFC 4566 states "In general, is either a number of fields > delimited by a single space character or a free format string, and is > CASE-SIGNIFICANT unless a specific field defines otherwise." Section > 5.13, which defines the syntax for a=, does not carve out an exception. > So, attribute names are case sensitive. > > RFC 5234 states "ABNF strings are case insensitive and the character set > for these strings is US-ASCII." So, the definition above is overly lax > in defining the syntax. > > Historically, the solution has been to do something like: > > msid-attr = %x6D.73.69.64 ":" msid-id > > But that's pretty horrible. Luckily, this is in the RFC Editors' queue: > http://datatracker.ietf.org/doc/draft-kyzivat-case-sensitive-abnf/ > > If you're willing to cite it in this document, it makes things much > easier to read: > > msid-attr = %s"msid:" msid-id > > This comment also applies to "msid-semantic:" in section 3. Please take a look at draft-ietf-mmusic-rfc4566bis-12, where I have redone the definitions of all the attributes defined there. I have adopted a definition style that doesn't use abnf to specify the *name* of the attribute. So specifying the name in a case-sensitive way isn't an issue. I suggest you follow that style. And, if you object to that style, please provide comments on that draft. Thanks, Paul From nobody Wed Oct 22 02:56:12 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4331A8F4A for ; Wed, 22 Oct 2014 02:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGMU0Wmp9Kpz for ; Wed, 22 Oct 2014 02:56:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B5F1A8F44 for ; Wed, 22 Oct 2014 02:56:08 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-9b-54477f363f99 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C6.18.04081.63F77445; Wed, 22 Oct 2014 11:56:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 11:56:06 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments Thread-Index: Ac/quUI/xECKSzhxQBSQKARMMFph+ABvWmSAACBV85AAD2ktgAAE/u1A///uoID//upOsA== Date: Wed, 22 Oct 2014 09:56:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C14AB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> <54453FD1.9070207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BB448@ESESSMB209.ericsson.se> <5446803D.80405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BFA92@ESESSMB209.ericsson.se> <54469331.4080307@alum.mit.edu> In-Reply-To: <54469331.4080307@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja5ZvXuIwa9uHYupyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4fX4ae8Fy/opd09YxNzDO5eli5OSQEDCR WH1pHxuELSZx4d56IJuLQ0jgKKPE1fvL2CGcJYwS+5v2A2U4ONgELCS6/2mDmCICGhKTtqqB 9DILqEi8On2ZFSQsLBArsWl1OUhYRCBOYurqJ8wQdphE447fYKtYBFQlbh46xApi8wr4SrRt vcMMsWknk8TvpZ2MIAlOAR2JV/ffgNmMQLd9P7WGCWKXuMStJ/OZIG4WkFiy5zwzhC0q8fLx P1YIW0lixfZLjBD1OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBk WcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGD0Ht/w22MH48rnjIUYBDkYlHt4F/O4hQqyJ ZcWVuYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBccfnZOmLJ3uaZ/1/ md5vqD5t48Oqc1y3Pk2s7CmeUxb7bmds4/ZmsXlHOGPP+7oIe0vmpwvIPV5/oN9qh3swZ089 q8rnGW/9Tuuk7FzzsMJX5WN3/c+kpQVXxGes4OZdPM9j7fkjE0x4XXfsb1+QEZ3MPtvMN9j3 K1+J5DZdLp64wj0a1p1mSizFGYmGWsxFxYkAx3PSNn8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IFknrYhZcMcCjAYpmSdQu8XpYS0 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 09:56:11 -0000 Hi, >>>>>> What would you like to mention about SCTP? >>>>>> >>>>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't=20 >>>>>>> use DTLS payload packets. So *one* m-line with a protocol that=20 >>>>>>> uses DTLS payload packets (e.g., >DTLS/SCTP) can coexist with=20 >>>>>>> STUN and SRTP. If there is more than one such m-line then some othe= r specification is required to associate those packets with m-lines. >>>>>> >>>>>> I think that is covered, as SRTP is distinguished from DTLS. >>>>>> >>>>>> But, if you think that needs to be more clear, maybe the following m= odified sentence: >>>>>> >>>>>> "[RFC5764] does not describe how to identify different protocols tr= ansported on DTLS (i.e. using DTLS payload packets), only how to..." >>>>>> >>>>> I think this document should bite the bullet and define how SCTP coex= ists with SRTP in a bundle. >>>> >>>> Personally, I would not want to do that at this stage. We decided=20 >>>> earlier that the draft will cover DTLS, SRTP and STUN, and that any ot= her protocols/combinations have to be defined elsewhere. >>> >>> If it isn't here, then it needs to be somewhere else. Where? >> >> In a separate draft. >> >>> It shouldn't be hard. >> >> Who is asking for it? RTCWEB will not support SCTP transport (they will = support SCTP over DTLS). > > I'll be satisfied if it covers SCTP over DTLS. That is the case where it = needs to be able to coexist with RTP. The draft describes how you distinguish between DTLS and SRTP, so that also= covers SCTP over DTLS (SCTP is the "application protocol" carried on DTLS)= . How you differentiate different protocols carried over DTLS need to be desc= ribed elsewhere, but if you only have SCTP carried over DTLS nothing else i= s needed. In addition, if you want to define how to separate SCTP from something else= , you would need to know what that something else is. Regards, Christer From nobody Wed Oct 22 06:03:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628C71A90F2 for ; Wed, 22 Oct 2014 06:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExWsFp3PrN1k for ; Wed, 22 Oct 2014 06:03:20 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09CE1A8AFE for ; Wed, 22 Oct 2014 06:03:19 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-ac-5447ab150eb3 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 21.65.04081.51BA7445; Wed, 22 Oct 2014 15:03:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 15:03:17 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute Thread-Index: Ac/t9UbtecZYZKzdQDWkACrUqUyK3A== Date: Wed, 22 Oct 2014 13:03:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvja7YavcQg667jBZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx9pJwwTmhirmnDRoY+/i6GDk5JARMJA7s bmOGsMUkLtxbz9bFyMUhJHCUUeLf7nksEM4SRokzi9azdjFycLAJWEh0/9MGMUUENCQmbVUD 6WUWUJF4dfoyK4gtLFAq8fDBC0YQW0SgTOLS18fMELaexK9/G9hBbBYBVYlL/fvA4rwCvhJN a/ewgNiMQDd8P7WGCWKmuMStJ/OZIG4TkFiy5zzUnaISLx//Y4WwlSQW3f4MVa8jsWD3JzYI W1ti2cLXUPMFJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWMosWpxUm56UZGeqlFmcnFxfl5 enmpJZsYgZFwcMtvgx2ML587HmIU4GBU4uFdwO8eIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGKfNXhA/64/z5AP3Zs6VeX5b1HDn7mMT5pwN153h1ie0 8SxDXv8EE660vfZ79r38/yjfptDtbfFMKZPF3NfXH9v3YuaSl0v40w7J9TSazXPUzgiyjb0Z GH9aPajwDRfPhnuPU+6d9WR0Uq3dOuddYCt/VFN0yDebe6zSbWdOcX+R27xlpZ7n8YNKLMUZ iYZazEXFiQDI5qBSZQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mDMn7w4BxRASqyHiVAgm39s5OkM Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 13:03:27 -0000 Hi, ------------------------- >>* Section 6: SDP 'bundle-only' Attribute >> >> I would like to see the definition follow the new style introduced in dr= aft-ietf-mmusic-rfc4566bis-12.=20 >> This draft is nearer to completion to that one, and there is some risk t= hat the new style will be revised=20 >> in that draft. I don't propose to hold this draft up for that one - ther= e should not be any formal dependency. > > I'll look into that. Below is a suggested modification to the SDP 'bundle-only' attribute defini= tion, based on the structure suggested by Paul in 4566bis. I have also added the "Category", as defined in draft-ietf-mmusic-sdp-mux-a= ttributes, which I have also suggested should be part of 4566bis. Note that the syntax is a little different than currently suggested by Paul= , and I will provide a comment on 4566bis regarding that. I have NOT added the ABNF to the IANA registrations, as suggested by Paul, = because I don't think it is needed there, and I will provide a comment on 4= 566bis regarding that. Section 6: =3D=3D=3D=3D=3D=3D=3D=3D 6. SDP 'bundle-only' Attribute 6.1. General This section defines a new SDP media-level attribute [RFC4566], 'bundle-only'. 6.2. bundle-only Name: bundle-only Value: Usage Level: media Charset Dependent: no Category: NORMAL Syntax: attribute =3D/ bundle-only-attribute bundle-only-attribute =3D "bundle-only" Example: a=3Dbundle-only The 'bundle-only' attribute can be associated with a bundled "m=3D" line in an offer, to request that the answerer only accepts the "m=3D" line if the answerer keeps the "m=3D" line within the associated BUNDLE group. In order to ensure that an answerer that does not supports the BUNDLE extension always *** rejects a 'bundle-only' "m=3D" line, the offerer can assign a zero port value to the "m=3D" line. According to [RFC4566] an answerer will reject such "m=3D" line. The usage of the 'bundle-only' attribute is only defined for a bundled "m=3D" line within an offer. Other usage is unspecified. [Section 8] defines the detailed SDP Offer/Answer procedures for the 'bundle-only' attribute. ------------------------- Regards, Christer From nobody Wed Oct 22 06:08:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7421A9100 for ; Wed, 22 Oct 2014 06:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gzzptv3AjIb7 for ; Wed, 22 Oct 2014 06:08:39 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2A81A9114 for ; Wed, 22 Oct 2014 06:08:38 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-92-5447ac548ff5 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 52.AD.24955.45CA7445; Wed, 22 Oct 2014 15:08:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 15:08:35 +0200 From: Christer Holmberg To: IETF MMUSIC WG Thread-Topic: BUNDLE: Mandating symmetric RTP? Thread-Index: Ac/t+TLxySzzhSPRThmnhInx0Sm2EA== Date: Wed, 22 Oct 2014 13:08:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4C1713ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+JvjW7IGvcQg3sd4hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRu/n08wFUyUqmtftZ2lgXC7axcjJISFgIrHn4002CFtM4sK9 9UA2F4eQwFFGiWvLlzJCOEsYJVae6mDvYuTgYBOwkOj+pw3SICKgIvHv3QM2kLCwgKbE5l8u IKaIgJ7EqZPBMObOtwkgxSwCqhKPV35gBQnzCvhKXNxcCRJmBFr6/dQaJhCbWUBc4taT+UwQ xwhILNlznhnCFpV4+fgfK4StJLHo9meo+nyJs0c3g9XwCghKnJz5hGUCo9AsJKNmISmbhaQM Iq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQI jIWDW36r7mC8/MbxEKMAB6MSD+8CfvcQIdbEsuLK3EOM0hwsSuK8C8/NCxYSSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAmP7k/NVvJzmnne5mP3TDVyu4ccbnYz+nTJwXO6Hmbfw8fquvey7t PqHkt6N1wQMbfr0A519e294ui8xxUMsW59rMdl+X4xh/mXf0bKG1ssZ3Jnv/ln/Jf2bn1qPc EdeenzecpWL/r94hrzlgShuj5WWRy6rlcXFHdq/bdSLt/fnMDPPFJwI2tSmxFGckGmoxFxUn AgAMvcw0ZgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1HggNJxaJn004AFOYSbe-ZqovHE Subject: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 13:08:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4C1713ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One question, raised as part of Paul's WGLC review of BUNDLE, was whether B= UNDLE should mandate usage of symmetric RTP, i.e. using the same address:po= rt for both sending and receiving RTP. (If ICE is used with BUNDLE, symmetric RTP is obviously required) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4C1713ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One question, raised as part of Paul’s WGLC re= view of BUNDLE, was whether BUNDLE should mandate usage of symmetric RTP, i= .e. using the same address:port for both sending and receiving RTP.

 

(If ICE is used with BUNDLE, symmetric RTP is obviou= sly required)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4C1713ESESSMB209erics_-- From nobody Wed Oct 22 07:18:47 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80B21AC3D0 for ; Wed, 22 Oct 2014 07:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hji8d3LQqIlQ for ; Wed, 22 Oct 2014 07:18:44 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8375B1AC3C2 for ; Wed, 22 Oct 2014 07:18:34 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-08v.sys.comcast.net with comcast id 6EHn1p00657bBgG01EJaTY; Wed, 22 Oct 2014 14:18:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id 6EJZ1p0063Ge9ey01EJZvX; Wed, 22 Oct 2014 14:18:33 +0000 Message-ID: <5447BCB9.2030607@alum.mit.edu> Date: Wed, 22 Oct 2014 10:18:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413987514; bh=ZfmYSUkV7D7UfLA/dI3euq1S8+LXydaTfVLxMCc5IA4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BwSsFFBsDSGp29Jw/NyvBbPSb37ZfzzQqH6XMENF3yuaTqjxZPW6Vo3zR29IgEO8X EILFMSIAcIfuYz5xnR3jKlsed9iTsaMJ5IOL7h1oOdSv+wIeXxyOecu+y+hXEVy5Hn y7fGnZLR4PtAjEt5K9IqoSOm6/Kc9BNEUJp7wCYGnyz2DjWABgLaXypvk9VbmVfgv7 ax7B7OQeombn7jv2x/QPageBd/TCL6wGWSL8LNs4QeS3j4bpzXElHfG4hn0qsCRhJy gOHoP3wNijp+OGCUSiYtumkRszJBWDu96MXcYCdTHpfiUc/DBI+tY8g+eI67aFKOQr qJECe+yvlHsyw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ftCDCFXpuZNx9VhA51NQxP8qh08 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:18:46 -0000 On 10/22/14 9:03 AM, Christer Holmberg wrote: > I have NOT added the ABNF to the IANA registrations, as suggested by Paul, because I don't think it is needed there, and I will provide a comment on 4566bis regarding that. ... > Syntax: > > attribute =/ bundle-only-attribute > > bundle-only-attribute = "bundle-only" The above looks like ABNF to me. Just not of the form I have proposed in 4566bis. Since this attribute has no value, the form in 4566bis would have no ABNF. And using an ABNF quoted string to define the name of the attribute causes it to be case-insensitive, which is not expected for attributes. See Adam's comment on the msid draft for more on that: https://mailarchive.ietf.org/arch/msg/mmusic/02BXt6UYiw370oQs6Rwpoccknr4 Thanks, Paul From nobody Wed Oct 22 07:30:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D791ACC88 for ; Wed, 22 Oct 2014 07:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzbepAwZoU6y for ; Wed, 22 Oct 2014 07:30:34 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0C31ACCE3 for ; Wed, 22 Oct 2014 07:30:30 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-07v.sys.comcast.net with comcast id 6EVl1p0065Clt1L01EWW08; Wed, 22 Oct 2014 14:30:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-17v.sys.comcast.net with comcast id 6EWU1p00V3Ge9ey01EWUaB; Wed, 22 Oct 2014 14:30:30 +0000 Message-ID: <5447BF84.6030902@alum.mit.edu> Date: Wed, 22 Oct 2014 10:30:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> <54453FD1.9070207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BB448@ESESSMB209.ericsson.se> <5446803D.80405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BFA92@ESESSMB209.ericsson.se> <54469331.4080307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C14AB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C14AB@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413988230; bh=CBmxa16lUJ+KDcDq5KJPglSPkM3OpebRTY3fCN+UNdY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=T3U/rV+ZAmTkjh3iehmBkMl/mLiecZIpBOqvcw9v0YBvCEfBo3t82aw+a4TEgE0pv vZKo1vbbsTsC7N/D6it1XeKTigcfCk5RzYOPqd0SG/d2W4y6Cftv0knW6KJfKSwTTH AU6J4TUWqtC9jMCWFt1WLrK8yn685WVJAB4vJoMateRi73PEi82TNEaVCwcIfTCXYH mW1uBk821mqs+o6kTUVdOlJzVqyDDNVzMgNiXc/GAwKG9hOc+lE0a1Nr2kLQB7Ipok coFYM6zfVtPwT/9WLtJwid4dBh27WDelzNWo4iUluwTKDaB6pkl9xUIFnyKlxLaJe7 7O8wVgTf+Z5hw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kK6-_uK15p1tU1_eGbrqzWZ0wXw Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:30:35 -0000 On 10/22/14 5:56 AM, Christer Holmberg wrote: > Hi, > >>>>>>> What would you like to mention about SCTP? >>>>>>> >>>>>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't >>>>>>>> use DTLS payload packets. So *one* m-line with a protocol that >>>>>>>> uses DTLS payload packets (e.g., >DTLS/SCTP) can coexist with >>>>>>>> STUN and SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines. >>>>>>> >>>>>>> I think that is covered, as SRTP is distinguished from DTLS. >>>>>>> >>>>>>> But, if you think that needs to be more clear, maybe the following modified sentence: >>>>>>> >>>>>>> "[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..." >>>>>>> >>>>>> I think this document should bite the bullet and define how SCTP coexists with SRTP in a bundle. >>>>> >>>>> Personally, I would not want to do that at this stage. We decided >>>>> earlier that the draft will cover DTLS, SRTP and STUN, and that any other protocols/combinations have to be defined elsewhere. >>>> >>>> If it isn't here, then it needs to be somewhere else. Where? >>> >>> In a separate draft. >>> >>>> It shouldn't be hard. >>> >>> Who is asking for it? RTCWEB will not support SCTP transport (they will support SCTP over DTLS). >> >> I'll be satisfied if it covers SCTP over DTLS. That is the case where it needs to be able to coexist with RTP. > > The draft describes how you distinguish between DTLS and SRTP, so that also covers SCTP over DTLS (SCTP is the "application protocol" carried on DTLS). > > How you differentiate different protocols carried over DTLS need to be described elsewhere, but if you only have SCTP carried over DTLS nothing else is needed. > > In addition, if you want to define how to separate SCTP from something else, you would need to know what that something else is. The draft describes how to distinguish DTLS and SRTP packets. It doesn't describe how to associate the DTLS packets with m-lines. Rather than single SCTP over DTLS out as special, this draft could simply say that: - if the bundle contains *no* m-lines for protocols that utilize DTLS payload packets then DTLS payload packets are erroneous. - if the bundle contains *one* m-line for a protocol that utilizes DTLS payload packets then all the payload packets are to be associated with it. - if the bundle contains *more than one* m-line for protocols that utilize payload packets then some other specification is needed to define how the packets are associated with m-lines. Thanks, Paul From nobody Wed Oct 22 07:36:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D637A1AC40B for ; Wed, 22 Oct 2014 07:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_45=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F0-R6aoyFOi for ; Wed, 22 Oct 2014 07:36:25 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2D91ACCEB for ; Wed, 22 Oct 2014 07:36:25 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-07v.sys.comcast.net with comcast id 6EcR1p0035BUCh401EcRjX; Wed, 22 Oct 2014 14:36:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id 6EcQ1p00L3Ge9ey01EcQPE; Wed, 22 Oct 2014 14:36:25 +0000 Message-ID: <5447C0E8.2080604@alum.mit.edu> Date: Wed, 22 Oct 2014 10:36:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "DRAGE, Keith (Keith)" References: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5445C65B.6040804@alum.mit.edu> <54469E76.1010806@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413988585; bh=neYOlvDn2X/nUUg+0n747bYj87uglYE59naog4LSBKM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hvfBGO+T28LNyL8SyltrU6NgF1Y2rLyBI8rUxHWQfuS1dDf3jKg4j9dWHkjHxpoNa EFWnnQfLaWmmutdrXLAMqYIvppmm4LgNQ58aHPmKF0e/Yzq+nQqXHpj50rt0y6mER9 V4zJeVLY5BGlZBYmxOkBXG6FBT1OCeFd2TNVV4zG63NaOBvtSGkI8oPEUhRywRGQoq O1syL35zsdG4bbBQxyw09oQHzOfLrL0yWk/TDV+KeMFMo172Bql37S83L5d3JqNK6b tX0OytQMttcZjcECR4PSFcbBTkXCUD5Kdn1FdW8FS5NGBS0bweH8mCPWsr/MtntWKN 7Hhc9vOIa/FMg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QbGyDVrX11HvEDJerGtFmObuH60 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:36:27 -0000 On 10/21/14 2:50 PM, Makaraju, Maridi Raju (Raju) wrote: > Hi Paul, > >> Hi Raju, >> >> On 10/21/14 1:04 PM, Makaraju, Maridi Raju (Raju) wrote: >>> Hi Paul, >>> >>> Thanks for the detailed and thorough comments. >>> Please see my inline responses below. >>> >>>> This is in much better shape now - having caught up with changes in the >>>> related drafts. Here are a few comments and suggestions: >>>> >>>> * Section 5.1.1.1: >>>> >>>> Rather than using 'unordered=1' for unordered, and 'unordered=0' for >>>> ordered, it would be more obvious to simply use 'ordered' and >> 'unordered'. >>> >>> Though I am ok with this style, but to my knowledge, so far none of the >> SDP properties are defined this way. The related properties are always >> defined as prop=value style (e.g. AMR octet-align=0/1, OPUS usedtx=0/1). >> >> For attributes there are: sendrecv / sendonly / recvonly / inactive >> rather than sendrecv={0/1/2/3} or >> direction={sendrecv/sendonly/recvonly/inactive}. >> >>> If unordered is confusing, how about using ordered=0 or 1 and make 1 as >> the default value? >> >> That would be an improvement. It is similar to boolean callee >> capabilities. ('isfocus' is short for 'isfocus=true'.) >> >> IMO this is mostly an esthetic choice. I'd appreciate hearing what >> others think. > > > Sure, let's wait for comments. If no major objections we want to keep ordered=0/1 syntax. > OK >>> >>> >>>> >>>> Are all combinations of max_retr, max-time, unordered, [ordered] >>>> allowed? (There are 8 such combinations, but there are only 6 data >>>> channel types in rtcweb-data-protocol.) >>>> >>>> (The syntax for the dcmap attribute suggests that all combinations are >>>> valid.) >>> >>> >>> Agreed. We will add text to indicate the combinations should be allowed >> per rtcweb-data-protocol spec. >>> >> >> The two excluded ones are those that have both max-retr and max-time >> (ordered or unordered). Does SCTP exclude those combinations? (I don't >> think so.) > > > I believe max-retr and max-time are application level concepts but not SCTP transport. > In both the cases retransmissions of SCTP data chunks does happen but the point at which retransmissions are stopped is different; for "retransmit" type they are stopped when # of retransmissions exceed 'max-retr' value; for "timed" typed are stopped when total elapsed time reaches 'max-time'. > So, they are mutually exclusive. > > >> >> Is there a reason to exclude those? Perhaps simply note that webrtc >> doesn't support those two combinations. > > > As mentioned, by definition max-retr and max-time are mutually exclusive. > Section "5.1.2 Methods" of http://w3c.github.io/webrtc-pc/ says: >> 5. If both the maxPacketLifeTime and maxRetransmits attributes are set (not null), >> then throw a SyntaxError exception and abort these steps. > > So, I think rejecting such an SDP offer is acceptable here. OK. You have convinced me. So there should be some text stating that max-retr and max-time are mutually exclusive. (It isn't feasible to impose such a constraint in the ABNF. I could do it, but it would be ugly.) Thanks, Paul From nobody Wed Oct 22 07:38:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7891ACCF5 for ; Wed, 22 Oct 2014 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbHQXYwgJrIp for ; Wed, 22 Oct 2014 07:38:19 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DB11AC42A for ; Wed, 22 Oct 2014 07:38:18 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-d8-5447c1581a1b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.3A.21334.851C7445; Wed, 22 Oct 2014 16:38:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 16:38:16 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute Thread-Index: Ac/t9UbtecZYZKzdQDWkACrUqUyK3P//+gqA///arAA= Date: Wed, 22 Oct 2014 14:38:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C186C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> <5447BCB9.2030607@alum.mit.edu> In-Reply-To: <5447BCB9.2030607@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjW7EQfcQgw37tC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjc+Mi9oJerooVn18wNzAeY+9i5OSQEDCR mLh+OguELSZx4d56ti5GLg4hgaOMEr8OPGWBcJYwSqyYOAvI4eBgE7CQ6P6nDWKKCGhITNqq BtLLLKAi8er0ZVYQW1igVOLhgxeMILaIQJnEpa+PmSFsK4m5s68xgdgsAqoSGz+tBbN5BXwl jqx8AtYrJJAv8WLlQrA4p4COxJKPt8DijEC3fT+1hglil7jErSfzmSBuFpBYsuc8M4QtKvHy 8T9WCFtJYu3h7SwQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExjFZiEZOwtJyywkLbOQtCxg ZFnFKFqcWlycm25krJdalJlcXJyfp5eXWrKJERg9B7f81t3BuPq14yFGAQ5GJR7eBfzuIUKs iWXFlbmHGKU5WJTEeRedmxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbF7gfcO5ZrXvAre EUU7w2zTe940nX555od/42VjxykXz9/aJvk64qgYx7Z7BXPP+fa5prqKnc7hv/PCq+rZlZ43 k+7f01N533C7pdt2qu76R3u6eu4KTfC5s5Yp1dV9ZU9IpfKGLY9TFtoXdU2/Hlsuo7eupLtU +kZV8Yy4qU4n5MXkFH+1OyuxFGckGmoxFxUnAgClQU0EfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7Y2MNAdsjwHvpeJjLq4p4Id4xps Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:38:20 -0000 Hi, >> I have NOT added the ABNF to the IANA registrations, as suggested by Pau= l, because I don't think=20 >> it is needed there, and I will provide a comment on 4566bis regarding th= at. >>... >> Syntax: >> >> attribute =3D/ bundle-only-attribute >> >> bundle-only-attribute =3D "bundle-only" > > The above looks like ABNF to me. Just not of the form I have proposed in = 4566bis. I know - I intend to give a comment on 4566bis, saying that I think the syn= tax shall be in ABNF form. The only place 4566bis currently suggest to put = the ABNF is in the IANA registration, but I'd rather see it in the attribut= e definition.=20 >Since this attribute has no value, the form in 4566bis would have no ABNF. > > And using an ABNF quoted string to define the name of the attribute cause= s it to be case-insensitive, which is not expected for attributes. > See Adam's comment on the msid draft for more on that: > > https://mailarchive.ietf.org/arch/msg/mmusic/02BXt6UYiw370oQs6Rwpoccknr4 Ok. So, based on the suggestion in that thread, the ABNF would be: attribute =3D/ bundle-only-attribute bundle-only-attribute =3D %s"bundle-only" ....right? Regards, Christer From nobody Wed Oct 22 07:45:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219971ACC81 for ; Wed, 22 Oct 2014 07:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKGi7pXRDOTJ for ; Wed, 22 Oct 2014 07:45:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C206E1ACCF0 for ; Wed, 22 Oct 2014 07:45:46 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-5e-5447c3188ee4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3A.83.04081.813C7445; Wed, 22 Oct 2014 16:45:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 16:45:44 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments Thread-Index: Ac/uBhWayoCnWLriRvenEjuW3EILDQ== Date: Wed, 22 Oct 2014 14:45:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C18A0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvja7EYfcQg/UHzSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj74M+9oK90hX/ujYxNjD+EO1i5OSQEDCR mLl4HzOELSZx4d56ti5GLg4hgaOMEm0Ni9ghnCWMEh17HwM5HBxsAhYS3f+0QUwRAQ2JSVvV QHqZBVQkXp2+zApiCwvESbTPns0OYosIxEvs/bmFCcLWk1h/sw2shkVAVeLY3SNgcV4BX4m9 +x+AxRmBbvh+ag0TxExxiVtP5jNB3CYgsWTPeag7RSVePv7HCmErSaw9vJ0Fol5HYsHuT2wQ trbEsoWvmSHmC0qcnPmEZQKjyCwkY2chaZmFpGUWkpYFjCyrGEWLU4uTctONjPRSizKTi4vz 8/TyUks2MQKj4eCW3wY7GF8+dzzEKMDBqMTDu4DfPUSINbGsuDL3EKM0B4uSOO/Cc/OChQTS E0tSs1NTC1KL4otKc1KLDzEycXBKNTB6+014NSXNaduHJbFvvl2+O3meanNv2o0ElbLA/b+f GtkyzxBQ1dH7PYv5QZTEhLX3l6rUGPu/ZJUR48tf9zpGz/ek1w0hl6ZPmvNF93ld5D93/dDP pD0ct3xWnjqwTrXtQ1uYL8fPmzy1WzyqV/CpSnQffhlhmTIpVOOMlq745kXz6hZ0P7yixFKc kWioxVxUnAgA3Lru32cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/L3PIqNx3ozKTVTomitwawL_1CZk Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:45:50 -0000 Hi, >>>>>>>> What would you like to mention about SCTP? >>>>>>>> >>>>>>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but=20 >>>>>>>>> doesn't use DTLS payload packets. So *one* m-line with a=20 >>>>>>>>> protocol that uses DTLS payload packets (e.g., >DTLS/SCTP) can=20 >>>>>>>>> coexist with STUN and SRTP. If there is more than one such m-line= then some other specification is required to associate those packets with = m-lines. >>>>>>>> >>>>>>>> I think that is covered, as SRTP is distinguished from DTLS. >>>>>>>> >>>>>>>> But, if you think that needs to be more clear, maybe the following= modified sentence: >>>>>>>> >>>>>>>> "[RFC5764] does not describe how to identify different protocols = transported on DTLS (i.e. using DTLS payload packets), only how to..." >>>>>>>> >>>>>>> I think this document should bite the bullet and define how SCTP co= exists with SRTP in a bundle. >>>>>> >>>>>> Personally, I would not want to do that at this stage. We decided=20 >>>>>> earlier that the draft will cover DTLS, SRTP and STUN, and that any = other protocols/combinations have to be defined elsewhere. >>>>> >>>>> If it isn't here, then it needs to be somewhere else. Where? >>>> >>>> In a separate draft. >>>> >>>>> It shouldn't be hard. >>>> >>>> Who is asking for it? RTCWEB will not support SCTP transport (they wil= l support SCTP over DTLS). >>> >>> I'll be satisfied if it covers SCTP over DTLS. That is the case where i= t needs to be able to coexist with RTP. >> >> The draft describes how you distinguish between DTLS and SRTP, so that a= lso covers SCTP over DTLS (SCTP is the "application protocol" carried on DT= LS). >> >> How you differentiate different protocols carried over DTLS need to be d= escribed elsewhere, but if you only have SCTP carried over DTLS nothing els= e is needed. >> >> In addition, if you want to define how to separate SCTP from something e= lse, you would need to know what that something else is. > > The draft describes how to distinguish DTLS and SRTP packets. It doesn't = describe how to associate the DTLS packets with m-lines. > > Rather than single SCTP over DTLS out as special, this draft could simply= say that: > > - if the bundle contains *no* m-lines for protocols that utilize DTLS > payload packets then DTLS payload packets are erroneous. > > - if the bundle contains *one* m-line for a protocol that utilizes > DTLS payload packets then all the payload packets are to be > associated with it. > > - if the bundle contains *more than one* m-line for protocols that > utilize payload packets then some other specification is needed > to define how the packets are associated with m-lines. Currently we have the following text in the draft: "[RFC5764] does not describe how to identify different protocols transported on DTLS, only how to identify the DTLS protocol itself. If multiple protocols are transported on DTLS, there MUST exist a specification describing a mechanism for identify each individual protocol." I guess we could e.g. extend that by saying that the document does not describe how to associated DTLS data with an m- lines, and that a separate specification is needed to define that (basically the third bullet you sugg= est). I don't think we need to say that receiving packets that you haven't negoti= ated is an error, because that applies to any type of non-negotiated protoc= ols. Regards, Christer From nobody Wed Oct 22 07:55:14 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0281ACD31 for ; Wed, 22 Oct 2014 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dol93I0K_BFB for ; Wed, 22 Oct 2014 07:55:07 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3EE1ACD2F for ; Wed, 22 Oct 2014 07:55:07 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-07v.sys.comcast.net with comcast id 6Euy1p00A4yXVJQ01Ev7Ho; Wed, 22 Oct 2014 14:55:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id 6Ev61p00A3Ge9ey01Ev6WM; Wed, 22 Oct 2014 14:55:07 +0000 Message-ID: <5447C54A.6020406@alum.mit.edu> Date: Wed, 22 Oct 2014 10:55:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> <5447BCB9.2030607@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C186C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C186C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413989707; bh=YMyP+1dmgWqUg3+mtayaS3frFfgvdebc0AtjXUNldUQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QnftD03xhPf+a0/ZWmh+gWHzlVJ7jQj5OUSoLrZOxwDlMWuSKmdJ4CY1ICHCCjk+c xDWIIcbudfsMCYSmZlryiU/Ufz5dmNYVqmimN1azR3rM9Ms+CZK/uRajJNVFeRGFrV CoJxDmXiK8AiRAqSCOYOdHZ89fRh2RcceVTV9Lthx4VSywKNIL+aqattl4zhMy6JpI 5hW/Q0w2pd0GPSbRnjSKOIr8fU4NEsIHuoEZrpar+3JyD+nnbfoXCUNGyksU6M/fy6 O+eSj2KbCyl4QYgH5Op8GOhl+dIDIw6ikWqvpcgjOn7qDTXBH5ONjm/0wOCB5ihYet tIuXo53dJnEyQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/GFozY2EOU3WxReJh0Y3I-mDXRls Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 14:55:10 -0000 On 10/22/14 10:38 AM, Christer Holmberg wrote: > Hi, > >>> I have NOT added the ABNF to the IANA registrations, as suggested by Paul, because I don't think >>> it is needed there, and I will provide a comment on 4566bis regarding that. >>> ... >>> Syntax: >>> >>> attribute =/ bundle-only-attribute >>> >>> bundle-only-attribute = "bundle-only" >> >> The above looks like ABNF to me. Just not of the form I have proposed in 4566bis. > > I know - I intend to give a comment on 4566bis, saying that I think the syntax shall be in ABNF form. The only place 4566bis currently suggest to put the ABNF is in the IANA registration, but I'd rather see it in the attribute definition. Why do you say that? Maybe I have more work to do on the IANA considerations section. Note that for the attributes defined in 4566bis, all the info describing an attribute is in the body of the rfc, in section 6, not in the IANA considerations section. The iana considerations section of 4566bis can't look like it would in an extension draft because it also has all the instructions on how to do it in extension drafts. I would expect a draft like yours to have a section defining the attribute, in a form like those in 4566bis have, and then an IANA considerations section that references the SDP Attributes table and references where in the draft the definition is. >> Since this attribute has no value, the form in 4566bis would have no ABNF. >> >> And using an ABNF quoted string to define the name of the attribute causes it to be case-insensitive, which is not expected for attributes. >> See Adam's comment on the msid draft for more on that: >> >> https://mailarchive.ietf.org/arch/msg/mmusic/02BXt6UYiw370oQs6Rwpoccknr4 > > Ok. So, based on the suggestion in that thread, the ABNF would be: > > attribute =/ bundle-only-attribute > > bundle-only-attribute = %s"bundle-only" > > ....right? No. Because I don't want to use ABNF to define the *name* of the attribute. So no 'attribute =/ ...'. Just ABNF for the *value* of the attribute. When the attribute has no value, then no ABNF at all. See now sendrecv is defined. Thanks, Paul From nobody Wed Oct 22 11:12:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0871ACF00 for ; Wed, 22 Oct 2014 11:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20ZUxMLPK6Pe for ; Wed, 22 Oct 2014 11:12:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768F21ACCDE for ; Wed, 22 Oct 2014 11:12:42 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-ff-5447f398e75c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.07.04081.893F7445; Wed, 22 Oct 2014 20:12:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 20:12:39 +0200 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute Thread-Index: Ac/t9UbtecZYZKzdQDWkACrUqUyK3P//+gqA///arACAAC+KAP//qilQ Date: Wed, 22 Oct 2014 18:12:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C1B58@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> <5447BCB9.2030607@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C186C@ESESSMB209.ericsson.se> <5447C54A.6020406@alum.mit.edu> In-Reply-To: <5447C54A.6020406@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje6Mz+4hBjfeKFpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGyrvPmAqeSldsOzKLqYFxtWgXIweHhICJ REOzfBcjJ5ApJnHh3nq2LkYuDiGBo4wSp/5chHKWMEp8+rWKDaSBTcBCovufNogpIqAhMWmr Gkgvs4CKxKvTl1lBbGGBUomHD14wgtgiAmUSl74+Zoaw3SQWL3zCDtLKIqAqceOwJ0iYV8BX 4kvTbhaITVcZJe6eXcQOkuAU0JF43H+RBcRmBLrt+6k1TBC7xCVuPZnPBHGzgMSSPeeZIWxR iZeP/7FC2EoSaw9vZ4Go15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nYWUhaZiFpmYWk ZQEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwNg5uOW3wQ7Gl88dDzEKcDAq8fAu4HcP EWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNLiwed5NQ/1 uOkcOsHz8d7qmTKZu+bqZU9QEp2UoNWlKre3TTh6/yr9DZwnsn476i/RKvsmtDAh4UnUzf9/ 13obfImTenOZ45GJ5QKLS/x/Cg4sjjmypLj0rxuTg3yC+bGn9/gdtuibRc/heT6ZPfd+beJz ntRkofrlcv9OrF8uymq16su9aCWW4oxEQy3mouJEAEurRtl+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/y_sYZW09plnGWEhTSqSXlA9Qz4Y Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 18:12:51 -0000 Hi, >>>> I have NOT added the ABNF to the IANA registrations, as suggested by=20 >>>> Paul, because I don't think it is needed there, and I will provide a c= omment on 4566bis regarding that. >>>> ... >>>> Syntax: >>>> >>>> attribute =3D/ bundle-only-attribute >>>> >>>> bundle-only-attribute =3D "bundle-only" >>> >>> The above looks like ABNF to me. Just not of the form I have proposed i= n 4566bis. >> >> I know - I intend to give a comment on 4566bis, saying that I think the = syntax shall be in=20 >> ABNF form. The only place 4566bis currently suggest to put the ABNF is i= n the IANA registration,=20 >> but I'd rather see it in the attribute definition. > > Why do you say that? Maybe I have more work to do on the IANA considerati= ons section. Note that for the attributes defined in 4566bis, all the info = describing an attribute > is in the body of the rfc, in section 6, not in t= he IANA considerations section. > > The iana considerations section of 4566bis can't look like it would in an= extension draft because it also has all the instructions on how to do it i= n extension drafts. Sorry, I was unclear. I am not talking about the IANA considerations of 456= 6bis, but what information would be in the IANA considerations of a draft d= efining an SDP attribute. Section 8.2.4 of 4566bis, which contains the information that someone defin= ing an attribute sends to IANA, contains the following: "o An ABNF definition of the attribute value rule. The rule MUST NOT match anything that is not also matched by . The rule name SHOULD [MUST?] NOT be defined as an Incremental Alternative to ." I don't think we need the ABNF in the information sent to IANA when registe= ring an attribute. >I would expect a draft like yours to have a section defining the attribute= , in a form like those in 4566bis have, and=20 >then an IANA considerations section that references the SDP Attributes tab= le and references where in the draft the definition is. Yes, that is how I also would like to have it :)=20 But, as described above, my understanding of section 8.2.4 is that I will n= ow have to send the ABNF to IANA when registering the attribute. >>> Since this attribute has no value, the form in 4566bis would have no AB= NF. >>> >>> And using an ABNF quoted string to define the name of the attribute cau= ses it to be case-insensitive, which is not expected for attributes. >>> See Adam's comment on the msid draft for more on that: >>> >>> https://mailarchive.ietf.org/arch/msg/mmusic/02BXt6UYiw370oQs6Rwpocck >>> nr4 >> >> Ok. So, based on the suggestion in that thread, the ABNF would be: >> >> attribute =3D/ bundle-only-attribute >> >> bundle-only-attribute =3D %s"bundle-only" >> >> ....right? > > No. Because I don't want to use ABNF to define the *name* of the attribut= e. So no 'attribute =3D/ ...'. Why not? It's not too long ago that it was decided that one shall use that = format for defining new SIP header fields, header field parameters etc. > Just ABNF for the *value* of the attribute. When the attribute has no val= ue, then no ABNF at all. See now sendrecv is defined. I'll do it that way, in order to be aligned with 4566bis, but I am not sure= I agree it is the best way. But, let's discuss that within the scope of 45= 66bis, as it's not BUNDLE specific. Regards, Christer From nobody Wed Oct 22 12:01:12 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8EF1AD0AE for ; Wed, 22 Oct 2014 12:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgnTndE3YI94 for ; Wed, 22 Oct 2014 12:01:09 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35811AD021 for ; Wed, 22 Oct 2014 12:00:58 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-05v.sys.comcast.net with comcast id 6Jz91p0014ueUHc01K0y1s; Wed, 22 Oct 2014 19:00:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-03v.sys.comcast.net with comcast id 6K0w1p00S3Ge9ey01K0x4n; Wed, 22 Oct 2014 19:00:57 +0000 Message-ID: <5447FEE8.2060801@alum.mit.edu> Date: Wed, 22 Oct 2014 15:00:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> <5447BCB9.2030607@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C186C@ESESSMB209.ericsson.se> <5447C54A.6020406@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C1B58@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C1B58@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414004458; bh=YImeKhTNn7OeIfX/6u90j30s/vZokcXVS8QXhlTolB0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=v+On2/Oe6yNEr9/E2nR+aOrHcobotI5VKiITCx3rxzxZYFLAz8vghKckj3dvpxW7d dANXctUSWUykx2LrSeRKt/whgzHQTS3VSMOfdJuItDXk+0MeJR68T4eUixVSC6Q61w VJxL3BBEe515agiZQ7HWES6nhHQ5IByiULoKCkxP5iiM/K4L8OtRkgsVK8F0h1praH viMBesvgtCCZi9DdUDM85B+m+L8ZOUf0oKVKcGyADuPb7RClyJBhtjfce3wU/wOLeQ do0V7hM6kcHxCePEYwv58fRPBFrotveO6YvAjZXfXKdWR1wXRl3Igx95lxThpojUV/ svDZsKTHm1eTA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/d8bsBcm0i4Hk2M3D7Xj0klGW_aU Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:01:11 -0000 On 10/22/14 2:12 PM, Christer Holmberg wrote: > Hi, > >>>>> I have NOT added the ABNF to the IANA registrations, as suggested by >>>>> Paul, because I don't think it is needed there, and I will provide a comment on 4566bis regarding that. >>>>> ... >>>>> Syntax: >>>>> >>>>> attribute =/ bundle-only-attribute >>>>> >>>>> bundle-only-attribute = "bundle-only" >>>> >>>> The above looks like ABNF to me. Just not of the form I have proposed in 4566bis. >>> >>> I know - I intend to give a comment on 4566bis, saying that I think the syntax shall be in >>> ABNF form. The only place 4566bis currently suggest to put the ABNF is in the IANA registration, >>> but I'd rather see it in the attribute definition. >> >> Why do you say that? Maybe I have more work to do on the IANA considerations section. Note that for the attributes defined in 4566bis, all the info describing an attribute > is in the body of the rfc, in section 6, not in the IANA considerations section. >> >> The iana considerations section of 4566bis can't look like it would in an extension draft because it also has all the instructions on how to do it in extension drafts. > > Sorry, I was unclear. I am not talking about the IANA considerations of 4566bis, but what information would be in the IANA considerations of a draft defining an SDP attribute. > > Section 8.2.4 of 4566bis, which contains the information that someone defining an attribute sends to IANA, contains the following: > > "o An ABNF definition of the attribute value rule. The rule MUST NOT > match anything that is not also matched by . The rule > name SHOULD [MUST?] NOT be defined as an Incremental Alternative > to ." > > I don't think we need the ABNF in the information sent to IANA when registering an attribute. > >> I would expect a draft like yours to have a section defining the attribute, in a form like those in 4566bis have, and >> then an IANA considerations section that references the SDP Attributes table and references where in the draft the definition is. > > Yes, that is how I also would like to have it :) > > But, as described above, my understanding of section 8.2.4 is that I will now have to send the ABNF to IANA when registering the attribute. It was not my intent that you have to send *anything* to IANA separately from your draft. The information needs to be in the draft, and your IANA considerations should only need to point to the section of your draft where the information is. >>>> Since this attribute has no value, the form in 4566bis would have no ABNF. >>>> >>>> And using an ABNF quoted string to define the name of the attribute causes it to be case-insensitive, which is not expected for attributes. >>>> See Adam's comment on the msid draft for more on that: >>>> >>>> https://mailarchive.ietf.org/arch/msg/mmusic/02BXt6UYiw370oQs6Rwpocck >>>> nr4 >>> >>> Ok. So, based on the suggestion in that thread, the ABNF would be: >>> >>> attribute =/ bundle-only-attribute >>> >>> bundle-only-attribute = %s"bundle-only" >>> >>> ....right? >> >> No. Because I don't want to use ABNF to define the *name* of the attribute. So no 'attribute =/ ...'. > > Why not? It's not too long ago that it was decided that one shall use that format for defining new SIP header fields, header field parameters etc. A few reasons: 1) 4566 never had ABNF including the names of specific attributes in the definition of . 2) if ABNF is used to define the attribute name, then the use of a quoted string causes the name to be case insensitive, while 4566 expects it to be case sensitive. (Of course this is less of a problem with my ABNF extension.) 3) Defining the attributes as extensions to the 4566 ABNF makes it difficult to validate the ABNF. You need to merge the two ABNFs together. In principle you need to merge *all* of the attribute definitions, and ensure that they don't conflict with each other. >> Just ABNF for the *value* of the attribute. When the attribute has no value, then no ABNF at all. See now sendrecv is defined. > > I'll do it that way, in order to be aligned with 4566bis, but I am not sure I agree it is the best way. But, let's discuss that within the scope of 4566bis, as it's not BUNDLE specific. The -12 version has been posted for awhile now. And I've made multiple requests for review, but there have as yet been none. I fully expect that it will need some tweaking. And it is possible that the consensus will be for a different approach. But until some comments come in it is what it is. Thanks, Paul From nobody Wed Oct 22 14:52:24 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908601A86E5 for ; Wed, 22 Oct 2014 14:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKaNOgr4MFHJ for ; Wed, 22 Oct 2014 14:52:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D03B1A86F1 for ; Wed, 22 Oct 2014 14:52:14 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-df-5448270c065c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D5.06.04081.C0728445; Wed, 22 Oct 2014 23:52:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 23:52:12 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute Thread-Index: Ac/t9UbtecZYZKzdQDWkACrUqUyK3P//+gqA///arACAAC+KAP//qilQgACahgD//7N4cA== Date: Wed, 22 Oct 2014 21:52:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C3078@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> <5447BCB9.2030607@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C186C@ESESSMB209.ericsson.se> <5447C54A.6020406@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C1B58@ESESSMB209.ericsson.se> <5447FEE8.2060801@alum.mit.edu> In-Reply-To: <5447FEE8.2060801@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+JvjS6PukeIwc75qhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRdGclY8Ej5or5h5YyNTD+Z+pi5OSQEDCR OLNiF5QtJnHh3nq2LkYuDiGBo4wSZ47NYoJwljBKXG+5yNrFyMHBJmAh0f1PG6RBRMBX4tnj 22ANwgINjBLLl7UwgzgiAo2MEqsvrmGFqAqTuPn8JguIzSKgKnHo2zWwdbxA3d2db1kgNuxm kviz6ysjSIJTQEfifOtrMJsR6Kbvp9aANTALiEvcejIf6lYBiSV7zjND2KISLx//Y4WwlSQW 3f4MVa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIHRcnDLb4MdjC+fOx5iFOBgVOLhXcDvHiLEmlhWXJl7iFGa g0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgDFk6earY43Zozturp0YTD2/4s nLoo9fX9M39SzCQrtm22mbI/oCDVyunky6VNEb6ccj5Tt2k7Pby145b5gus2t3VfGPpsKt4n y3zx1QvR46b5X3L+7KtOXi+7Q4Px9dyIxR45n8M8lm4Rc3t3hnVTnJls9Bwf3cZz4ov53qSY Tp579OmxI/YdSizFGYmGWsxFxYkASusKn3cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3x6xCnNwFQptUWSOWEWEevWDkaQ Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 21:52:22 -0000 Hi, I'll drop the ABNF discussion - I think we have more important things to fo= cus on (IF I still have some comments, I'll provide them within the context= of my SDP directorate review of 4566bis). As long as it is clear to everyo= ne how to define, register and implement the attributes, that's what matter= s :) Tomorrow I'll generate new BUNDLE text for the bundle-only definition/IANA = considerations, according to 4566bis-12. Thanks! Regards, Christer From nobody Wed Oct 22 16:33:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0C41A6F65 for ; Wed, 22 Oct 2014 16:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dNs45XChGlE for ; Wed, 22 Oct 2014 16:33:42 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BA31A6F3A for ; Wed, 22 Oct 2014 16:33:41 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id C584F2E848F28; Wed, 22 Oct 2014 23:33:36 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9MNXe5D031530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 19:33:41 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 19:33:40 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "DRAGE, Keith (Keith)" Thread-Topic: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 Thread-Index: AQHP7NemWaWCYcXI9U6748OuwSozPJw6vsdwgABbdgD//736gIABnEMAgABJhaA= Date: Wed, 22 Oct 2014 23:33:39 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B262638@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5445C65B.6040804@alum.mit.edu> <54469E76.1010806@alum.mit.edu> <5447C0E8.2080604@alum.mit.edu> In-Reply-To: <5447C0E8.2080604@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/C8SVAu45EVSKodBZ_fa_ULI8GpE Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 23:33:44 -0000 Hi Paul, >> Is there a reason to exclude those? Perhaps simply note that webrtc > >> doesn't support those two combinations. > > > > > > As mentioned, by definition max-retr and max-time are mutually exclusiv= e. > > Section "5.1.2 Methods" of http://w3c.github.io/webrtc-pc/ says: > >> 5. If both the maxPacketLifeTime and maxRetransmits attributes are set > (not null), > >> then throw a SyntaxError exception and abort these steps. > > > > So, I think rejecting such an SDP offer is acceptable here. >=20 > OK. You have convinced me. So there should be some text stating that > max-retr and max-time are mutually exclusive. (It isn't feasible to > impose such a constraint in the ABNF. I could do it, but it would be ugly= .) Agreed. I think text alone, instead of (or in-addition to) complex/ugly ABN= F, is good as it probably makes it more direct. So, we will add text. Thanks Raju From nobody Wed Oct 22 22:36:04 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AA31A88D3 for ; Wed, 22 Oct 2014 22:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD-uR4rzj_K4 for ; Wed, 22 Oct 2014 22:36:00 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374BC1A88D0 for ; Wed, 22 Oct 2014 22:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14412; q=dns/txt; s=iport; t=1414042561; x=1415252161; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=jddDrGfafdQZTkyfJquk17t2Z7bvuna0QBJt1V+xslo=; b=cWAUAfWIZigbgTcp0dcLRGMuc9DkBgUhfo4YoI+WQ1uYVsHyEcvBLBdf tMMtbNCpLc9+jzfC4U1FBX0Ct7/ARpRi91PnFFj4FJdWQtOUyme0K3lrc xAkdimMVjR3IWEbmtniMA/VTmcNxF9u4HcmqPQfr/yr1Iu+zjosNDtdMM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkLAOiSSFStJV2P/2dsb2JhbABcgkhGVFiIYbApAQEBAQEBBQFzkmcBC4Z3VAKBDhYBfYQCAQEBAwEBAQEaEEEKERwEAQEBCRYIBwkDAgECARUfAwEFCAYBDAYCAQEFiDAIDcgPAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4YlijiESwWGLZcwh2yOQYI0gWAhLwGCSgEBAQ X-IronPort-AV: E=Sophos; i="5.04,773,1406592000"; d="scan'208,217"; a="89563894" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 23 Oct 2014 05:36:00 +0000 Received: from [10.86.242.62] (che-vpn-cluster-2-62.cisco.com [10.86.242.62]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9N5ZvuQ024553; Thu, 23 Oct 2014 05:35:57 GMT Message-ID: <544893BD.2030706@cisco.com> Date: Thu, 23 Oct 2014 01:35:57 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "Stach, Thomas" , =?ISO-8859-1?Q?Ari_Ker=E4nen?= , mmusic References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D481271@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D481271@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------080007080409000804010809" Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XJHsxs1fWU4mQ16st_zDkzXttFg Subject: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 05:36:03 -0000 This is a multi-part message in MIME format. --------------080007080409000804010809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit In terms of consensus call, we had pretty strong consensus in the meeting for option #3 (see under http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.1yc63e74pbhi). To recap, the options and consensus outcome were: 3 options 1. Current 5245 behavior (only if change from default candidate) 2. MUST always do updated O/A (whether change or not) 3. "Ekr's" proposal: you do it or don't do it, but you indicate in the o/a if you're going to do it. Basically want to have option to never do the updated O/A exchange, with an indication in the signaling that you will not be doing it. Of course can always initiate a new O/A exchange whenever you want to. Consensus call by chair (Flemming): 0 for option 1 3 for option 2 15 for option 3 Since then, Ari started a thread to find out if option 3 was causing major problems for people, and if so, if there were a (better ?) way of addressing those. This is essentialy what this whole "ICE updated offer" thread has been about. From a chair point of view, I think it's fair to say that we have heard additional points of view and proposals as part of this thread, but that we also only heard from a subset of the people involved in the discussion at IETF 90. What I would suggest is that the author (Ari) actively engages the people that expressed an opinion at IETF 90 in this discussion to get their points of view. We can then discuss at IETF 91 again and take another consensus call based on all the information available. We will make sure to also take that consensus call to the mailing list subsequently to hopefully agree on the way forward (or at least get explicit consensus). Thanks -- Flemming (as MMUSIC co-chair). On 10/17/14, 7:08 AM, Christer Holmberg wrote: > Hi, > > There was a consensus call for 3, so the minutes are correct. > > I apologize if I should have challenged the minutes, rather than > waiting for an explicit verification call from the chairs. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Stach, Thomas > Sent: ?17/?10/?2014 13:58 > To: Christer Holmberg ; Ari > Keränen ; mmusic > Subject: RE: [MMUSIC] ICE updated offer - Back to the initial question > > > > > Hi, > > > > Whatever decisions are made at the meetings must (or, at least that > seem to > > be de facto practise) be confirmed on the mailing list. > You're right I also haven't seen an explicit consensus call on the list. > But there also wasn't objection against the minutes and they say: > "Chair calls consensus on option 3." > Maybe the chairs can help where we are wrt to consensus or not consensus. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------080007080409000804010809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In terms of consensus call, we had pretty strong consensus in the meeting for option #3 (see under http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.1yc63e74pbhi). To recap, the options and consensus outcome were:

<quote>

3 options

1. Current 5245 behavior (only if change from default candidate)

2. MUST always do updated O/A (whether change or not)

3. "Ekr's" proposal: you do it or don’t do it, but you indicate in the o/a if you’re going to do it. Basically want to have option to never do the updated O/A exchange, with an indication in the signaling that you will not be doing it. Of course can always initiate a new O/A exchange whenever you want to.

 

Consensus call by chair (Flemming):

0 for option 1

3 for option 2

15 for option 3
</quote>


Since then, Ari started a thread to find out if option 3 was causing major problems for people, and if so, if there were a (better ?) way of addressing those. This is essentialy what this whole "ICE updated offer" thread has been about.

From a chair point of view, I think it's fair to say that we have heard additional points of view and proposals as part of this thread, but that we also only heard from a subset of the people involved in the discussion at IETF 90. What I would suggest is that the author (Ari) actively engages the people that expressed an opinion at IETF 90 in this discussion to get their points of view. We can then discuss at IETF 91 again and take another consensus call based on all the information available. We will make sure to also take that consensus call to the mailing list subsequently to hopefully agree on the way forward (or at least get explicit consensus).

Thanks

-- Flemming (as MMUSIC co-chair).




On 10/17/14, 7:08 AM, Christer Holmberg wrote:
Hi,

There was a consensus call for 3, so the minutes are correct.

I apologize if I should have challenged the minutes, rather than waiting for an explicit verification call from the chairs.

Regards,

Christer

Sent from my Windows Phone
From: Stach, Thomas
Sent: ‎17/‎10/‎2014 13:58
To: Christer Holmberg; Ari Keränen; mmusic
Subject: RE: [MMUSIC]  ICE updated offer - Back to the initial question

>
> Hi,
>
> Whatever decisions are made at the meetings must (or, at least that seem to
> be de facto practise) be confirmed on the mailing list.
You're right I also haven't seen an explicit consensus call on the list.
But there also wasn't objection against the minutes and they say:
"Chair calls consensus on option 3."
Maybe the chairs can help where we are wrt to consensus or not consensus. 



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

--------------080007080409000804010809-- From nobody Thu Oct 23 00:54:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA8A1A88FF for ; Thu, 23 Oct 2014 00:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TifuZJP3lOH6 for ; Thu, 23 Oct 2014 00:54:16 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD181A88F8 for ; Thu, 23 Oct 2014 00:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4407; q=dns/txt; s=iport; t=1414050816; x=1415260416; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xMBjiGvHU/p3mCmtEpL585cQh47cmkMTqtJDbmwZjtE=; b=Bfc4HUPyvsZ8wQfn6AKZh3R+HxV8Ur+Uc0nv3gAvdXT5aREoNwMf4Nzx G+EocM/G8MTPbdb8HzE0Mijt8Q6ifVUKm+KLssaHwvYjWLFeO5288XBmW uQOnlI78bWfqqL5A96GYT4QZFQlSKHBjUFBGSEUPB0gYa/I4PSkHgGU8A s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAMGySFStJV2R/2dsb2JhbABcgw5UWATMeYdLAoENFgF9hAMBAQR5EAIBCAQKMQcyFBECBA4FG4gmDcdpAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQUgQHgy2BHgWLJYZghEaHEoExhnaOBoN4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,774,1406592000"; d="scan'208,217";a="365695653" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 23 Oct 2014 07:53:35 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9N7rYGE010452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 07:53:34 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 02:53:34 -0500 From: "Pal Martinsen (palmarti)" To: Simon Perreault Thread-Topic: [MMUSIC] ICE Dual Stack Fairness (was: Milestones changed for mmusic WG) Thread-Index: AQHP7T7TX2WMQgQKTUq1fTtTVtC2V5w9pjaA Date: Thu, 23 Oct 2014 07:53:33 +0000 Message-ID: References: <20141017222826.30724.11722.idtracker@ietfa.amsl.com> <761C04CA-32BA-4BF9-87DE-A8EFED61105C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.81.13] Content-Type: multipart/alternative; boundary="_000_AFAC204C644049AD95E6B49F2F5C5043ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Xex148W38aeoqGntUdIC868iavU Cc: mmusic Subject: Re: [MMUSIC] ICE Dual Stack Fairness (was: Milestones changed for mmusic WG) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 07:54:19 -0000 --_000_AFAC204C644049AD95E6B49F2F5C5043ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 21 Oct 2014, at 16:53, Simon Perreault > wrote: On Tue, Oct 21, 2014 at 4:11 AM, Pal Martinsen (palmarti) > wrote: We submitted a new draft that we believe cover the new milestone. https://tools.ietf.org/html/draft-martinsen-mmusic-ice-dualstack-fairness-0= 0 I just read this for the first time. Forgive me if this has been discussed = before... As an implementer I would prefer if there was "the one true" algo= rithm that I can go and implement and not have to think. Having an example = algorithm in an appendix makes me uneasy. If the algorithm is not contentio= us, why not make it normative? This have been briefly discussed. Some ICE implementations already do simil= ar tricks to solve this problem. The main purpose of the draft is to make i= mplementers aware that their might be a problem and hint that there is a so= lution they can use. That said, I completely agree that the algorithm should be normative. The algorithm in the draft already has wording in there to allow for implem= entation specific modifications. And should be able to handle any old ICE i= mplementations without braking anything. Anyone with objections regarding making the proposed algorithm normative in= the draft? .-. P=E5l-Erik Thanks, Simon --_000_AFAC204C644049AD95E6B49F2F5C5043ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On 21 Oct 2014, at 16:53, Simon Perreault <sperreault@jive.com> wrote:


On Tue, Oct 21, 2014 at 4:11 AM, Pal Martinsen (= palmarti) <palmarti@cisco.com> wrote:
We submitted a new= draft that we believe cover the new milestone.

https://tools.ietf.org/html/draft-martinsen= -mmusic-ice-dualstack-fairness-00

I just read this for the first time. Forgive me if this has been discussed = before... As an implementer I would prefer if there was "the one true&= quot; algorithm that I can go and implement and not have to think. Having a= n example algorithm in an appendix makes me uneasy. If the algorithm is not contentious, why not make it normative?


This have been briefly discussed. Some ICE implementations already do = similar tricks to solve this problem. The main purpose of the draft is to m= ake implementers aware that their might be a problem and hint that there is= a solution they can use. 

That said, I completely agree that the algorithm should be normative.&= nbsp;

The algorithm in the draft already has wording in there to allow for i= mplementation specific modifications. And should be able to handle any old = ICE implementations without braking anything. 

Anyone with objections regarding making the proposed algorithm normati= ve in the draft?

.-.
P=E5l-Erik

Thanks,
Simon

--_000_AFAC204C644049AD95E6B49F2F5C5043ciscocom_-- From nobody Thu Oct 23 01:04:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195F21A88FE for ; Thu, 23 Oct 2014 01:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW_h054-Jrzj for ; Thu, 23 Oct 2014 01:04:31 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4F41A88F5 for ; Thu, 23 Oct 2014 01:04:30 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id e86b8445.2b7b14c8d940.2488611.00-2446.6954246.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 23 Oct 2014 08:04:30 +0000 (UTC) X-MXL-Hash: 5448b68e11459d5c-e6f65cb15407f3b6f5600be4d37be44b70999cb8 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id b86b8445.0.2488597.00-2365.6954212.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 23 Oct 2014 08:04:28 +0000 (UTC) X-MXL-Hash: 5448b68c5340024a-85d6702c1604ea461671af2ee832c9ed29357c93 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9N84ROj024619; Thu, 23 Oct 2014 04:04:27 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9N84KcP024612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Oct 2014 04:04:23 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 23 Oct 2014 08:04:09 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.207]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 04:04:09 -0400 From: "DOLLY, MARTIN C" To: Flemming Andreasen , Christer Holmberg , "Stach, Thomas" , =?utf-8?B?QXJpIEtlcsOkbmVu?= , mmusic Thread-Topic: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] Thread-Index: AQHP7oNAhGoevhBCvUKrSKv09fCWwpw9UZHQ Date: Thu, 23 Oct 2014 08:04:08 +0000 Message-ID: References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D481271@ESESSMB209.ericsson.se> <544893BD.2030706@cisco.com> In-Reply-To: <544893BD.2030706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.234.63] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656032A03D8MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=X9rl3hve c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=nPd00b4jHLYA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=4QX1zJ9iAA] X-AnalysisOut: [AA:8 a=0FD05c-RAAAA:8 a=p3qQXDehg5he10yyo-4A:9 a=QEXdDO2ut] X-AnalysisOut: [3YA:10 a=qM39cor4HRgA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:] X-AnalysisOut: [10 a=2Q6QyxRqr2UA:10 a=f7GxY0FH8QIA:10 a=PmBGqXwlzwFGheJA:] X-AnalysisOut: [21 a=J8y2It8r74v40TCo:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8] X-AnalysisOut: [ a=GdEs0S4sXNoZWMVd7_QA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A] X-AnalysisOut: [:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=CJ2fn9qQqpyawed8] X-AnalysisOut: [:21 a=ecYtVsSyHt548mhr:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZdxRI5HtvfNXx9urBgLy-sFWpQU Subject: Re: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 08:04:37 -0000 --_000_E42CCDDA6722744CB241677169E83656032A03D8MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2h5IGFyZSB5b3UgcGxheWluZyBhcm91bmQgd2l0aCBTRFA/DQpHZXR0aW5nIFNEUCBvZmZlci9h bnN3ZXIgdG8gd29yayBpcyBkaWZmaWN1bHQgYXMgaXQgaXMuDQpOb3QgYmVpbmcgYWJsZSB0byBy ZWx5IG9uIFNEUCBpbmZvcm1hdGlvbiB0byBiZWdpbiB3aXRoIGlzIHRoZSB3cm9uZyB3YXkgZm9y d2FyZCwgYW5kIGl0IHdpbGwgaGF2ZSBiaWcgaW1wYWN0cyBvbiBleGlzdGluZyBTSVAgYmFzZWQg ZGVwbG95bWVudHMuDQpJbnRlcm9wZXJhYmlsaXR5IHdpdGggZXhpc3RpbmcgU0lQIGRlcGxveW1l bnRzIGlzIHZlcnkgaW1wb3J0YW50Lg0KDQpSZWdhcmRzLA0KDQpNYXJ0aW4gRG9sbHkNCkxlYWQg TWVtYmVyIFRlY2huaWNhbCBTdGFmZg0KQ29yZSAmIEdvdmVybm1lbnQvUmVndWxhdG9yeSBTdGFu ZGFyZHMNCkFUJlQgU3RhbmRhcmRzIGFuZCBJbmR1c3RyeSBBbGxpYW5jZXMNCm1kMzEzNUBhdHQu Y29tPG1haWx0bzptZDMxMzVAYXR0LmNvbT4NCisxLTYwOS05MDMtMzM2MA0KDQoNCkZyb206IG1t dXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRmxlbW1p bmcgQW5kcmVhc2VuDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMywgMjAxNCAxOjM2IEFNDQpU bzogQ2hyaXN0ZXIgSG9sbWJlcmc7IFN0YWNoLCBUaG9tYXM7IEFyaSBLZXLDpG5lbjsgbW11c2lj DQpTdWJqZWN0OiBbTU1VU0lDXSBSZXZpc2l0IGNvbnNlbnN1cyA/IFtSZTogSUNFIHVwZGF0ZWQg b2ZmZXIgLSBCYWNrIHRvIHRoZSBpbml0aWFsIHF1ZXN0aW9uXQ0KDQpJbiB0ZXJtcyBvZiBjb25z ZW5zdXMgY2FsbCwgd2UgaGFkIHByZXR0eSBzdHJvbmcgY29uc2Vuc3VzIGluIHRoZSBtZWV0aW5n IGZvciBvcHRpb24gIzMgKHNlZSB1bmRlciBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz LzkwL21pbnV0ZXMvbWludXRlcy05MC1tbXVzaWMjaC4xeWM2M2U3NHBiaGkpLiBUbyByZWNhcCwg dGhlIG9wdGlvbnMgYW5kIGNvbnNlbnN1cyBvdXRjb21lIHdlcmU6DQoNCjxxdW90ZT4NCg0KDQoz IG9wdGlvbnMNCg0KMS4gQ3VycmVudCA1MjQ1IGJlaGF2aW9yIChvbmx5IGlmIGNoYW5nZSBmcm9t IGRlZmF1bHQgY2FuZGlkYXRlKQ0KDQoyLiBNVVNUIGFsd2F5cyBkbyB1cGRhdGVkIE8vQSAod2hl dGhlciBjaGFuZ2Ugb3Igbm90KQ0KDQozLiAiRWtyJ3MiIHByb3Bvc2FsOiB5b3UgZG8gaXQgb3Ig ZG9u4oCZdCBkbyBpdCwgYnV0IHlvdSBpbmRpY2F0ZSBpbiB0aGUgby9hIGlmIHlvdeKAmXJlIGdv aW5nIHRvIGRvIGl0LiBCYXNpY2FsbHkgd2FudCB0byBoYXZlIG9wdGlvbiB0byBuZXZlciBkbyB0 aGUgdXBkYXRlZCBPL0EgZXhjaGFuZ2UsIHdpdGggYW4gaW5kaWNhdGlvbiBpbiB0aGUgc2lnbmFs aW5nIHRoYXQgeW91IHdpbGwgbm90IGJlIGRvaW5nIGl0LiBPZiBjb3Vyc2UgY2FuIGFsd2F5cyBp bml0aWF0ZSBhIG5ldyBPL0EgZXhjaGFuZ2Ugd2hlbmV2ZXIgeW91IHdhbnQgdG8uDQoNCg0KDQpD b25zZW5zdXMgY2FsbCBieSBjaGFpciAoRmxlbW1pbmcpOg0KDQowIGZvciBvcHRpb24gMQ0KDQoz IGZvciBvcHRpb24gMg0KDQoxNSBmb3Igb3B0aW9uIDMNCjwvcXVvdGU+DQoNCg0KU2luY2UgdGhl biwgQXJpIHN0YXJ0ZWQgYSB0aHJlYWQgdG8gZmluZCBvdXQgaWYgb3B0aW9uIDMgd2FzIGNhdXNp bmcgbWFqb3IgcHJvYmxlbXMgZm9yIHBlb3BsZSwgYW5kIGlmIHNvLCBpZiB0aGVyZSB3ZXJlIGEg KGJldHRlciA/KSB3YXkgb2YgYWRkcmVzc2luZyB0aG9zZS4gVGhpcyBpcyBlc3NlbnRpYWx5IHdo YXQgdGhpcyB3aG9sZSAiSUNFIHVwZGF0ZWQgb2ZmZXIiIHRocmVhZCBoYXMgYmVlbiBhYm91dC4N Cg0KRnJvbSBhIGNoYWlyIHBvaW50IG9mIHZpZXcsIEkgdGhpbmsgaXQncyBmYWlyIHRvIHNheSB0 aGF0IHdlIGhhdmUgaGVhcmQgYWRkaXRpb25hbCBwb2ludHMgb2YgdmlldyBhbmQgcHJvcG9zYWxz IGFzIHBhcnQgb2YgdGhpcyB0aHJlYWQsIGJ1dCB0aGF0IHdlIGFsc28gb25seSBoZWFyZCBmcm9t IGEgc3Vic2V0IG9mIHRoZSBwZW9wbGUgaW52b2x2ZWQgaW4gdGhlIGRpc2N1c3Npb24gYXQgSUVU RiA5MC4gV2hhdCBJIHdvdWxkIHN1Z2dlc3QgaXMgdGhhdCB0aGUgYXV0aG9yIChBcmkpIGFjdGl2 ZWx5IGVuZ2FnZXMgdGhlIHBlb3BsZSB0aGF0IGV4cHJlc3NlZCBhbiBvcGluaW9uIGF0IElFVEYg OTAgaW4gdGhpcyBkaXNjdXNzaW9uIHRvIGdldCB0aGVpciBwb2ludHMgb2Ygdmlldy4gV2UgY2Fu IHRoZW4gZGlzY3VzcyBhdCBJRVRGIDkxIGFnYWluIGFuZCB0YWtlIGFub3RoZXIgY29uc2Vuc3Vz IGNhbGwgYmFzZWQgb24gYWxsIHRoZSBpbmZvcm1hdGlvbiBhdmFpbGFibGUuIFdlIHdpbGwgbWFr ZSBzdXJlIHRvIGFsc28gdGFrZSB0aGF0IGNvbnNlbnN1cyBjYWxsIHRvIHRoZSBtYWlsaW5nIGxp c3Qgc3Vic2VxdWVudGx5IHRvIGhvcGVmdWxseSBhZ3JlZSBvbiB0aGUgd2F5IGZvcndhcmQgKG9y IGF0IGxlYXN0IGdldCBleHBsaWNpdCBjb25zZW5zdXMpLg0KDQpUaGFua3MNCg0KLS0gRmxlbW1p bmcgKGFzIE1NVVNJQyBjby1jaGFpcikuDQoNCg0KDQpPbiAxMC8xNy8xNCwgNzowOCBBTSwgQ2hy aXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQpIaSwNCg0KVGhlcmUgd2FzIGEgY29uc2Vuc3VzIGNhbGwg Zm9yIDMsIHNvIHRoZSBtaW51dGVzIGFyZSBjb3JyZWN0Lg0KDQpJIGFwb2xvZ2l6ZSBpZiBJIHNo b3VsZCBoYXZlIGNoYWxsZW5nZWQgdGhlIG1pbnV0ZXMsIHJhdGhlciB0aGFuIHdhaXRpbmcgZm9y IGFuIGV4cGxpY2l0IHZlcmlmaWNhdGlvbiBjYWxsIGZyb20gdGhlIGNoYWlycy4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBTdGFjaCwgVGhvbWFzPG1haWx0bzp0aG9tYXMu c3RhY2hAdW5pZnkuY29tPg0KU2VudDog4oCOMTcv4oCOMTAv4oCOMjAxNCAxMzo1OA0KVG86IENo cmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBB cmkgS2Vyw6RuZW48bWFpbHRvOmFyaS5rZXJhbmVuQGVyaWNzc29uLmNvbT47IG1tdXNpYzxtYWls dG86bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtNTVVTSUNdICBJQ0UgdXBkYXRlZCBv ZmZlciAtIEJhY2sgdG8gdGhlIGluaXRpYWwgcXVlc3Rpb24NCj4NCj4gSGksDQo+DQo+IFdoYXRl dmVyIGRlY2lzaW9ucyBhcmUgbWFkZSBhdCB0aGUgbWVldGluZ3MgbXVzdCAob3IsIGF0IGxlYXN0 IHRoYXQgc2VlbSB0bw0KPiBiZSBkZSBmYWN0byBwcmFjdGlzZSkgYmUgY29uZmlybWVkIG9uIHRo ZSBtYWlsaW5nIGxpc3QuDQpZb3UncmUgcmlnaHQgSSBhbHNvIGhhdmVuJ3Qgc2VlbiBhbiBleHBs aWNpdCBjb25zZW5zdXMgY2FsbCBvbiB0aGUgbGlzdC4NCkJ1dCB0aGVyZSBhbHNvIHdhc24ndCBv YmplY3Rpb24gYWdhaW5zdCB0aGUgbWludXRlcyBhbmQgdGhleSBzYXk6DQoiQ2hhaXIgY2FsbHMg Y29uc2Vuc3VzIG9uIG9wdGlvbiAzLiINCk1heWJlIHRoZSBjaGFpcnMgY2FuIGhlbHAgd2hlcmUg d2UgYXJlIHdydCB0byBjb25zZW5zdXMgb3Igbm90IGNvbnNlbnN1cy4NCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbW11c2ljIG1haWxp bmcgbGlzdA0KDQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K --_000_E42CCDDA6722744CB241677169E83656032A03D8MISOUT7MSGUSRDB_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5u b3JtYWwsIGxpLm5vcm1hbCwgZGl2Lm5vcm1hbA0KCXttc28tc3R5bGUtbmFtZTpub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30N CnAuZW1haWxxdW90ZSwgbGkuZW1haWxxdW90ZSwgZGl2LmVtYWlscXVvdGUNCgl7bXNvLXN0eWxl LW5hbWU6ZW1haWxxdW90ZTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjEuMHB0 Ow0KCWJvcmRlcjpub25lOw0KCXBhZGRpbmc6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPldoeSBhcmUgeW91IHBsYXlpbmcgYXJvdW5kIHdpdGggU0RQPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2V0dGluZyBTRFAgb2ZmZXIvYW5zd2VyIHRv IHdvcmsgaXMgZGlmZmljdWx0IGFzIGl0IGlzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Ob3QgYmVpbmcgYWJsZSB0byByZWx5IG9uIFNEUCBpbmZvcm1hdGlv biB0byBiZWdpbiB3aXRoIGlzIHRoZSB3cm9uZyB3YXkgZm9yd2FyZCwgYW5kIGl0IHdpbGwgaGF2 ZSBiaWcgaW1wYWN0cyBvbiBleGlzdGluZyBTSVAgYmFzZWQgZGVwbG95bWVudHMuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkludGVyb3BlcmFiaWxpdHkgd2l0 aCBleGlzdGluZyBTSVAgZGVwbG95bWVudHMgaXMgdmVyeSBpbXBvcnRhbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NYXJ0aW4gRG9sbHk8 YnI+DQpMZWFkIE1lbWJlciBUZWNobmljYWwgU3RhZmY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q29yZSAmYW1wOyBHb3Zlcm5tZW50L1JlZ3VsYXRvcnkgU3RhbmRhcmRzPGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QVQmYW1wO1QgU3Rh bmRhcmRzIGFuZCBJbmR1c3RyeSBBbGxpYW5jZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCjxhIGhyZWY9Im1haWx0bzptZDMxMzVAYXR0LmNv bSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+bWQzMTM1QGF0dC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mIzQzOzEtNjA5LTkwMy0zMzYwPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+RmxlbW1pbmcgQW5kcmVhc2VuPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBPY3RvYmVyIDIzLCAyMDE0IDE6MzYgQU08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVy IEhvbG1iZXJnOyBTdGFjaCwgVGhvbWFzOyBBcmkgS2Vyw6RuZW47IG1tdXNpYzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBbTU1VU0lDXSBSZXZpc2l0IGNvbnNlbnN1cyA/IFtSZTogSUNFIHVwZGF0ZWQg b2ZmZXIgLSBCYWNrIHRvIHRoZSBpbml0aWFsIHF1ZXN0aW9uXTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRlcm1zIG9mIGNvbnNlbnN1cyBjYWxsLCB3 ZSBoYWQgcHJldHR5IHN0cm9uZyBjb25zZW5zdXMgaW4gdGhlIG1lZXRpbmcgZm9yIG9wdGlvbiAj MyAoc2VlIHVuZGVyDQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkw L21pbnV0ZXMvbWludXRlcy05MC1tbXVzaWMjaC4xeWM2M2U3NHBiaGkiPg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9taW51dGVzL21pbnV0ZXMtOTAtbW11c2ljI2guMXljNjNl NzRwYmhpPC9hPikuIFRvIHJlY2FwLCB0aGUgb3B0aW9ucyBhbmQgY29uc2Vuc3VzIG91dGNvbWUg d2VyZTo8YnI+DQo8YnI+DQombHQ7cXVvdGUmZ3Q7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibm9ybWFsIiBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQ7bGluZS1oZWlnaHQ6MTIuNjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MyBvcHRp b25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6 LS4yNWluO2JhY2tncm91bmQ6d2hpdGU7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dp ZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xLiBDdXJyZW50IDUyNDUgYmVoYXZpb3Ig KG9ubHkgaWYgY2hhbmdlIGZyb20gZGVmYXVsdCBjYW5kaWRhdGUpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO2JhY2tncm91bmQ6d2hp dGU7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4yLiBNVVNUIGFsd2F5cyBkbyB1cGRhdGVkIE8vQSAod2hldGhlciBjaGFuZ2Ug b3Igbm90KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5k ZW50Oi0uMjVpbjtiYWNrZ3JvdW5kOndoaXRlO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFy dDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+My4gJnF1b3Q7RWtyJ3MmcXVvdDsg cHJvcG9zYWw6IHlvdSBkbyBpdCBvciBkb27igJl0IGRvIGl0LCBidXQgeW91IGluZGljYXRlIGlu IHRoZSBvL2EgaWYgeW914oCZcmUgZ29pbmcgdG8gZG8gaXQuIEJhc2ljYWxseSB3YW50IHRvIGhh dmUgb3B0aW9uIHRvIG5ldmVyIGRvIHRoZSB1cGRhdGVkIE8vQSBleGNoYW5nZSwgd2l0aCBhbiBp bmRpY2F0aW9uIGluIHRoZQ0KIHNpZ25hbGluZyB0aGF0IHlvdSB3aWxsIG5vdCBiZSBkb2luZyBp dC4gT2YgY291cnNlIGNhbiBhbHdheXMgaW5pdGlhdGUgYSBuZXcgTy9BIGV4Y2hhbmdlIHdoZW5l dmVyIHlvdSB3YW50IHRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJub3JtYWwi IHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxMi42 NXB0O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjU1LA0KICAg ICAgMjU1KTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJub3JtYWwiIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxMi42NXB0O29ycGhhbnM6 IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjU1LA0KICAgICAgMjU1KTt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNlbnN1cyBjYWxs IGJ5IGNoYWlyIChGbGVtbWluZyk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im5v cm1hbCIgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xpbmUtaGVpZ2h0 OjEyLjY1cHQ7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LCAyNTUs DQogICAgICAyNTUpO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+MCBmb3Igb3B0aW9uIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibm9ybWFs IiBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6MTIu NjVwdDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsIDI1NSwNCiAg ICAgIDI1NSk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4z IGZvciBvcHRpb24gMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJub3JtYWwiIHN0 eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDoxMi42NXB0 O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjU1LA0KICAgICAg MjU1KTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjE1IGZv ciBvcHRpb24gMzxicj4NCiZsdDsvcXVvdGUmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Im5vcm1hbCIgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xp bmUtaGVpZ2h0OjEyLjY1cHQ7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2Io MjU1LCAyNTUsDQogICAgICAyNTUpO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5TaW5jZSB0aGVuLCBBcmkgc3RhcnRl ZCBhIHRocmVhZCB0byBmaW5kIG91dCBpZiBvcHRpb24gMyB3YXMgY2F1c2luZyBtYWpvciBwcm9i bGVtcyBmb3IgcGVvcGxlLCBhbmQgaWYgc28sIGlmIHRoZXJlIHdlcmUgYSAoYmV0dGVyID8pIHdh eSBvZiBhZGRyZXNzaW5nIHRob3NlLiBUaGlzIGlzIGVzc2VudGlhbHkgd2hhdCB0aGlzIHdob2xl ICZxdW90O0lDRSB1cGRhdGVkDQogb2ZmZXImcXVvdDsgdGhyZWFkIGhhcyBiZWVuIGFib3V0LiA8 YnI+DQo8YnI+DQpGcm9tIGEgY2hhaXIgcG9pbnQgb2YgdmlldywgSSB0aGluayBpdCdzIGZhaXIg dG8gc2F5IHRoYXQgd2UgaGF2ZSBoZWFyZCBhZGRpdGlvbmFsIHBvaW50cyBvZiB2aWV3IGFuZCBw cm9wb3NhbHMgYXMgcGFydCBvZiB0aGlzIHRocmVhZCwgYnV0IHRoYXQgd2UgYWxzbyBvbmx5IGhl YXJkIGZyb20gYSBzdWJzZXQgb2YgdGhlIHBlb3BsZSBpbnZvbHZlZCBpbiB0aGUgZGlzY3Vzc2lv biBhdCBJRVRGIDkwLiBXaGF0IEkgd291bGQgc3VnZ2VzdCBpcyB0aGF0DQogdGhlIGF1dGhvciAo QXJpKSBhY3RpdmVseSBlbmdhZ2VzIHRoZSBwZW9wbGUgdGhhdCBleHByZXNzZWQgYW4gb3Bpbmlv biBhdCBJRVRGIDkwIGluIHRoaXMgZGlzY3Vzc2lvbiB0byBnZXQgdGhlaXIgcG9pbnRzIG9mIHZp ZXcuIFdlIGNhbiB0aGVuIGRpc2N1c3MgYXQgSUVURiA5MSBhZ2FpbiBhbmQgdGFrZSBhbm90aGVy IGNvbnNlbnN1cyBjYWxsIGJhc2VkIG9uIGFsbCB0aGUgaW5mb3JtYXRpb24gYXZhaWxhYmxlLiBX ZSB3aWxsIG1ha2Ugc3VyZQ0KIHRvIGFsc28gdGFrZSB0aGF0IGNvbnNlbnN1cyBjYWxsIHRvIHRo ZSBtYWlsaW5nIGxpc3Qgc3Vic2VxdWVudGx5IHRvIGhvcGVmdWxseSBhZ3JlZSBvbiB0aGUgd2F5 IGZvcndhcmQgKG9yIGF0IGxlYXN0IGdldCBleHBsaWNpdCBjb25zZW5zdXMpLg0KPGJyPg0KPGJy Pg0KVGhhbmtzIDxicj4NCjxicj4NCi0tIEZsZW1taW5nIChhcyBNTVVTSUMgY28tY2hhaXIpLiA8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiAxMC8xNy8xNCwgNzowOCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8YnI+DQo8YnI+DQpU aGVyZSB3YXMgYSBjb25zZW5zdXMgY2FsbCBmb3IgMywgc28gdGhlIG1pbnV0ZXMgYXJlIGNvcnJl Y3QuPGJyPg0KPGJyPg0KSSBhcG9sb2dpemUgaWYgSSBzaG91bGQgaGF2ZSBjaGFsbGVuZ2VkIHRo ZSBtaW51dGVzLCByYXRoZXIgdGhhbiB3YWl0aW5nIGZvciBhbiBleHBsaWNpdCB2ZXJpZmljYXRp b24gY2FsbCBmcm9tIHRoZSBjaGFpcnMuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpD aHJpc3Rlcjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIg d2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBo cmVmPSJtYWlsdG86dGhvbWFzLnN0YWNoQHVuaWZ5LmNvbSI+U3RhY2gsIFRob21hczwvYT48L3Nw YW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50OiA8L3NwYW4+DQo8 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igI4xNy/igI4xMC/igI4yMDE0IDEzOjU4 PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIj5DaHJpc3RlciBIb2xtYmVyZzwvYT47DQo8YSBocmVmPSJt YWlsdG86YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tIj5BcmkgS2Vyw6RuZW48L2E+OyA8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIj4NCm1tdXNpYzwvYT48L3NwYW4+PGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5SRTogW01NVVNJQ10mbmJzcDsgSUNFIHVwZGF0ZWQgb2ZmZXIg LSBCYWNrIHRvIHRoZSBpbml0aWFsIHF1ZXN0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7DQo8YnI+DQom Z3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGF0ZXZlciBkZWNpc2lvbnMgYXJlIG1hZGUg YXQgdGhlIG1lZXRpbmdzIG11c3QgKG9yLCBhdCBsZWFzdCB0aGF0IHNlZW0gdG88YnI+DQomZ3Q7 IGJlIGRlIGZhY3RvIHByYWN0aXNlKSBiZSBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdC4g PGJyPg0KWW91J3JlIHJpZ2h0IEkgYWxzbyBoYXZlbid0IHNlZW4gYW4gZXhwbGljaXQgY29uc2Vu c3VzIGNhbGwgb24gdGhlIGxpc3QuIDxicj4NCkJ1dCB0aGVyZSBhbHNvIHdhc24ndCBvYmplY3Rp b24gYWdhaW5zdCB0aGUgbWludXRlcyBhbmQgdGhleSBzYXk6PGJyPg0KJnF1b3Q7Q2hhaXIgY2Fs bHMgY29uc2Vuc3VzIG9uIG9wdGlvbiAzLiZxdW90Ozxicj4NCk1heWJlIHRoZSBjaGFpcnMgY2Fu IGhlbHAgd2hlcmUgd2UgYXJlIHdydCB0byBjb25zZW5zdXMgb3Igbm90IGNvbnNlbnN1cy4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tbXVzaWMgbWFp bGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0Bp ZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E42CCDDA6722744CB241677169E83656032A03D8MISOUT7MSGUSRDB_-- From nobody Thu Oct 23 02:37:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D1C1A89C4 for ; Thu, 23 Oct 2014 02:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chyIMFOYNZkb for ; Thu, 23 Oct 2014 02:37:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A02E1A89B4 for ; Thu, 23 Oct 2014 02:37:12 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-84-5448cc46248e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AE.D8.24955.64CC8445; Thu, 23 Oct 2014 11:37:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 11:37:10 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute Thread-Index: Ac/t9UbtecZYZKzdQDWkACrUqUyK3P//+gqA///arACAAC+KAP//qilQgACahgD//7N4cP/+nwhg Date: Thu, 23 Oct 2014 09:37:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C3B64@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C16EB@ESESSMB209.ericsson.se> <5447BCB9.2030607@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C186C@ESESSMB209.ericsson.se> <5447C54A.6020406@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C1B58@ESESSMB209.ericsson.se> <5447FEE8.2060801@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C3078@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C3078@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvja7bGY8Qg0OTdC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj3NEn7AVH+Cv2XOBoYJzL3cXIySEhYCLx Y8EmFghbTOLCvfVsXYxcHEICRxklOv7eYoVwljBKXJ1wjKmLkYODTcBCovufNkiDiICvxLPH t8EahAUaGCWWL2thBnFEBBoZJVZfXMMKURUl8bJ3AROIzSKgKjFtx1+wdbxA3fs2/GGC2PCf SeLinlawIk4BP4lZH3aBNTMC3fT91BqwOLOAuMStJ/OZIG4VkFiy5zwzhC0q8fLxP1YIW0li 0e3PUPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqc lJtuZKyXWpSZXFycn6eXl1qyiREYKwe3/FbdwXj5jeMhRgEORiUe3oSZHiFCrIllxZW5hxil OViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR0GWy6sKV8ta6730OWunxcTJp Xjnw4FK53d0y1cSThwPYM96nulvUr7sz+duEfUI5U9+onFG70fmmd5rV+z3ciwoWC+9teb+6 Lj7Bx0faZUbvjJAertZJ3f7rwlbLhPVtmro83qEx/vBRj0lZ9fvmc1txV/SmGavsabhe9CZU 0G79p5KFHceVWIozEg21mIuKEwHVCbKfdgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/R_nllL0CQkukLjteYbdZvTu_tyM Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 09:37:14 -0000 Hi, Below is new suggested text for the bundle-only attribute definition, follo= wing the structure in 4566bis-12: SECTION 6: --------------- 6. SDP 'bundle-only' Attribute 6.1. General This section defines a new SDP media-level attribute [RFC4566], 'bundle-only'. 6.2. bundle-only Name: bundle-only Value: Usage Level: media Charset Dependent: no Example: a=3Dbundle-only The 'bundle-only' attribute can be associated with a bundled "m=3D" line in an offer, to request that the answerer only accepts the "m=3D" line if the answerer keeps the "m=3D" line within the associated BUNDLE group. In order to ensure that an answerer that does not supports the BUNDLE extension always *** rejects a 'bundle-only' "m=3D" line, the offerer can assign a zero port value to the "m=3D" line. According to [RFC4566] an answerer will reject such "m=3D" line. The usage of the 'bundle-only' attribute is only defined for a bundled "m=3D" line within an offer. Other usage is unspecified. [Section 8] defines the detailed SDP Offer/Answer procedures for the 'bundle-only' attribute. SECTION 14.3 (IANA Considerations): ------------------------------------------------- 14.3. New SDP Attribute [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document defines a new SDP media-level attribute, according to the following data: Attribute name: bundle-only Type of attribute: media Subject to charset: No Purpose: Request a media description to be accepted in the answer only if kept within a BUNDLE group by the answerer. Appropriate values: N/A Contact name: Christer Holmberg Contact e-mail: christer.holmberg@ericsson.com Reference: RFCXXXX Regards, Christer From nobody Thu Oct 23 02:45:37 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720F81A8A15 for ; Thu, 23 Oct 2014 02:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKm0QUhuv5nc for ; Thu, 23 Oct 2014 02:45:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527AD1A89AF for ; Thu, 23 Oct 2014 02:45:33 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-69-5448ce3b3f13 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E2.9A.21334.B3EC8445; Thu, 23 Oct 2014 11:45:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 11:45:30 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat Thread-Topic: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - associated DTLS with m- line Thread-Index: Ac/uphZ98xBO+uV/R5KePjNBqtwqKg== Date: Thu, 23 Oct 2014 09:45:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C3BB6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja71OY8Qg69rdSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj28yX7AWz5Co2vL/B1MA4QaKLkZNDQsBE Yv3fhWwQtpjEhXvrgWwuDiGBo4wS/+7MZIRwljBK7HnaB5Th4GATsJDo/qcN0iAiECcx7eRz VhCbWUBF4tXpy6wg9cIC7YwS3U9eMIE4IgIdjBLzZ25jhOjQk2h59BNsHYuAqsSfHUfYQWxe AV+JTa3PmEBsRqAzvp9awwQxVVzi1pP5TBDnCUgs2XOeGcIWlXj5+B8rhK0ksej2Z6h6HYkF uz+xQdjaEssWvmaGmC8ocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3K TC4uzs/Ty0st2cQIjImDW37r7mBc/drxEKMAB6MSD2/CTI8QIdbEsuLK3EOM0hwsSuK8i87N CxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOOv9jEn35e/t2bppfodqptzFh8enTXvmGvW0 /5NCem8pn85u7qBjMx4UypoqRIVkGwfw5TBGlwU0euXujD5385++YvKhPY5LbpqaTHnvdzj2 w9XSJe2l76XlJ2zUdt1pIx3kkd7xLC5KJmXX6dB3O4/ohZiJzJ8UfYtjwcYpDuZOV1lX/bnc q8RSnJFoqMVcVJwIADKxc7lqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/msAVSd9te4bpZPpZ4OnsgeN_S70 Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - associated DTLS with m- line X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 09:45:35 -0000 Hi, >>>>>>>>> What would you like to mention about SCTP? >>>>>>>>> >>>>>>>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but=20 >>>>>>>>>> doesn't use DTLS payload packets. So *one* m-line with a=20 >>>>>>>>>> protocol that uses DTLS payload packets (e.g., >DTLS/SCTP) can=20 >>>>>>>>>> coexist with STUN and SRTP. If there is more than one such m-lin= e then some other specification is required to associate those packets with= m-lines. >>>>>>>>> >>>>>>>>> I think that is covered, as SRTP is distinguished from DTLS. >>>>>>>>> >>>>>>>>> But, if you think that needs to be more clear, maybe the followin= g modified sentence: >>>>>>>>> >>>>>>>>> "[RFC5764] does not describe how to identify different protocols= transported on DTLS (i.e. using DTLS payload packets), only how to..." >>>>>>>>> >>>>>>>> I think this document should bite the bullet and define how SCTP c= oexists with SRTP in a bundle. >>>>>>> >>>>>>> Personally, I would not want to do that at this stage. We decided=20 >>>>>>> earlier that the draft will cover DTLS, SRTP and STUN, and that any= other protocols/combinations have to be defined elsewhere. >>>>>> >>>>>> If it isn't here, then it needs to be somewhere else. Where? >>>>> >>>>> In a separate draft. >>>>> >>>>>> It shouldn't be hard. >>>>> >>>>> Who is asking for it? RTCWEB will not support SCTP transport (they wi= ll support SCTP over DTLS). >>>> >>>> I'll be satisfied if it covers SCTP over DTLS. That is the case where = it needs to be able to coexist with RTP. >>> >>> The draft describes how you distinguish between DTLS and SRTP, so that = also covers SCTP over DTLS (SCTP is the "application protocol" carried on D= TLS). >>> >>> How you differentiate different protocols carried over DTLS need to be = described elsewhere, but if you only have SCTP carried over DTLS nothing el= se is needed. >>> >>> In addition, if you want to define how to separate SCTP from something = else, you would need to know what that something else is. >> >> The draft describes how to distinguish DTLS and SRTP packets. It doesn't= describe how to associate the DTLS packets with m-lines. >> >> Rather than single SCTP over DTLS out as special, this draft could simpl= y say that: >> >> - if the bundle contains *no* m-lines for protocols that utilize DTLS >> payload packets then DTLS payload packets are erroneous. >> >> - if the bundle contains *one* m-line for a protocol that utilizes >> DTLS payload packets then all the payload packets are to be >> associated with it. >> >> - if the bundle contains *more than one* m-line for protocols that >> utilize payload packets then some other specification is needed >> to define how the packets are associated with m-lines. > > Currently we have the following text in the draft: > > "[RFC5764] does not describe how to identify different protocols > transported on DTLS, only how to identify the DTLS protocol itself. > If multiple protocols are transported on DTLS, there MUST exist a > specification describing a mechanism for identify each individual > protocol." > > I guess we could e.g. extend that by saying that the document does not de= scribe how to associated=20 > DTLS data with an m- lines, and that a separate specification is needed t= o define that (basically the third=20 > bullet you suggest). I realized that we have the existing text in section 9.1: "In addition, if a received packet can be associated with more than one bundled "m=3D" line, there MUST exist a publically available specification which describes a mechanism for associating the received packet with the correct "m=3D" line." So, I think that covers the case where you would receive DTLS packets assoc= iated with multiple "m=3D" lines. Regards, Christer From nobody Thu Oct 23 04:56:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D431A8F38 for ; Thu, 23 Oct 2014 04:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lQoBxPvWyEN for ; Thu, 23 Oct 2014 04:56:55 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822CE1A9252 for ; Thu, 23 Oct 2014 04:56:53 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A623259A6B26D for ; Thu, 23 Oct 2014 11:56:49 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9NBuTXG002014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Oct 2014 13:56:51 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 13:56:37 +0200 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" Thread-Topic: draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: Ac/uuCRoxa2wDi0XTrmXWBalhgDJLQ== Date: Thu, 23 Oct 2014 11:56:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cYsjKfM5Nu_srtoFftxxcc0F5Hs Subject: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 11:56:57 -0000 I have just posted an updated version of the MSRP document that gives one m= apping for usage MSRP over draft-ejzak-mmusic-data-channel-sdpneg-01 The group (if any) that should handle this usage document is still as I wen= t back and reread the dispatch minutes in regard to draft-ejzak-mmusic-data= -channel-sdpneg and it is unclear to me whether one or both documents were = dispatched to MMUSIC. I will try and get this clarified offline. In any case, I have submitted it with an MMUSIC label as I think the MMUSIC= folks are the next people who should be looking at it. Regards Keith A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-00.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Name: draft-ejzak-mmusic-msrp-usage-data-channel Revision: 00 Title: MSRP over SCTP/DTLS data channels Document date: 2014-10-23 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp= -usage-data-channel-00.txt Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-us= age-data-channel/ Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-da= ta-channel-00 Abstract: This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the the SDP offer/answer exchange-based external negotiation defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations are documented: a WebRTC end-to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat = From nobody Thu Oct 23 06:17:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880C71A9099 for ; Thu, 23 Oct 2014 06:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfK6jQpLLrkT for ; Thu, 23 Oct 2014 06:17:14 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0CF1A9085 for ; Thu, 23 Oct 2014 06:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4698; q=dns/txt; s=iport; t=1414070233; x=1415279833; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jv6zUpIEE085IqmPqbkhquwF+XjFRYAUrF1FmGrw3+Y=; b=krz0vw3zuwsPwAxzIqMXc9l6CyUgjwhf26Fyk/VwBqIz+/oUQSh8Z6+S aRLRqeEZzsO39+H1drQUBHfGDcWiMrkU7RLhGlLjstw9ekgW/adUVUDkj Cdalx63Wswgbkh9ki1CWx2Gm91wCN6JPTd9kWejSxNvgRTCuSzHS910TF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAB//SFStJV2Y/2dsb2JhbABcgkhGVFzMdAEJhnlUAoERFgF9hAMBAQQBAQFrCxACAQg/BycLFBEBAQQOBYhBDcdtAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQVAQHgy2BHgWSBYtYli2DeGyBSIEDAQEB X-IronPort-AV: E=Sophos; i="5.04,774,1406592000"; d="scan'208,217"; a="89667591" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 23 Oct 2014 13:17:12 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9NDHCIw031643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 13:17:12 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 08:17:12 -0500 From: "Pal Martinsen (palmarti)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric RTP? Thread-Index: Ac/t+TLxySzzhSPRThmnhInx0Sm2EAA9FwCA Date: Thu, 23 Oct 2014 13:17:11 +0000 Message-ID: <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.81.13] Content-Type: multipart/alternative; boundary="_000_0323BE4EBC684848BE90227CF769BE23ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/D_6HXdfBiBrkPZCTID7a5r_9yXA Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 13:17:15 -0000 --_000_0323BE4EBC684848BE90227CF769BE23ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 22 Oct 2014, at 15:08, Christer Holmberg > wrote: Hi, One question, raised as part of Paul=92s WGLC review of BUNDLE, was whether= BUNDLE should mandate usage of symmetric RTP, i.e. using the same address:= port for both sending and receiving RTP. I think that make sense. The report from SIPit31 said that 100% of the endp= oints supported symmetric RTP (https://www.sipit.net/SIPit31_summary) .-. P=E5l-Erik (If ICE is used with BUNDLE, symmetric RTP is obviously required) Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_0323BE4EBC684848BE90227CF769BE23ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <456AE07D2F687E4E9C1ACDA7F228F53A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 22 Oct 2014, at 15:08, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,
 
One question, raised as part of Paul=92s WGLC review of BUNDLE, was whether= BUNDLE should mandate usage of symmetric RTP, i.e. using the same address:= port for both sending and receiving RTP.
 

I think that make sense. The report from SIPit31 said that 100% of the endp= oints supported symmetric RTP

.-.
P=E5l-Erik

(If ICE is used with BUNDLE, symmetric RTP is obviously required)
 
Regards,
 
Christer
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/= listinfo/mmusic

--_000_0323BE4EBC684848BE90227CF769BE23ciscocom_-- From nobody Thu Oct 23 06:22:00 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709A01A90AD for ; Thu, 23 Oct 2014 06:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x7QmhoKVuMK for ; Thu, 23 Oct 2014 06:21:58 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id AF2951A90AC for ; Thu, 23 Oct 2014 06:21:57 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 641CB93C1AF; Thu, 23 Oct 2014 13:21:54 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_F2D22A5F-5108-46C8-B253-DE7ED21D7BAC" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> Date: Thu, 23 Oct 2014 15:21:45 +0200 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> To: "Pal Martinsen (palmarti)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/M7lcwhKWbjc7kGNpg74HqCAKaVM Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 13:21:59 -0000 --Apple-Mail=_F2D22A5F-5108-46C8-B253-DE7ED21D7BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 23 Oct 2014, at 15:17, Pal Martinsen (palmarti) = wrote: >=20 > On 22 Oct 2014, at 15:08, Christer Holmberg = wrote: >=20 >> Hi, >> =20 >> One question, raised as part of Paul=92s WGLC review of BUNDLE, was = whether BUNDLE should mandate usage of symmetric RTP, i.e. using the = same address:port for both sending and receiving RTP. >> =20 >=20 > I think that make sense. The report from SIPit31 said that 100% of the = endpoints supported symmetric RTP > (https://www.sipit.net/SIPit31_summary) >=20 Was said to support... At least one did not during tests. But anyway, I think symmetric RTP is a must in the networks we operate = in. /O= --Apple-Mail=_F2D22A5F-5108-46C8-B253-DE7ED21D7BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 23 Oct 2014, at 15:17, Pal = Martinsen (palmarti) <palmarti@cisco.com> = wrote:


On 22 Oct 2014, at 15:08, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:

Hi,
 
One question, raised as part of Paul=92s WGLC review of BUNDLE, was = whether BUNDLE should mandate usage of symmetric RTP, i.e. using the = same address:port for both sending and receiving RTP.
 

I think that make sense. The report from SIPit31 said that 100% of the = endpoints supported symmetric RTP

Was said to support... At least = one did not during tests.

But anyway, I think = symmetric RTP is a must in the networks we operate = in.

/O
= --Apple-Mail=_F2D22A5F-5108-46C8-B253-DE7ED21D7BAC-- From nobody Thu Oct 23 07:03:26 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4385F1A90E7 for ; Thu, 23 Oct 2014 07:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj0XH8JO9l0S for ; Thu, 23 Oct 2014 07:03:22 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92411A9114 for ; Thu, 23 Oct 2014 07:03:21 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-03v.sys.comcast.net with comcast id 6e2v1p00452QWKC01e3MFQ; Thu, 23 Oct 2014 14:03:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id 6e3L1p00P3Ge9ey01e3LGq; Thu, 23 Oct 2014 14:03:21 +0000 Message-ID: <54490AA8.7030802@alum.mit.edu> Date: Thu, 23 Oct 2014 10:03:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414073001; bh=bSBuIL3OCax56dBdSxZVNPipEN9dDiIoULaIppu+vTY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wg/RQjGmopgidtOx8zFXpHaM8H59vatLww7ihCjKhFxmhYR7WgrAeBIS28gHJOPh1 lku5bb6+c9S1LsJ0mF6TkOHcQy0srb68qw4gooGqVpg3ro1VMpcKr6CkZ2FHVoxb2o 4ZMpa13EIpqkbcna9B+6qbXAgLEUd07d/lJqmyuR5LRogSTjd0OkEqSrwvYDvw73fT FCnZFECvy3iNZAtL9DwfsEP1fh/i17DMU/MbSfQ+jklxKYIf0BqfgH+4QaTvI1jzm4 Y49JNlxJSuD9sZE5+SVlBSnbPXorhzkRvwbPuA7mYStbuHvpEvZ43ix79ssfHPCpec v1boAoPsJkJRw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jqVa9DVSRjjzEBUkup5n6C8oras Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 14:03:23 -0000 On 10/23/14 9:21 AM, Olle E. Johansson wrote: > > On 23 Oct 2014, at 15:17, Pal Martinsen (palmarti) > wrote: > >> >> On 22 Oct 2014, at 15:08, Christer Holmberg >> > > wrote: >> >>> Hi, >>> One question, raised as part of Paul’s WGLC review of BUNDLE, was >>> whether BUNDLE should mandate usage of symmetric RTP, i.e. using the >>> same address:port for both sending and receiving RTP. >> >> I think that make sense. The report from SIPit31 said that 100% of the >> endpoints supported symmetric RTP >> (https://www.sipit.net/SIPit31_summary) >> > Was said to support... At least one did not during tests. > > But anyway, I think symmetric RTP is a must in the networks we operate in. The question isn't whether symmetric RTP is important to you. The question is whether symmetric RTP is necessary for BUNDLE. If there is some belief that symmetric RTP is a practical necessity in all cases, and that support for asymmetric RTP should be deprecated, then ISTM that should be taken under consideration by AVT. Thanks, Paul From nobody Thu Oct 23 07:39:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4081A90F5 for ; Thu, 23 Oct 2014 07:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EvgTYYHyyRu for ; Thu, 23 Oct 2014 07:39:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7A01A899D for ; Thu, 23 Oct 2014 07:39:15 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-d5-54491311b187 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6E.92.04387.11319445; Thu, 23 Oct 2014 16:39:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 16:39:12 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric RTP? Thread-Index: Ac/t+TLxySzzhSPRThmnhInx0Sm2EAA9FwCA//+L8ICAAAueAP//1XQg Date: Thu, 23 Oct 2014 14:39:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> In-Reply-To: <54490AA8.7030802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja6gsGeIwdFtkhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxePlV5oKfnBWnvz1kbWD8xd7FyMkhIWAi sWPHNxYIW0ziwr31bF2MXBxCAkcZJb4uv8gI4SxhlHg0bzdrFyMHB5uAhUT3P22QBhEBX4ln j2+zgYSFBcwkvj/2hgibS2yf+YMRwnaTmHxvNxOIzSKgKtHeuAmsnBeo9cjRSojp1xgldu+Z wwZSwymgI3Fv9kWwekage76fWgNmMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwlSRWbL/E CFGvI7Fg9yc2CFtbYtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLc dCMjvdSizOTi4vw8vbzUkk2MwCg5uOW31Q7Gg88dDzEKcDAq8fAmzPQIEWJNLCuuzD3EKM3B oiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjL4yq66vPsRU02cR5xSjYNglLCJ2 LkLR08aEa1HFPd59LzdeF9Z7ntupqLTD/Ki0cfmXIhFrDSY+9tedeSkOObenMb7fWB/4csGi 6WliVRLRr5Yni0z4taH2WPGmt9+zv/w0KkpbuUV8g+x1NqZ3MXfN1sn0impaFmwr2rB8kitr 0b7lwXsXK7EUZyQaajEXFScCAPxy7q9zAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Qyz1ha6cV9bOIGgzGwMRA3gIoMM Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 14:39:18 -0000 Hi, >>>> One question, raised as part of Paul's WGLC review of BUNDLE, was=20 >>>> whether BUNDLE should mandate usage of symmetric RTP, i.e. using the=20 >>>> same address:port for both sending and receiving RTP. >>> >>> I think that make sense. The report from SIPit31 said that 100% of=20 >>> the endpoints supported symmetric RTP >>> (https://www.sipit.net/SIPit31_summary) >>> >> Was said to support... At least one did not during tests. >> >> But anyway, I think symmetric RTP is a must in the networks we operate i= n. > > The question isn't whether symmetric RTP is important to you. > The question is whether symmetric RTP is necessary for BUNDLE. > > If there is some belief that symmetric RTP is a practical necessity in al= l cases, and that support=20 > for asymmetric RTP should be deprecated, then ISTM that should be taken u= nder consideration by AVT. I think we could mandate symmetric RTP for BUNDLE even if AVT does not depr= ecate it for general use. Symmetric RTP is assumed for a number of network functions, and it seems to= be what most people are using. So, from that perspective, I think we could= mandate symmetric RTP for BUNDLE. Less options means less interoperability= problems :) Regards, Christer From nobody Thu Oct 23 08:26:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0A1AC426 for ; Thu, 23 Oct 2014 08:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajx96HwMZN7e for ; Thu, 23 Oct 2014 08:26:49 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980EA1AC433 for ; Thu, 23 Oct 2014 08:26:44 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-12v.sys.comcast.net with comcast id 6fSb1p0044xDoy801fSkdJ; Thu, 23 Oct 2014 15:26:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id 6fSj1p00D3Ge9ey01fSjE8; Thu, 23 Oct 2014 15:26:44 +0000 Message-ID: <54491E32.80509@alum.mit.edu> Date: Thu, 23 Oct 2014 11:26:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414078004; bh=CRvGnntBaCiFzD0ZdPobfeWgQN8JoV79fI0AapbkcNM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rWB6j4kZM7v2rxcvv+g167HWh/avqq294Mon1wrs+F/8sta2AQLUA7JfKNPF3tWfw TqT3j/eG73q3Hozu4kFrJGHH17kaEJy1ykKFqEdg8zTgov+/Q/vQEVVQt917aIqBzc cErkSJnyPjZMlsTtTjPkp9j5j+TKufej9aThE+rSwGOeM42HSyv5/C0ij8XT1Af/qO 0jNhUxyijr66tSb/miuSq9tTJI0cTrvEWsa0sOKuGBIdMm96LI9gxXqxfjNgWhml30 2xL6i47Km5URsxPfV7ZP8xHqslxYzAyeZSekuJvB7n7mBLKiDQ5IsxhZNxp45us8Lt Z5OL3WoYtoTAQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/6kWu0RvVUWslts-PVEzu4KSnINE Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:26:50 -0000 On 10/23/14 10:39 AM, Christer Holmberg wrote: > Hi, > >>>>> One question, raised as part of Paul's WGLC review of BUNDLE, was >>>>> whether BUNDLE should mandate usage of symmetric RTP, i.e. using the >>>>> same address:port for both sending and receiving RTP. >>>> >>>> I think that make sense. The report from SIPit31 said that 100% of >>>> the endpoints supported symmetric RTP >>>> (https://www.sipit.net/SIPit31_summary) >>>> >>> Was said to support... At least one did not during tests. >>> >>> But anyway, I think symmetric RTP is a must in the networks we operate in. >> >> The question isn't whether symmetric RTP is important to you. >> The question is whether symmetric RTP is necessary for BUNDLE. >> >> If there is some belief that symmetric RTP is a practical necessity in all cases, and that support >> for asymmetric RTP should be deprecated, then ISTM that should be taken under consideration by AVT. > > I think we could mandate symmetric RTP for BUNDLE even if AVT does not deprecate it for general use. > > Symmetric RTP is assumed for a number of network functions, and it seems to be what most people are using. So, from that perspective, I think we could mandate symmetric RTP for BUNDLE. Less options means less interoperability problems :) We *could*, but should we? Doing so is a passive/aggressive way of starting to deprecate non-symmetric RTP - without really discussing the real issue. The scope of this mechanism is potentially much broader than RTCWEB, so such decisions should not be made solely on the needs of RTCWEB. Thanks, Paul From nobody Thu Oct 23 08:33:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6021AC3C6 for ; Thu, 23 Oct 2014 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6NLyY_R2s7V for ; Thu, 23 Oct 2014 08:33:53 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C124C1A8F49 for ; Thu, 23 Oct 2014 08:33:53 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id AFD831EB8478; Thu, 23 Oct 2014 17:33:52 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 17:33:52 +0200 From: "Stach, Thomas" To: 'Christer Holmberg' Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits Thread-Index: Ac/u1r6MPHtnXAm3R8uZQhYrmpbrZA== Date: Thu, 23 Oct 2014 15:33:51 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LYdUwoVePFa3R0l4_RMFglVF5yE Cc: 'mmusic' Subject: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:33:55 -0000 All, I reviewed bundle-12 and think that it is on a good way to becoming technic= ally mature. Nevertheless, I have a few issue that I will address in separate mails. Below are some random editorial nits and clarifying question on some text t= hat was not clear to me. Section 8.2.2. Request offerer BUNDLE address selection I can't parse that caption. Section 8.5.3, 1st para Typo ...it wants to add a bundled "m=3D" line to BUNDLE group, --> ...it wants to add a bundled "m=3D" line to a BUNDLE group, Section 8.5.3, 2nd bullet I could hardly parse this.=20 o Place the SDP 'mid' attribute value associated with the "m=3D" line in the SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE group [Section 8.2.2]. I think it means that the list of identification-tags (mid-values) in the g= roup-attribute from the previous offer needs to be extended with the identi= fication-tag that is carried in the 'mid' attribute of the additional m-lin= e. Correct? Section 9.2, 1st para A typo at the start "If an offer or answerer in offers or answers ..." -> "If an offerer or answerer ..." However, I'd prefer to shorten and change to " If offers or answers include bundled "m=3D" lines that represent these pr= otocols, the offerer=20 and answerer MUST support ..." ^^^ Section 10.1.2 Typo ... in order for a given payload type value to used inside ... -> ... in order for a given payload type value to be used inside ... IANA consideration appear twice=20 14. IANA Considerations 17. IANA Considerations=20 Regards Thomas From nobody Thu Oct 23 08:34:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85FA1A8F49 for ; Thu, 23 Oct 2014 08:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKfwCDbyvlp1 for ; Thu, 23 Oct 2014 08:34:06 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8401B1AC3D7 for ; Thu, 23 Oct 2014 08:34:02 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id C289823F0675; Thu, 23 Oct 2014 17:34:01 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 17:34:01 +0200 From: "Stach, Thomas" To: 'Christer Holmberg' Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology Thread-Index: Ac/u1sSmOrC76dpuRG2RzgUhUCSTWA== Date: Thu, 23 Oct 2014 15:34:00 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E231C3EMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/x1EXzEqjwZy_wROQg_JqtX-enxc Cc: 'mmusic' Subject: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:34:11 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E231C3EMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All Terminology Offerer suggested BUNDLE mid: The first mid value in a given SDP 'group:BUNDLE' attribute mid list in an offer. and Answerer selected BUNDLE mid: The first mid value in a given SDP 'group:BUNDLE' attribute mid list in an answer. These terms are not very intuitive and make the reading the related text qu= ite cumbersome. Since you are talking about the identification-tags from RFC5888 group-attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) mid-attribute =3D "a=3Dmid:" identification-tag may I suggest re-using that terminology and propose using a single, more pr= egnant term for both together with additional explanation? E.g. BUNDLE-tag: The first element in the list of identification-tags of a 'group:' attribute [RFC5888] with BUNDLE semantics. This tag has special significance in that it identifies the m-line that carries the suggested or selected BUNDLE addres= s. The corresponding m-line will carry the same tag in a 'mid' att= ribute. The offerer suggests a BUNDLE tag. The answerer preferably acce= pts the suggested BUNDLE-tag, but could select a different BUNDLE-tag, if necessary. Example: If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo' would be= the BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE address= . If there is appetite for changing that terminology, I understand that it wo= uld cause quite a few other editorial changes in the remainder of the document. In order to not delay progress of the draft, I can only offer to help in an= y editorial effort and would be happy to propose changed text. Regards Thomas --_000_F81CEE99482EFE438DAE2A652361EE121E231C3EMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

 

Terminology

 

   Offerer suggested BUNDLE mid: The first mid v= alue in a given SDP

   'group:BUNDLE' attribute mid list in an offer= .

and

   Answerer selected BUNDLE mid: The first = mid value in a given SDP

   'group:BUNDLE' attribute mid list in an answe= r.

 

These terms are not very intuitive and make the read= ing the related text quite cumbersome.

Since you are talking about the identification-tags = from RFC5888

group-attribute =3D "a=3Dgroup:" semantics *(SP = identification-tag)

mid-attribute   =3D "a=3Dmid:" identification-tag<=
o:p>

may I suggest re-using that terminology and propose = using a single, more pregnant term for both

together with additional explanation?

E.g.

 

BUNDLE-tag: The first element in the list of identificatio= n-tags of

         &nbs= p;  a 'group:' attribute [RFC5888] with BUNDLE semantics.

         &nbs= p;  This tag has special significance in that it identifies

         &nbs= p;  the m-line that carries the suggested or selected BUNDLE addr= ess.

         &nbs= p;  The corresponding m-line will carry the same tag in a 'mid' a= ttribute.

         &nbs= p;  The offerer suggests a BUNDLE tag. The answerer preferably ac= cepts

         &nbs= p;  the suggested BUNDLE-tag, but could select a different

         &nbs= p;  BUNDLE-tag, if necessary.

         &nbs= p;  Example:

         &nbs= p;  If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo' would be th= e

         &nbs= p;  BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE addre= ss.

 

If there is appetite for changing that terminology, = I understand that it would cause quite a few

other editorial changes in the remainder of the docu= ment.

In order to not delay progress of the draft, I can o= nly offer to help in any editorial effort and would be happy to propose cha= nged text.

 

Regards

Thomas

 

 

--_000_F81CEE99482EFE438DAE2A652361EE121E231C3EMCHP04MSXglobal_-- From nobody Thu Oct 23 08:34:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565331AC3C6 for ; Thu, 23 Oct 2014 08:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trKhd6cQUhur for ; Thu, 23 Oct 2014 08:34:33 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CF5AF1AC3A8 for ; Thu, 23 Oct 2014 08:34:32 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 42B511EB86C9; Thu, 23 Oct 2014 17:34:32 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 17:34:31 +0200 From: "Stach, Thomas" To: 'Christer Holmberg' Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS handling Thread-Index: Ac/u1taQOLbO/QrPTb2C6VqW5Nw7Ig== Date: Thu, 23 Oct 2014 15:34:30 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mFBrR8rR0d5ZVCyq_73rr7S4nVg Cc: 'mmusic' Subject: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:34:34 -0000 All, as noted in the draft: The main purpose of the BAS offer is to ensure that intermediaries, that might not support the BUNDLE extension, have correct information regarding the address is going to be used to transport the bundled media. This is the same motivation as for the "ICE updated offer".=20 Consequently, BUNDLE and ICE need to behave in the same way. I don't want to restart the corresponding discussion for BAS again,=20 but I personally prefer, that BAS should be optional, with the offerer indi= cating=20 if it will perform BAS or not. Regards Thomas From nobody Thu Oct 23 08:34:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0221AC3D7 for ; Thu, 23 Oct 2014 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJDZBT0l0A93 for ; Thu, 23 Oct 2014 08:34:47 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E43911AC3A8 for ; Thu, 23 Oct 2014 08:34:46 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 584D023F0671; Thu, 23 Oct 2014 17:34:46 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 17:34:46 +0200 From: "Stach, Thomas" To: 'Christer Holmberg' Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Offerless re-INVITE Thread-Index: Ac/u1t93iu+6XoNYQrS/qpOjh/ehCQ== Date: Thu, 23 Oct 2014 15:34:45 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/anXmaldjTpqNVOeB1pnmIYALdMo Cc: 'mmusic' Subject: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Offerless re-INVITE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:34:51 -0000 All, considered the case where a SIP dialog was established and BUNDLE was succe= ssfully negotiated in the initial offer/answer exchange. If now an offerless re-INVITE arrives at one of the UIAs, how should the tr= iggered offer be created? Like during the initial SDP offer/answer exchange, i.e. in https://tools.ie= tf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-12#section-8.2 ? Or Like in https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotia= tion-12#section-8.5 for modifying a session? I see merits for both: The first would be useful in case of call transfer initiated by a B2BUA bas= ed on 3PCC procedures. The second would be useful to trigger a BAS. Would it be useful to define an indicator that tells the offerer if 1 or 2 = is requested? Regards Thomas From nobody Thu Oct 23 08:34:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013E81AC3A8 for ; Thu, 23 Oct 2014 08:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5EHNaykVPDB for ; Thu, 23 Oct 2014 08:34:50 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0B32B1AC3E5 for ; Thu, 23 Oct 2014 08:34:50 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 72E3023F0671; Thu, 23 Oct 2014 17:34:49 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 17:34:49 +0200 From: "Stach, Thomas" To: 'Christer Holmberg' Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions Thread-Index: Ac/u1uD0Q8E9/mIMRDq8+AIzqzfe/w== Date: Thu, 23 Oct 2014 15:34:48 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/P_BnHulAjwBE4NGC7eOgj2MSE-M Cc: 'mmusic' Subject: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:34:52 -0000 Section 11.2.1 When an offerer or answerer assigns a unique address to a bundled "m=3D" line (excluding bundle-only "m=3D" lines), it MUST also assign unique ICE candidates [RFC5245] to the "m=3D" line. Why does the answerer assign a unique address to a bundled m-line? The m-line either bundled, then it is shared address. Or if the answerer assigns a unique address, the m-line is not bundled. When an offerer or answerer assigns a shared address (i.e. a previously selected BUNDLE address) to one or more bundled "m=3D" line (including bundle-only "m=3D" lines), and when it assigns an address with a zero port value to one or more bundle-only "m=3D" lines, it MUST assign identical ICE candidates (referred to as shared ICE candidates) to each of those "m=3D" lines. What are these identical ICE candidates?=20 Are these the unique ICE candidates from the 1st para? Are these additional candidates that reflect the port zero in that m-line? I.e. are they introduced in order to not create an ICE-mismatch for the bun= dle-only m-lines? Section 11.2.3 When an answerer generates an answer, which contains a BUNDLE group, the answerer MUST assign shared ICE candidates to each bundled "m=3D" line (including "m=3D" lines that were indicated as bundle-only in the associated offer) in the answer. Does this mean that the answerer copies of all candidates into every m-line= of a BUNDLE? If the ICE candidates are shared, wouldn't it be sufficient to include them= only once? An example for all this would certainly worthwhile. The interactions quite complex and seems to require more text, to make what= needs to be done. Regards Thomas From nobody Thu Oct 23 08:52:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537081ACD2D for ; Thu, 23 Oct 2014 08:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OflpwW4XTWrZ for ; Thu, 23 Oct 2014 08:52:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5916A1ACD24 for ; Thu, 23 Oct 2014 08:51:49 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-57-54492413cd74 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.B8.24955.31429445; Thu, 23 Oct 2014 17:51:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 17:51:47 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric RTP? Thread-Index: Ac/t+TLxySzzhSPRThmnhInx0Sm2EAA9FwCA//+L8ICAAAueAP//1XQggABB1wD//9huEA== Date: Thu, 23 Oct 2014 15:51:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> In-Reply-To: <54491E32.80509@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja6wimeIwanL8hZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx40tuwWr+iv4v85kbGBfwdDFyckgImEg0 N15jhLDFJC7cW88GYgsJHGWUmLCktIuRC8hewigxfcIFoCIODjYBC4nuf9ogNSICvhLPHt9m AwkLC5hJfH/sDRE2l9g+8wcjhB0m8efUaxYQm0VAVeLp2ydMIDYvUOv51VNZIMbvYpK4duUK K0iCU0BLYtKd+cwgNiPQPd9PrQFrYBYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+xwphK0ms2H6J EaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LT jYz1Uosyk4uL8/P08lJLNjECY+Tglt+qOxgvv3E8xCjAwajEw5sw0yNEiDWxrLgy9xCjNAeL kjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwSsw3+3qH5YgZW4rLF63Spob9l6Yc Luew+Sta/kZd9NgNwTl3z0j3eTYd52Xzz932xq7k7/PnhvsTTLd13V9llPlg73X1v1Oyfz8M 23FtB/vb+wzmL27tfPRrzQKBbXwKZ72bTx7cyauXcjJti4OzyxqtayZZGYxV61pqZ3idv59+ M1vrYMyq20osxRmJhlrMRcWJADBVLfFyAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/X47QWPprT94Q1P6pz-PyYgAoI3w Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 15:52:23 -0000 Hi, >>>>>> One question, raised as part of Paul's WGLC review of BUNDLE, was=20 >>>>>> whether BUNDLE should mandate usage of symmetric RTP, i.e. using=20 >>>>>> the same address:port for both sending and receiving RTP. >>>>> >>>>> I think that make sense. The report from SIPit31 said that 100% of=20 >>>>> the endpoints supported symmetric RTP >>>>> (https://www.sipit.net/SIPit31_summary) >>>>> >>>> Was said to support... At least one did not during tests. >>>> >>>> But anyway, I think symmetric RTP is a must in the networks we operate= in. >>> >>> The question isn't whether symmetric RTP is important to you. >>> The question is whether symmetric RTP is necessary for BUNDLE. >>> >>> If there is some belief that symmetric RTP is a practical necessity=20 >>> in all cases, and that support for asymmetric RTP should be deprecated,= then ISTM that should be taken under consideration by AVT. >> >> I think we could mandate symmetric RTP for BUNDLE even if AVT does not d= eprecate it for general use. >> >> Symmetric RTP is assumed for a number of network functions, and it=20 >> seems to be what most people are using. So, from that perspective, I=20 >> think we could mandate symmetric RTP for BUNDLE. Less options means=20 >> less interoperability problems :) > > We *could*, but should we? > > Doing so is a passive/aggressive way of starting to deprecate non-symmetr= ic RTP - without really discussing=20 > the real issue. The scope of this mechanism is potentially much broader t= han RTCWEB, so such decisions should=20 > not be made solely on the needs of RTCWEB. For RTCWEB it is not an issue, as the usage of ICE mandates symmetric RTP. My aim has all the time been to define BUNDLE as a generic mechanism, so my= support of symmetric RTP is not because of RTCWEB - it is based on the fac= t that it seems to be what is being deployed. So, I am not religious about it. Regards, Christer From nobody Thu Oct 23 09:11:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7671E1ACD63 for ; Thu, 23 Oct 2014 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCixXoOG5I7y for ; Thu, 23 Oct 2014 09:11:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987501ACD60 for ; Thu, 23 Oct 2014 09:11:06 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-3c-544928980e70 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F4.05.04081.89829445; Thu, 23 Oct 2014 18:11:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 18:11:03 +0200 From: Christer Holmberg To: "Stach, Thomas" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits Thread-Index: Ac/u1r6MPHtnXAm3R8uZQhYrmpbrZAAApkLQ Date: Thu, 23 Oct 2014 16:11:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C4243@ESESSMB209.ericsson.se> References: 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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje4MDc8Qg95VuhZTlz9msTi5cxuz A5PHkiU/mTy29zxmCWCK4rJJSc3JLEst0rdL4MrY1niAveCnQMWi2WfYGxhn83YxcnJICJhI TNw4nwnCFpO4cG89WxcjF4eQwFFGiRd3JjJDOEsYJe503QTKcHCwCVhIdP/TBmkQEdCRmD3z MTuIzSwgJ7Fh8ks2EFtYIEai+9oXNoiaWIlHO9oZIWwjiTmnd4LZLAKqEndP/GQBsXkFfCWu npkDVi8k4CfR96uTFcTmFPCXuHO9CyzOCHTc91NrmCB2iUvcegJztIDEkj3nmSFsUYmXj/+x QthKEmsPb2eBqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sq RtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMD4Objlt8EOxpfPHQ8xCnAwKvHwJsz0CBFiTSwr rsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzrpbx7ZTSP3VJP7dcv fl98oNRaYVeqj6Gr9mxuj+QDNwvX7DI2eSMV+cihfKqMT7wWo8vcf7pJ5r7Pyr+VxSra/0ln 4OUUPaUst44r+GCuac5bnukVS9gP/xJddDe7RfRzUXCb50m5aZNclGOfiNw1irpdascw8+Hy yZ5WammPFlpq5M6+qsRSnJFoqMVcVJwIAJcXbD6AAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SSgFECbff4KD88DZ6ldLNFCM9Yo Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 16:11:08 -0000 Hi Thomas, Thanks for your review! See inline. --------------------- > Section 8.2.2. Request offerer BUNDLE address selection I can't parse tha= t caption. Based on Paul's review, I suggest to change that to "Request the offerer BU= NDLE address". --------------------- > Section 8.5.3, 1st para > > Typo ...it wants to add a bundled "m=3D" line to BUNDLE group, > --> ...it wants to add a bundled "m=3D" line to a BUNDLE group, Fixed. --------------------- >Section 8.5.3, 2nd bullet >I could hardly parse this.=20 > o Place the SDP 'mid' attribute value associated with the "m=3D" line > in the SDP 'group:BUNDLE' attribute mid list associated with the > BUNDLE group [Section 8.2.2]. > I think it means that the list of identification-tags (mid-values) in the= group-attribute from the previous offer=20 > needs to be extended with the identification-tag that is carried in the '= mid' attribute of the additional m-line. Correct? Yes. I guess I could remove "associated with the BUNDLE group []", if it makes i= t more clear. That is the wording used for the initial offer, so... --------------------- > Section 9.2, 1st para > A typo at the start "If an offer or answerer in offers or answers ..." > -> "If an offerer or answerer ..." > However, I'd prefer to shorten and change to " If offers or answers inclu= de bundled "m=3D" lines=20 > that represent these protocols, the offerer and answerer MUST support ..= ." =20 Paul commented on the same sentence, and my suggested modification is: "If an offer or answer includes bundled "m=3D" lines that represent these p= rotocols, the offerer or answerer MUST support..." So, it is almost as you suggested :) --------------------- > Section 10.1.2 > Typo ... in order for a given payload type value to used inside ... > -> ... in order for a given payload type value to be used inside ... Will be fixed. --------------------- > IANA consideration appear twice=20 > 14. IANA Considerations > 17. IANA Considerations=20 17 will be removed. --------------------- Regards, Christer From nobody Thu Oct 23 09:21:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFA51ACD37 for ; Thu, 23 Oct 2014 09:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPm7JmbzoChm for ; Thu, 23 Oct 2014 09:21:10 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6521AD378 for ; Thu, 23 Oct 2014 09:21:09 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-c0-54492af3f3a7 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.CB.24955.3FA29445; Thu, 23 Oct 2014 18:21:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 18:21:07 +0200 From: Christer Holmberg To: "Stach, Thomas" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS handling Thread-Index: Ac/u1taQOLbO/QrPTb2C6VqW5Nw7IgABTnqA Date: Thu, 23 Oct 2014 16:21:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C4262@ESESSMB209.ericsson.se> References: 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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje5nLc8Qgxt7LSymLn/MYnFy5zZm ByaPJUt+Mnls73nMEsAUxWWTkpqTWZZapG+XwJVx49FSpoKfnBX7F39nb2D8xN7FyMEhIWAi 0XiKp4uRE8gUk7hwbz1bFyMXh5DAUUaJi6t6WSCcJYwS077NZgJpYBOwkOj+pw3SICKgIzF7 5mN2EJtZQE5iw+SXbCC2sECUxM51t1ggaqIlHk05ywhhG0mcW/MCrJ5FQFXi+JzzYHFeAV+J jskXWEFsIQE/iQXfPzOCrOIU8Jf48VUQJMwIdNv3U2uYIFaJS9x6Mp8J4mYBiSV7zjND2KIS Lx//Y4WwlSTWHt7OAlGvI7Fg9yc2CFtbYtnC18wQawUlTs58wjKBUWwWkrGzkLTMQtIyC0nL AkaWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBsXNwy2/VHYyX3zgeYhTgYFTi4U2Y6REi xJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY5fbfe57dWtkq +u3e8q1Ckmce8leqFRXfvT3roIulRunXBXazexvrGJmzvE6s3i4ZqHG4pPe9duKjI2sCPFz7 zj5fypcg9P30v9ojtoJNb7RX9pWcnR/wLfad3p2321fPrKoNSzu46BlTprPClvSMS9vuJbHr Lbs+h1Vng/SPQwzPFh+ecXO3uRJLcUaioRZzUXEiADIAhHZ+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/N45Hb9VL-Xwtbc6oU7vz0LCzHWo Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 16:21:11 -0000 Hi, Must-send-BAS played a central part in the agreement to merge the pre-merge= r BUNDLE mechanism with Cullen's mechanism. And, the reason for sending it is the same as for sending the updated ICE o= ffer. Also keep in mind that you can use BUNDLE without ICE, in which case SDP is= the only way (as you don't send STUN requests) to inform the remote endpoi= nt about the selected address. Regards, Christer -----Original Message----- From: Stach, Thomas [mailto:thomas.stach@unify.com]=20 Sent: 23 October 2014 18:35 To: Christer Holmberg Cc: 'mmusic' Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS= handling All, as noted in the draft: The main purpose of the BAS offer is to ensure that intermediaries, that might not support the BUNDLE extension, have correct information regarding the address is going to be used to transport the bundled media. This is the same motivation as for the "ICE updated offer".=20 Consequently, BUNDLE and ICE need to behave in the same way. I don't want to restart the corresponding discussion for BAS again, but I p= ersonally prefer, that BAS should be optional, with the offerer indicating = if it will perform BAS or not. Regards Thomas From nobody Thu Oct 23 09:30:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87621A9124 for ; Thu, 23 Oct 2014 09:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R7Auw5aJrJt for ; Thu, 23 Oct 2014 09:30:48 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6991ACD8B for ; Thu, 23 Oct 2014 09:30:45 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-02v.sys.comcast.net with comcast id 6gWW1p0054ueUHc01gWlTF; Thu, 23 Oct 2014 16:30:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-03v.sys.comcast.net with comcast id 6gWk1p00H3Ge9ey01gWkDL; Thu, 23 Oct 2014 16:30:45 +0000 Message-ID: <54492D34.5030705@alum.mit.edu> Date: Thu, 23 Oct 2014 12:30:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414081845; bh=2Fd9cyYpTGDIuTmKLkFn99OZ2lLCSIAxgmWqLcle7D0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oRW9nMtog6tHoK36R4fYPWR+gFS2vhG336PUym0neb0LmHhUWL2/zlhngmVEPTiWM bOr+81Jw6dwkG2lMolWzy1iBy6nv39+wws9YmIW/TnlB6cEiStSMwnf08ao72WgyrC Zl9J9iWnNvzADKnS4HvksMCb4QOyfeFov0yLq3iXAVZEh9DJ2GbN8igB1KCSpOltu1 n81hAPcJZ/IMVh/XJdMgikasp78kZnSkOL6vg6lkaA2UNyzWW8AEPik6oLW5AyuAPJ oWdfHn1qDdc7nyUjA3B00LhdBAsocWDE/3OukClX3cTvNNj7CDu5vB8pKRX00RYutR Exx0kA+gdhvxw== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/OQmpTozz1L3PkQvJGmdjKICCXlE Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 16:30:49 -0000 IMO this document is important even to those who don't care about MSRP, because it will set a precedent for how to map existing protocols on top of data channels. A few comments: * Section 4.3: Instead of rewriting the transport rule from 4975, why not just extend it? I.e., transport =/ "dc" * Section 5.1.1.1 The following seems overly stringent: The SDP answer shall include the exact same attribute line to indicate acceptance of the data channel instance. This seems to require a byte-by-byte copy. That precludes independently generating an equivalent attribute. ISTM it is sufficient to require the attribute in the answer to meet the same requirements as that in the offer, and to have the same channel number. (And label???) * Section 5.1.5 ... Closing an MSRP session should trigger an SDP negotiation where the SDP attributes for each affected data channel are removed. I don't know how to interpret this - what does the "should" mean? Is it SHOULD, MUST, MAY? What if it isn't done? Which end is responsible for initiating this O/A? Or does this just mean that the SDP should be updated to reflect the closure the next time there is need to do an O/A? Suppose the intent is to close one MSRP session and immediately open a new one. Is it permissible to simply update the SDP to describe the new MSRP session, reusing the channel number, without first doing an O/A to confirm the closure of the old one? * General There are a couple of places that refer to an attribute "within the m line". That isn't quite right. A better way to say that would be "within the media description" or "associated with the m-line". The inclusion of a=sctp-port in the examples throughout is an unnecessary distraction. It isn't necessary because it has a default. (I don't see *any* currently planned uses for webrtc-datachannel where there is need to specify the sctp port.) Thanks, Paul On 10/23/14 7:56 AM, DRAGE, Keith (Keith) wrote: > I have just posted an updated version of the MSRP document that gives one mapping for usage MSRP over draft-ejzak-mmusic-data-channel-sdpneg-01 > > The group (if any) that should handle this usage document is still as I went back and reread the dispatch minutes in regard to draft-ejzak-mmusic-data-channel-sdpneg and it is unclear to me whether one or both documents were dispatched to MMUSIC. I will try and get this clarified offline. > > In any case, I have submitted it with an MMUSIC label as I think the MMUSIC folks are the next people who should be looking at it. > > Regards > > Keith > > > A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-00.txt > has been successfully submitted by Keith Drage and posted to the IETF repository. > > Name: draft-ejzak-mmusic-msrp-usage-data-channel > Revision: 00 > Title: MSRP over SCTP/DTLS data channels > Document date: 2014-10-23 > Group: Individual Submission > Pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-00.txt > Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/ > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-00 > > > Abstract: > This document specifies how the Message Session Relay Protocol (MSRP) > can be instantiated as a data channel sub-protocol, using the the SDP > offer/answer exchange-based external negotiation defined in > [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations > are documented: a WebRTC end-to-end configuration (connecting two > MSRP over data channel endpoints), and a gateway configuration > (connecting an MSRP over data channel endpoint with an MSRP over TCP > endpoint). > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Oct 23 09:32:24 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1F71ACD93 for ; Thu, 23 Oct 2014 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38zS9Kcs7s5n for ; Thu, 23 Oct 2014 09:32:22 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E801ACDAD for ; Thu, 23 Oct 2014 09:31:30 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-84-54492d60833e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.AC.24955.06D29445; Thu, 23 Oct 2014 18:31:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 18:31:27 +0200 From: Christer Holmberg To: "Stach, Thomas" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions Thread-Index: Ac/u1uD0Q8E9/mIMRDq8+AIzqzfe/wABsBFg Date: Thu, 23 Oct 2014 16:31:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C427D@ESESSMB209.ericsson.se> References: 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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjW6CrmeIwa05shZTlz9msTi5cxuz A5PHkiU/mTy29zxmCWCK4rJJSc3JLEst0rdL4Mp4cOoUS8FU/or7axuYGxh/cncxcnJICJhI XLrbxAxhi0lcuLeerYuRi0NI4CijROffc6wQzhJGieczXwJVcXCwCVhIdP/TBmkQEdCRmD3z MTuIzSwgJ7Fh8ks2EFtYIE7iUvsbZoiaeIkPR1exQthGEte/LGYBsVkEVCVeLN4OZvMK+Ep0 3PsNVi8k4Cdx+/xfJpBVnAL+EgfPyoGEGYFu+35qDRPEKnGJW0/mM0HcLCCxZM95qPtFJV4+ /scKYStJrD0MMZ4Z6MwFuz+xQdjaEssWvmaGWCsocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCy rGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjJ6DW36r7mC8/MbxEKMAB6MSD2/CTI8QIdbE suLK3EOM0hwsSuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaKKx/1quSMi3rU3e 3B03Zmjcnx5sI62nuuOT3vHgPlem55yixTnTpZQFJ75V3XtR8/rFE2GLuGc6h882OHLTvynl 2QvOK7/OL/rbqzN1y7IaqbnlPN6GS+5Evjhh21n9du9aTevO+WeOrvKOVazuntz2tmBqSmnv HC6BZxOXJSg1v048Jve6W4mlOCPRUIu5qDgRAIMS65h/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kD8a8PHa7XWnOKZ8og0aK8QHg38 Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 16:32:23 -0000 Hi, > Section 11.2.1 > > When an offerer or answerer assigns a unique address to a bundled > "m=3D" line (excluding bundle-only "m=3D" lines), it MUST also assign > unique ICE candidates [RFC5245] to the "m=3D" line. > > Why does the answerer assign a unique address to a bundled m-line? > The m-line either bundled, then it is shared address. > Or if the answerer assigns a unique address, the m-line is not bundled. Unique addresses must be used in the initial offer, before it is known whet= her the answerer supports BUNDLE. --------------------------------- > When an offerer or answerer assigns a shared address (i.e. a > previously selected BUNDLE address) to one or more bundled "m=3D" line > (including bundle-only "m=3D" lines), and when it assigns an address > with a zero port value to one or more bundle-only "m=3D" lines, it MUST > assign identical ICE candidates (referred to as shared ICE > candidates) to each of those "m=3D" lines. > > What are these identical ICE candidates?=20 The ICE candidate values are identical. > Are these the unique ICE candidates from the 1st para? It is the ICE candidate associated with the m- line that was selected for t= he offerer BUNDLE address. --------------------------------- > Section 11.2.3 > When an answerer generates an answer, which contains a BUNDLE group, > the answerer MUST assign shared ICE candidates to each bundled "m=3D" > line (including "m=3D" lines that were indicated as bundle-only in the > associated offer) in the answer. > > Does this mean that the answerer copies of all candidates into every m-li= ne of a=20 > BUNDLE? > > If the ICE candidates are shared, wouldn't it be sufficient to include th= em only once? I believe this was discussed quite a while ago, and the outcome was that we= should not use assign candidate values in an implicit way. Regards, Christer From nobody Thu Oct 23 09:36:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2E31ACD9B for ; Thu, 23 Oct 2014 09:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8oExaty7lup for ; Thu, 23 Oct 2014 09:36:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8F01ACD91 for ; Thu, 23 Oct 2014 09:36:06 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-bf-54492e75f82c Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6F.FC.24955.57E29445; Thu, 23 Oct 2014 18:36:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 18:36:04 +0200 From: Christer Holmberg To: "Stach, Thomas" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology Thread-Index: Ac/u1sSmOrC76dpuRG2RzgUhUCSTWAACEKxA Date: Thu, 23 Oct 2014 16:36:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C429D@ESESSMB209.ericsson.se> References: 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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4C429DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RrdUzzPE4M8MYYupyx+zWJzcuY3Z gcljyZKfTB7bex6zBDBFcdmkpOZklqUW6dslcGVMfn2MtWBuVsX6vccYGxivxHYxcnJICJhI LFy7lBnCFpO4cG89WxcjF4eQwFFGiX+397KDJIQEljBKzNrv0cXIwcEmYCHR/U8bJCwioCMx e+ZjsBJmATmJDZNfsoHYwgKREv9f3mWCqImSaD3dzA5hG0msfHQNzGYRUJVYc/kMmM0r4Csx +9g8FohVfhKf3s9mBbE5Bfwlrjw5D1bDCHTb91NrmCB2iUvcejKfCeJmAYkle85D3S8q8fLx P1YIW0li7eHtLCAnMwvkS7ScrIFYJShxcuYTlgmMorOQTJqFUDULSRVEiY7Egt2f2CBsbYll C18zw9hnDjxmQhZfwMi+ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMw0g5u+a26g/HyG8dD jAIcjEo8vAkzPUKEWBPLiitzDzFKc7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOjV+FGqzTTmz2u5WpJxpEqCoETGw9su33ZZ+/fuKBkG2nP4yKH9otsMLcSjrDp6uIoUbgc /P3d+/KiB1G3lLp45jXz8Tyd9DGounb9ty/dcqY8jp6z5gUZx7eLTys7wetYXmC05aXpD+Vf 85aUr+Da9MjfbmLyh6lsayrFGs8d1eO522O7q0SJpTgj0VCLuag4EQCBGDJzlQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Cja3dES6hohxUcXIiComtU0EGcg Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 16:36:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4C429DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There has been many long discussions in order to come up with the terminolo= gy. Also, considering the number of editorial re-structures that have already taken p= lace, and the impact this would have on the document, I would suggest to NO= T do the change. But, if you think the existing definitions can be clarified, we can discuss= that. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 23 October 2014 18:34 To: Christer Holmberg Cc: 'mmusic' Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Ter= minology All Terminology Offerer suggested BUNDLE mid: The first mid value in a given SDP 'group:BUNDLE' attribute mid list in an offer. and Answerer selected BUNDLE mid: The first mid value in a given SDP 'group:BUNDLE' attribute mid list in an answer. These terms are not very intuitive and make the reading the related text qu= ite cumbersome. Since you are talking about the identification-tags from RFC5888 group-attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) mid-attribute =3D "a=3Dmid:" identification-tag may I suggest re-using that terminology and propose using a single, more pr= egnant term for both together with additional explanation? E.g. BUNDLE-tag: The first element in the list of identification-tags of a 'group:' attribute [RFC5888] with BUNDLE semantics. This tag has special significance in that it identifies the m-line that carries the suggested or selected BUNDLE addres= s. The corresponding m-line will carry the same tag in a 'mid' att= ribute. The offerer suggests a BUNDLE tag. The answerer preferably acce= pts the suggested BUNDLE-tag, but could select a different BUNDLE-tag, if necessary. Example: If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo' would be= the BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE address= . If there is appetite for changing that terminology, I understand that it wo= uld cause quite a few other editorial changes in the remainder of the document. In order to not delay progress of the draft, I can only offer to help in an= y editorial effort and would be happy to propose changed text. Regards Thomas --_000_7594FB04B1934943A5C02806D1A2204B1D4C429DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There has been many long discussions in order to come up with the term= inology. Also,

considering the number of editorial re-structures that have already ta= ken place, and the impact this would have on the document, I would suggest = to NOT do the change.

 

But, if you think the existing definitions can be clarified, we can di= scuss that.

 

Regards,

 

Christer

 

From: Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: 23 October 2014 18:34
To: Christer Holmberg
Cc: 'mmusic'
Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-1= 2 - Terminology

 

All

 

Terminology

 

   Offerer suggested BUNDLE mid: = The first mid value in a given SDP

   'group:BUNDLE' attribute mid l= ist in an offer.

and

   Answerer selected BUNDLE = mid: The first mid value in a given SDP

   'group:BUNDLE' attribute mid l= ist in an answer.

 

These terms are not very intuit= ive and make the reading the related text quite cumbersome.

Since you are talking about the= identification-tags from RFC5888

group-attribute =3D "a=3Dgroup:" = semantics *(SP identification-tag)

mid-attribute   =3D "a=3Dmid:"=
; identification-tag

may I suggest re-using that ter= minology and propose using a single, more pregnant term for both

together with additional explan= ation?

E.g.

 

BUNDLE-tag: The first element in the list o= f identification-tags of

       &= nbsp;    a 'group:' attribute [RFC5888] with BUNDLE sem= antics.

       &= nbsp;    This tag has special significance in that it i= dentifies

       &= nbsp;    the m-line that carries the suggested or selec= ted BUNDLE address.

       &= nbsp;    The corresponding m-line will carry the same t= ag in a 'mid' attribute.

       &= nbsp;    The offerer suggests a BUNDLE tag. The answere= r preferably accepts

       &= nbsp;    the suggested BUNDLE-tag, but could select a d= ifferent

       &= nbsp;    BUNDLE-tag, if necessary.

       &= nbsp;    Example:

       &= nbsp;    If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'f= oo' would be the

       &= nbsp;    BUNDLE-tag and 'a=3Dmid:foo' the m-line with t= he BUNDLE address.

 

If there is appetite for changi= ng that terminology, I understand that it would cause quite a few

other editorial changes in the = remainder of the document.

In order to not delay progress = of the draft, I can only offer to help in any editorial effort and would be= happy to propose changed text.

 

Regards

Thomas

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D4C429DESESSMB209erics_-- From nobody Thu Oct 23 09:48:58 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D24E1ACD81 for ; Thu, 23 Oct 2014 09:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ-1CZilX40Q for ; Thu, 23 Oct 2014 09:48:55 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58D81A9130 for ; Thu, 23 Oct 2014 09:48:54 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-b6-54493174304c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 03.48.04081.47139445; Thu, 23 Oct 2014 18:48:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 18:48:52 +0200 From: Christer Holmberg To: "Stach, Thomas" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Offerless re-INVITE Thread-Index: Ac/u1t93iu+6XoNYQrS/qpOjh/ehCQACVzNQ Date: Thu, 23 Oct 2014 16:48:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C42C9@ESESSMB209.ericsson.se> References: 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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjW6JoWeIQdsMG4upyx+zWJzcuY3Z gcljyZKfTB7bex6zBDBFcdmkpOZklqUW6dslcGX0fl/MXnCKu+JP533GBsZ9nF2MnBwSAiYS x88tZoewxSQu3FvP1sXIxSEkcJRRYtmaMywQzhJGiZOvTgBlODjYBCwkuv9pgzSICOhIzJ75 GKyZWUBOYsPkl2wgtrBAosSbV39YIWqSJD5smQplG0mcvTORBcRmEVCVuLagkQVkJK+Ar0Tb gwiQsJCAn8T5I2vBRnIK+Eus7fsI1soIdNv3U2uYIFaJS9x6Mp8J4mYBiSV7zjND2KISLx// Y4WwlSTWHt7OAlGvI7Fg9yc2CFtbYtnC12D1vAKCEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEj yypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwOg5uOW3wQ7Gl88dDzEKcDAq8fAmzPQIEWJN LCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOJzXmRfjud4U5R3 UFv2zvueL2GzfynpFZ2uUJopcahr/2f5FC+7f+L37eXLZ+ns5TA8GL8uRXzzvNPpNmt5TC8s 4LGIVO3c0Pjx/u03MpymWYrnjp09dn2bsV3Sn4JU0aWqQVNO7VvcM7E1cZpeIe8lPT9bnqgF jA37l1hUsl5o3GH8N2FfiBJLcUaioRZzUXEiAAZWZK9/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/3tmdxOE-hK-rIVrR-G8mv-R-FsI Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Offerless re-INVITE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 16:48:56 -0000 Hi, My approach has been that an initial offer is an initial offer no matter in= what message it is sent. In the past, there were discussions (and, if I remember correctly, text in = the draft) that one could offer a shared address already in the initial off= er, if the offerer "knows" (using some kind of indicator) that the answerer= supports BUNDLE. But, that was later removed. Regards, Christer -----Original Message----- From: Stach, Thomas [mailto:thomas.stach@unify.com]=20 Sent: 23 October 2014 18:35 To: Christer Holmberg Cc: 'mmusic' Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Off= erless re-INVITE All, considered the case where a SIP dialog was established and BUNDLE was succe= ssfully negotiated in the initial offer/answer exchange. If now an offerless re-INVITE arrives at one of the UIAs, how should the tr= iggered offer be created? Like during the initial SDP offer/answer exchange, i.e. in https://tools.ie= tf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-12#section-8.2 ? Or Like in https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotia= tion-12#section-8.5 for modifying a session? I see merits for both: The first would be useful in case of call transfer initiated by a B2BUA bas= ed on 3PCC procedures. The second would be useful to trigger a BAS. Would it be useful to define an indicator that tells the offerer if 1 or 2 = is requested? Regards Thomas From nobody Thu Oct 23 11:20:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A7A1A87BB for ; Thu, 23 Oct 2014 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so3xIEkcYAsI for ; Thu, 23 Oct 2014 11:20:30 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CBC1A8AC5 for ; Thu, 23 Oct 2014 11:20:30 -0700 (PDT) Received: from [81.187.2.149] (port=33554 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhMzp-000724-JR; Thu, 23 Oct 2014 19:20:26 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> Date: Thu, 23 Oct 2014 19:20:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tm8S3CB3ZhcPgpOzGUftPU7UQ7o Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 18:20:33 -0000 On 23 Oct 2014, at 16:51, Christer Holmberg = wrote: >>>>>>> One question, raised as part of Paul's WGLC review of BUNDLE, = was=20 >>>>>>> whether BUNDLE should mandate usage of symmetric RTP, i.e. using=20= >>>>>>> the same address:port for both sending and receiving RTP. >>>>>>=20 >>>>>> I think that make sense. The report from SIPit31 said that 100% = of=20 >>>>>> the endpoints supported symmetric RTP >>>>>> (https://www.sipit.net/SIPit31_summary) >>>>>>=20 >>>>> Was said to support... At least one did not during tests. >>>>>=20 >>>>> But anyway, I think symmetric RTP is a must in the networks we = operate in. >>>>=20 >>>> The question isn't whether symmetric RTP is important to you. >>>> The question is whether symmetric RTP is necessary for BUNDLE. >>>>=20 >>>> If there is some belief that symmetric RTP is a practical necessity=20= >>>> in all cases, and that support for asymmetric RTP should be = deprecated, then ISTM that should be taken under consideration by AVT. >>>=20 >>> I think we could mandate symmetric RTP for BUNDLE even if AVT does = not deprecate it for general use. >>>=20 >>> Symmetric RTP is assumed for a number of network functions, and it=20= >>> seems to be what most people are using. So, from that perspective, I=20= >>> think we could mandate symmetric RTP for BUNDLE. Less options means=20= >>> less interoperability problems :) >>=20 >> We *could*, but should we? >>=20 >> Doing so is a passive/aggressive way of starting to deprecate = non-symmetric RTP - without really discussing=20 >> the real issue. The scope of this mechanism is potentially much = broader than RTCWEB, so such decisions should=20 >> not be made solely on the needs of RTCWEB. >=20 > For RTCWEB it is not an issue, as the usage of ICE mandates symmetric = RTP. Also, section 4.7 of draft-ietf-rtcweb-rtp-usage says =93implementations = are REQUIRED to implement and use Symmetric RTP=94. > My aim has all the time been to define BUNDLE as a generic mechanism, = so my support of symmetric RTP is not because of RTCWEB - it is based on = the fact that it seems to be what is being deployed. >=20 > So, I am not religious about it. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ From nobody Thu Oct 23 11:30:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788F41A017D for ; Thu, 23 Oct 2014 11:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLq2FGC_M6Cv for ; Thu, 23 Oct 2014 11:30:20 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2A91A8BBE for ; Thu, 23 Oct 2014 11:30:20 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-12v.sys.comcast.net with comcast id 6iVg1p00354zqzk01iWKJU; Thu, 23 Oct 2014 18:30:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id 6iWD1p00M3Ge9ey01iWJa6; Thu, 23 Oct 2014 18:30:19 +0000 Message-ID: <54494934.2020302@alum.mit.edu> Date: Thu, 23 Oct 2014 14:30:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Colin Perkins , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> In-Reply-To: <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414089019; bh=dipe6BSS2DkSN5Xrz8S7uv9CqooepPQHq/wTUVucB7Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pal/1bCLcuJ71Y/VPSogxD9pToykOCf5pmaw5cHP+Tzjn1sFEWvnm0i6x35MFYeg5 YzFNYi++5SDJDdh5U2Ua+Qxo/WL7FSU0WG2Adwcyx/AMoNSaWj1kGxQAGE94jptPyE XKZyGYRli9PKecOafKxVZFkC4owleGiQ2DkjIaDLqQeuhP3rO7FGd10TkbJEtjvW9X Fjc4V6xw1n5FVuj6dwhkM7i8AoFo0hOqddXq92QO8T9ShrXgouqchkpaDhiH07BZ80 ColOU36MWAhRLYGcwVXX2qGRN9dQcSuz1em5r08J+K3M10VXI/jbX4pZWZvooRyjM/ +RKMkknXIGL5A== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/-CKtALyGq3OPRpOzNYLeu6Pioik Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 18:30:21 -0000 Colin, I don't know how to interpret your response. Are you saying that it is ok to mandate symmetric RTP because it is already required for RTCWEB and BUNDLE is *only* for RTCWEB??? If we consider use of BUNDLE in other contexts, what would the reason be to require symmetric RTP? As I said before - if the current wisdom is that RTP should *always* be used in a symmetric fashion, then can we just state that somewhere? Thanks, Paul On 10/23/14 2:20 PM, Colin Perkins wrote: > On 23 Oct 2014, at 16:51, Christer Holmberg wrote: >>>>>>>> One question, raised as part of Paul's WGLC review of BUNDLE, was >>>>>>>> whether BUNDLE should mandate usage of symmetric RTP, i.e. using >>>>>>>> the same address:port for both sending and receiving RTP. >>>>>>> >>>>>>> I think that make sense. The report from SIPit31 said that 100% of >>>>>>> the endpoints supported symmetric RTP >>>>>>> (https://www.sipit.net/SIPit31_summary) >>>>>>> >>>>>> Was said to support... At least one did not during tests. >>>>>> >>>>>> But anyway, I think symmetric RTP is a must in the networks we operate in. >>>>> >>>>> The question isn't whether symmetric RTP is important to you. >>>>> The question is whether symmetric RTP is necessary for BUNDLE. >>>>> >>>>> If there is some belief that symmetric RTP is a practical necessity >>>>> in all cases, and that support for asymmetric RTP should be deprecated, then ISTM that should be taken under consideration by AVT. >>>> >>>> I think we could mandate symmetric RTP for BUNDLE even if AVT does not deprecate it for general use. >>>> >>>> Symmetric RTP is assumed for a number of network functions, and it >>>> seems to be what most people are using. So, from that perspective, I >>>> think we could mandate symmetric RTP for BUNDLE. Less options means >>>> less interoperability problems :) >>> >>> We *could*, but should we? >>> >>> Doing so is a passive/aggressive way of starting to deprecate non-symmetric RTP - without really discussing >>> the real issue. The scope of this mechanism is potentially much broader than RTCWEB, so such decisions should >>> not be made solely on the needs of RTCWEB. >> >> For RTCWEB it is not an issue, as the usage of ICE mandates symmetric RTP. > > Also, section 4.7 of draft-ietf-rtcweb-rtp-usage says “implementations are REQUIRED to implement and use Symmetric RTP”. > >> My aim has all the time been to define BUNDLE as a generic mechanism, so my support of symmetric RTP is not because of RTCWEB - it is based on the fact that it seems to be what is being deployed. >> >> So, I am not religious about it. >> >> Regards, >> >> Christer >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > From nobody Thu Oct 23 11:44:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA471A1A25 for ; Thu, 23 Oct 2014 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnAQFnSoalnn for ; Thu, 23 Oct 2014 11:44:40 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E9F1A19EA for ; Thu, 23 Oct 2014 11:44:40 -0700 (PDT) Received: from [81.187.2.149] (port=41682 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XhNNE-0001CC-Pc; Thu, 23 Oct 2014 19:44:37 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <54494934.2020302@alum.mit.edu> Date: Thu, 23 Oct 2014 19:44:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9D7FB942-5159-4E12-B224-E2F79D6C5745@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> <54494934.2020302@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Cg63nzWgenyWY7QNaYiFg7JaWbY Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 18:44:42 -0000 Paul, On 23 Oct 2014, at 19:30, Paul Kyzivat wrote: > Colin, >=20 > I don't know how to interpret your response. > Are you saying that it is ok to mandate symmetric RTP because it is = already required for RTCWEB and BUNDLE is *only* for RTCWEB??? No, I was merely clarifying that WebRTC requires symmetric RTP, = irrespective of whether ICE is used. I made no comment about what should = go in the BUNDLE draft. > If we consider use of BUNDLE in other contexts, what would the reason = be to require symmetric RTP? Don=92t know - I haven=92t thought about this. > As I said before - if the current wisdom is that RTP should *always* = be used in a symmetric fashion, then can we just state that somewhere? I have no objection to mandating symmetric RTP for some particular = scenarios, but I don=92t think a blanket statement that it MUST be used = is appropriate, since there could be environments where using RTP in a = non-symmetric manner makes sense.=20 Colin > Thanks, > Paul >=20 > On 10/23/14 2:20 PM, Colin Perkins wrote: >> On 23 Oct 2014, at 16:51, Christer Holmberg = wrote: >>>>>>>>> One question, raised as part of Paul's WGLC review of BUNDLE, = was >>>>>>>>> whether BUNDLE should mandate usage of symmetric RTP, i.e. = using >>>>>>>>> the same address:port for both sending and receiving RTP. >>>>>>>>=20 >>>>>>>> I think that make sense. The report from SIPit31 said that 100% = of >>>>>>>> the endpoints supported symmetric RTP >>>>>>>> (https://www.sipit.net/SIPit31_summary) >>>>>>>>=20 >>>>>>> Was said to support... At least one did not during tests. >>>>>>>=20 >>>>>>> But anyway, I think symmetric RTP is a must in the networks we = operate in. >>>>>>=20 >>>>>> The question isn't whether symmetric RTP is important to you. >>>>>> The question is whether symmetric RTP is necessary for BUNDLE. >>>>>>=20 >>>>>> If there is some belief that symmetric RTP is a practical = necessity >>>>>> in all cases, and that support for asymmetric RTP should be = deprecated, then ISTM that should be taken under consideration by AVT. >>>>>=20 >>>>> I think we could mandate symmetric RTP for BUNDLE even if AVT does = not deprecate it for general use. >>>>>=20 >>>>> Symmetric RTP is assumed for a number of network functions, and it >>>>> seems to be what most people are using. So, from that perspective, = I >>>>> think we could mandate symmetric RTP for BUNDLE. Less options = means >>>>> less interoperability problems :) >>>>=20 >>>> We *could*, but should we? >>>>=20 >>>> Doing so is a passive/aggressive way of starting to deprecate = non-symmetric RTP - without really discussing >>>> the real issue. The scope of this mechanism is potentially much = broader than RTCWEB, so such decisions should >>>> not be made solely on the needs of RTCWEB. >>>=20 >>> For RTCWEB it is not an issue, as the usage of ICE mandates = symmetric RTP. >>=20 >> Also, section 4.7 of draft-ietf-rtcweb-rtp-usage says = =93implementations are REQUIRED to implement and use Symmetric RTP=94. >>=20 >>> My aim has all the time been to define BUNDLE as a generic = mechanism, so my support of symmetric RTP is not because of RTCWEB - it = is based on the fact that it seems to be what is being deployed. >>>=20 >>> So, I am not religious about it. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ From nobody Thu Oct 23 11:56:15 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5671ACCE9 for ; Thu, 23 Oct 2014 11:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hhFiH-iucqK for ; Thu, 23 Oct 2014 11:56:10 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066321ACDDE for ; Thu, 23 Oct 2014 11:56:06 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-03v.sys.comcast.net with comcast id 6ivv1p00153iAfU01iw6eC; Thu, 23 Oct 2014 18:56:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-10v.sys.comcast.net with comcast id 6iw51p00H3Ge9ey01iw57k; Thu, 23 Oct 2014 18:56:06 +0000 Message-ID: <54494F45.4080106@alum.mit.edu> Date: Thu, 23 Oct 2014 14:56:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Colin Perkins References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> <54494934.2020302@alum.mit.edu> <9D7FB942-5159-4E12-B224-E2F79D6C5745@csperkins.org> In-Reply-To: <9D7FB942-5159-4E12-B224-E2F79D6C5745@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414090566; bh=h+sSDGDZg3wZO6MpRg9/PHwmSVRf8QYGkcaymvGwEME=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sF8YlzWb3eScXzEEoSgPOAm+nR+0+9EbIClLIhXGeoVPjY3g13SjoFZqVy6fcB2z5 XnPoI67qPRlHSOfVpJ31+wnH0ajXv7UYiiBh0oyG6Y+lhIDOnWjTdfw5c9z7W/qC4B kDiKWyIyqOj4Ymm/t3Ua97YytD7rpeA84ogci5I9eUwM2BtUsdQ2PnGwdoV338RuYS 52t9Kw9aZo4Piq2TUKZ7xtK3h4gaZ4PbUVOFsaM20DBnthXKzUQX6eUJYuKPdylI89 +u9gb7+i5pB43/1gyvVhbtvRJNW8iEnFswSvwblqet1pAgikY5qaBxv6S2MOPH3jb2 D38Z2ZL+hnKEQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eAvnPVgW5vEtnb2S2IPU2zyk2Dw Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 18:56:11 -0000 On 10/23/14 2:44 PM, Colin Perkins wrote: > Paul, > > On 23 Oct 2014, at 19:30, Paul Kyzivat wrote: >> Colin, >> >> I don't know how to interpret your response. >> Are you saying that it is ok to mandate symmetric RTP because it is already required for RTCWEB and BUNDLE is *only* for RTCWEB??? > > No, I was merely clarifying that WebRTC requires symmetric RTP, irrespective of whether ICE is used. I made no comment about what should go in the BUNDLE draft. > >> If we consider use of BUNDLE in other contexts, what would the reason be to require symmetric RTP? > > Don’t know - I haven’t thought about this. > >> As I said before - if the current wisdom is that RTP should *always* be used in a symmetric fashion, then can we just state that somewhere? > > I have no objection to mandating symmetric RTP for some particular scenarios, but I don’t think a blanket statement that it MUST be used is appropriate, since there could be environments where using RTP in a non-symmetric manner makes sense. Well then, ISTM that if there are scenarios where non-symmetric RTP makes sense, then there could well be a reason to use BUNDLE with those scenarios. Thanks, Paul From nobody Thu Oct 23 13:11:50 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69D61ACFCD for ; Thu, 23 Oct 2014 13:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gDsOp_nvqeh for ; Thu, 23 Oct 2014 13:11:44 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92531ACEB6 for ; Thu, 23 Oct 2014 13:11:44 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 638D0A73B8AF2; Thu, 23 Oct 2014 20:11:41 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9NKBhDA019765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 16:11:43 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 16:11:43 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: AQHP7t66dy5ZGL+nPEG/1c9gL4hdCZw+EJjQ Date: Thu, 23 Oct 2014 20:11:42 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> In-Reply-To: <54492D34.5030705@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/46pWipmIjUniB3cwp8YRP6hFbOM Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 20:11:47 -0000 Hi Paul, Thanks much for thorough comments. Please see my inline responses. > IMO this document is important even to those who don't care about MSRP, > because it will set a precedent for how to map existing protocols on top > of data channels. >=20 > A few comments: >=20 > * Section 4.3: >=20 > Instead of rewriting the transport rule from 4975, why not just extend > it? I.e., >=20 > transport =3D/ "dc" =20 Will change it. >=20 > * Section 5.1.1.1 >=20 > The following seems overly stringent: >=20 > The SDP answer shall include the exact same attribute line to > indicate acceptance of the data channel instance. >=20 > This seems to require a byte-by-byte copy. That precludes independently > generating an equivalent attribute. ISTM it is sufficient to require the > attribute in the answer to meet the same requirements as that in the > offer, and to have the same channel number. (And label???) =20 Correct. In theory a simple answer of "a=3Ddcamp:2" is sufficient (especial= ly since we are now going to make "subprotocol" as optional) to indicating=20 acceptance of that particular data channel. However, to make it consistent with rest of the SDP style, we will change=20 the text to indicate subprotocol parameter MUST be included in answer with= =20 an optional label (matching or non-matching). They may appear in any order. We need to remove '"stream=3D" streamidentifier' as it is now integrated wi= th "dcmap:". >=20 > * Section 5.1.5 >=20 > ... Closing an MSRP > session should trigger an SDP negotiation where the SDP attributes > for each affected data channel are removed. >=20 > I don't know how to interpret this - what does the "should" mean? Is it > SHOULD, MUST, MAY? What if it isn't done? Which end is responsible for > initiating this O/A? Or does this just mean that the SDP should be > updated to reflect the closure the next time there is need to do an O/A? This section will be updated to align with http://tools.ietf.org/html/draft= -ejzak-mmusic-data-channel-sdpneg-01#section-5.2.3 Above reference says that if a new SDP offer is used to close a data channe= l then closing of data channel (which triggers SSN reset) can only be sent after SDP offer/answer sequence is completed. However, application may decide to close a data channel, without sending a = new offer, by just informing the local datachannel stack. Also per above reference, a peer, upon getting close notification, SHOULD generate a new offer which = excludes the closed stream. This is to make sure the data channel close is communica= ted end to end (useful in scenarios where middle boxes are involved and only one end may r= eceive the data channel close due to interworking with other transports). Also the above reference needs to be further clarified about this optional = SDP offer to initiate closing of a datachannel. >=20 > Suppose the intent is to close one MSRP session and immediately open a > new one. Is it permissible to simply update the SDP to describe the new > MSRP session, reusing the channel number, without first doing an O/A to > confirm the closure of the old one? The intent is not to reuse a datachannel (same or a different subprotocol)= =20 before close. We will clarify that such a reuse is not supported. The problem with such reuse is, previous datachannel MUST be reset before it is used for new subprotocol, else the data from previous data channel us= e will interfere with the new data channel use. >=20 > * General >=20 > There are a couple of places that refer to an attribute "within the m > line". That isn't quite right. A better way to say that would be "within > the media description" or "associated with the m-line". Will change. > The inclusion of a=3Dsctp-port in the examples throughout is an > unnecessary distraction. It isn't necessary because it has a default. (I > don't see *any* currently planned uses for webrtc-datachannel where > there is need to specify the sctp port.) You are right; I do not see any such non-default use cases either. We will remove a=3Dsctp-port lines. Thanks Raju From nobody Thu Oct 23 13:36:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D291AD359 for ; Thu, 23 Oct 2014 13:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE08orEkQmYE for ; Thu, 23 Oct 2014 13:36:31 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD981AD358 for ; Thu, 23 Oct 2014 13:36:31 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-12v.sys.comcast.net with comcast id 6kb91p00258ss0Y01kcXeh; Thu, 23 Oct 2014 20:36:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id 6kcW1p00C3Ge9ey01kcWAp; Thu, 23 Oct 2014 20:36:31 +0000 Message-ID: <544966CE.2080709@alum.mit.edu> Date: Thu, 23 Oct 2014 16:36:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414096591; bh=9GuPiaOHWX1ZokZIsU0JUo3ccDGfQ4PdFp+pgte7rqw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=t/hJUgM/iaQ8CcIGQ6QmlFvzDYMfK4cuPgtmCxP/Z1ve7qXDIEs71FbW/91YOXjwJ mmhN9dClFfu+78rrAeu/Kcg/k2shlngRp7Qz/p6ISEt64qVZcxT2hzt/fsWf7Qqwos RD15rXmD4wj2flTqt1uhnCjTRXZyAjTMlApMgT+WP75iIoO1rd7v48N4eKhTGuBUkU jKFDYm1NG5aBDWYVtkN72Rb6g7nmlZNeEeUevrz6aeDbnAzzJ83Q5LQ26j+fUThUSk nLicNORVLiIEOPnZvSBSuoXRUVhRwh+OZh1XtFiml3qhqeawloC/1ThvyFcwnBWzdv WBljzbDksB9DA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/hmcsEG1hxDmVOqKXyJbSZz8EXtw Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 20:36:32 -0000 On 10/23/14 4:11 PM, Makaraju, Maridi Raju (Raju) wrote: >> Suppose the intent is to close one MSRP session and immediately open a >> new one. Is it permissible to simply update the SDP to describe the new >> MSRP session, reusing the channel number, without first doing an O/A to >> confirm the closure of the old one? > > The intent is not to reuse a datachannel (same or a different subprotocol) > before close. We will clarify that such a reuse is not supported. > The problem with such reuse is, previous datachannel MUST be reset before > it is used for new subprotocol, else the data from previous data channel use > will interfere with the new data channel use. My question is: Can I just close it in-band (with a reset) and then send an offer for the new usage of the channel? Thanks, Paul From nobody Thu Oct 23 14:23:15 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DB21A86E2 for ; Thu, 23 Oct 2014 14:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIEa4wyPeJQs for ; Thu, 23 Oct 2014 14:23:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54551A03A0 for ; Thu, 23 Oct 2014 14:23:11 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-f2-544971bd8886 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.10.04387.DB179445; Thu, 23 Oct 2014 23:23:09 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.67]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 23:23:09 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "mmusic@ietf.org" Thread-Topic: ICE updated offer summary Thread-Index: AQHP7weKDmlP+3T9ZEG5U+X7wN7OoA== Date: Thu, 23 Oct 2014 21:23:08 +0000 Message-ID: <8C422F01-91C4-433E-862B-67E1B42890D5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0FDD2D517D0FC947A767F67D12DA5895@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje7eQs8Qg3sN+hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtmb75kLPglVHG2azNzA2C/QxcjJISFgInGmoY8ZwhaTuHBv PVsXIxeHkMBRRokfUx4zQziLGSUebfnEBFLFJmAvMXnNR0YQW0RAXeLr3h6wbmEBJYme/1dZ YeLPn3yHsvUkju8A2cDBwSKgKtF/Nw8kzAs05tOvQywgNiPQ4u+n1oCNZxYQl7j1ZD4TxEEC Ekv2nIc6TlTi5eN/rCBjJAQUJZb3y0GU60ncmDqFDcK2lpg9sY8VwtaWWLbwNTPEKkGJkzOf sExgFJmFZMMsJO2zkLTPQtI+C0n7AkbWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBEXFw y2+rHYwHnzseYhTgYFTi4U2Y6REixJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYrYKEjF5lXuZ8sH8p4x/us2Vld+cIFX7MVGR7atLjW84dZfc76Pzribb2 R7e9azpx+bNGxKf3wi4K0xdLdwT/6ezYZNL+89mNPQ8s1YXvi3xos7ZfKGlw/vahptrlF25r LVQy7TLZxCUnxGnUdbVm6zxZwcYTMoHZTg43nkTePzzbaRmPZtAaJZbijERDLeai4kQA0f+2 xmkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/n1qOI7To4LuZRO41WGu4g702TvU Subject: [MMUSIC] ICE updated offer summary X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 21:23:14 -0000 All, To make sure we're on the same page, here's my summary on the ICE updated o= ffer discussion from and since the Toronto meeting, listing arguments for a= nd against doing the updated offer. Please chime in if there are major erro= rs or some relevant point is missing. There are also couple of open questions (see below) for which more input wo= uld be good. Cheers, Ari For doing updated offer ----------------------- * SDP aware intermediaries may need to enforce policies and/or perform conf= iguration for the media path (latching, SDN, etc.): https://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9sdM https://mailarchive.ietf.org/arch/msg/mmusic/IdZykrtyeTBfIt0Hac3uN5nn5DA https://mailarchive.ietf.org/arch/msg/mmusic/nKPIit139XRwOhC6yl-WhcChYLU https://mailarchive.ietf.org/arch/msg/mmusic/mYbRdoeBN35ESVEeZaCCWnYpa_Q and [1] - Information from SDP ICE candidates and STUN messages is not sufficient = (can't be sure which candidate was selected e.g., with aggressive nominatio= n)=20 * Could also help with releasing TURN candidates without need to wait for t= imeout [1] * Helps with error case debugging and diagnostics [1] * OK if answerer can communicate need for updated offer https://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9sdM * With WebRTC, updated offer could be done with the JS application (no need= for API changes) - However, is selected candidate information available for JS apps? https://mailarchive.ietf.org/arch/msg/mmusic/_3DO5QkBbWgMIV_2uJE9wvhxC1M) For not doing updated offer --------------------------- * Some 3PCC scenarios break with updated offer: https://mailarchive.ietf.org/arch/msg/mmusic/mMyN9hzyrGOqIVdCpp1N1OllNSg http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#section= -3.1 * Not needed in scenarios without SDP aware intermediaries=20 * Complicates call flows and implementations [1] * Currently updated offer is not implemented for Chrome and Firefox; not cl= ear if needed in practice [1] * Could we do instead offerless INVITE where updated offer is needed? Is PR= ACK nowadays supported? https://mailarchive.ietf.org/arch/msg/mmusic/lORWBcHNqXPlZqdvE2SDbVdAwc4 https://mailarchive.ietf.org/arch/msg/mmusic/s95L-4VagjrTluojSQyFBkM6Zn0 [1] http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.1yc63e74= pbhi= From nobody Thu Oct 23 14:38:08 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5241A1B37 for ; Thu, 23 Oct 2014 14:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsHtZXP7NpR4 for ; Thu, 23 Oct 2014 14:38:03 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B021A1AD4 for ; Thu, 23 Oct 2014 14:38:02 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-a7-54497538ce5b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3A.E0.04387.83579445; Thu, 23 Oct 2014 23:38:01 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.67]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 23:38:00 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Eric Rescorla , Jonathan Lennox Thread-Topic: Revisit consensus ? [Re: [MMUSIC] ICE updated offer - Back to the initial question] Thread-Index: AQHP7oM7DJC/6A6Aj0+7L4XC22OMYZw+FLoA Date: Thu, 23 Oct 2014 21:38:00 +0000 Message-ID: <959D853E-7890-4A19-8E24-43FEF51B523E@ericsson.com> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D481271@ESESSMB209.ericsson.se> <544893BD.2030706@cisco.com> In-Reply-To: <544893BD.2030706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: <86A63F29CBC9684EA7478C42E87215CC@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM+Jvja5lqWeIwbt+HosVr8+xW7y/oGux f/F5Zoupyx+zWJzcuY3ZgdVjyu+NrB5Llvxk8pj8uI3ZY3vPYxaPtmd32ANYo7hsUlJzMstS i/TtErgynn36zlxwQrVi9elF7A2MZ1S6GDk5JARMJJ6/v8UMYYtJXLi3nq2LkYtDSOAoo8TT V4vYIZzFjBLrl55jAqliE7CVeNK6jxXEFhFwk7ixbi1YB7PAEkaJW7+vgCWEBZIklm7bD1WU LDHh7EoWCNtIYv75XnYQm0VAVeLyyxZGEJtXwF7iatceJohtd5kkpq7/B5Tg4OAU0JQ4PNMC pIYR6Lzvp9aAHcEsIC5x68l8JoizBSSW7DkP9YKoxMvH/1ghbEWJj6/2gY1hBhqzfpc+RKu1 RPebH4wQtqLElO6H7BAnCEqcnPmEZQKj+CwkG2YhdM9C0j0LSfcsJN0LGFlXMYoWpxYX56Yb GemlFmUmFxfn5+nlpZZsYgRG6sEtv612MB587niIUYCDUYmHN2GmR4gQa2JZcWXuIUZpDhYl cd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBMSm15nfF/7e0ks4+7tA4Ya0SxzeNi zBHe8byy/vryxyKsXIn7Lvs5vObed+HD9GO6ewUY93prdPxvM6qVDDaYpKAvUfAv4N/+/uD0 aQJLNrZKT5056fbt28XH2ReePWpdNal40+Oj/m89rv3m9ZmrEigduneW0NKnEwNv9SwpvOez w2jXpcbLSizFGYmGWsxFxYkAwrXqCbUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/7gXwzPYp_iod5C7HDlGKUNtNsgo Cc: Flemming Andreasen , mmusic , Christer Holmberg Subject: Re: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 21:38:05 -0000 RWtyLCBKb25hdGhhbiwgZXQgYWwsDQoNCldlIGFyZSBub3cgZGlzY3Vzc2luZyB0aGUgbmVlZCBm b3IgSUNFIHVwZGF0ZWQgb2ZmZXIgKHNlZSBiZWxvdyBhbmQgdGhlIHJlbGF0ZWQgdGhyZWFkcyBv biB0aGUgTU1VU0lDIGxpc3QpLiBBcyBGbGVtbWluZyBtZW50aW9uZWQgYmVsb3csIHdlIGhhdmUg bm90IHlldCBoZWFyZCBvcGluaW9ucyBmcm9tIGV2ZXJ5b25lIHBhcnRpY2lwYXRpbmcgYXQgdGhl IGRpc2N1c3Npb24gYXQgdGhlIHByZXZpb3VzIG1lZXRpbmcuDQoNCkkgdHJpZWQgdG8gc3VtbWFy aXplIHRoZSBkaXNjdXNzaW9ucyBzbyBmYXIgYWxzbyBoZXJlOg0KaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9tbXVzaWMvbjFxT0k3VG80THVaUk80MVdHdTRnNzAyVHZVDQoN CkNvdWxkIHlvdSBwbGVhc2UgY29tbWVudCB3aXRoIHlvdXIgdmlld3Mgc28gdGhhdCB3ZSBoYXZl IHRoZSBsYXRlc3Qgb3BpbmlvbnMgZnJvbSBhbGwgc2lkZXMuDQoNCg0KVGhhbmtzLA0KQXJpIChh cyBpbmRpdmlkdWFsKQ0KDQpPbiBPY3QgMjMsIDIwMTQsIGF0IDg6MzUgQU0sIEZsZW1taW5nIEFu ZHJlYXNlbiB3cm90ZToNCg0KPiBJbiB0ZXJtcyBvZiBjb25zZW5zdXMgY2FsbCwgd2UgaGFkIHBy ZXR0eSBzdHJvbmcgY29uc2Vuc3VzIGluIHRoZSBtZWV0aW5nIGZvciBvcHRpb24gIzMgKHNlZSB1 bmRlciBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkwL21pbnV0ZXMvbWludXRlcy05 MC1tbXVzaWMjaC4xeWM2M2U3NHBiaGkpLiBUbyByZWNhcCwgdGhlIG9wdGlvbnMgYW5kIGNvbnNl bnN1cyBvdXRjb21lIHdlcmU6DQo+IA0KPiA8cXVvdGU+DQo+IDMgb3B0aW9ucw0KPiAxLiBDdXJy ZW50IDUyNDUgYmVoYXZpb3IgKG9ubHkgaWYgY2hhbmdlIGZyb20gZGVmYXVsdCBjYW5kaWRhdGUp DQo+IDIuIE1VU1QgYWx3YXlzIGRvIHVwZGF0ZWQgTy9BICh3aGV0aGVyIGNoYW5nZSBvciBub3Qp DQo+IDMuICJFa3IncyIgcHJvcG9zYWw6IHlvdSBkbyBpdCBvciBkb27igJl0IGRvIGl0LCBidXQg eW91IGluZGljYXRlIGluIHRoZSBvL2EgaWYgeW914oCZcmUgZ29pbmcgdG8gZG8gaXQuIEJhc2lj YWxseSB3YW50IHRvIGhhdmUgb3B0aW9uIHRvIG5ldmVyIGRvIHRoZSB1cGRhdGVkIE8vQSBleGNo YW5nZSwgd2l0aCBhbiBpbmRpY2F0aW9uIGluIHRoZSBzaWduYWxpbmcgdGhhdCB5b3Ugd2lsbCBu b3QgYmUgZG9pbmcgaXQuIE9mIGNvdXJzZSBjYW4gYWx3YXlzIGluaXRpYXRlIGEgbmV3IE8vQSBl eGNoYW5nZSB3aGVuZXZlciB5b3Ugd2FudCB0by4NCj4gIA0KPiBDb25zZW5zdXMgY2FsbCBieSBj aGFpciAoRmxlbW1pbmcpOg0KPiAwIGZvciBvcHRpb24gMQ0KPiAzIGZvciBvcHRpb24gMg0KPiAx NSBmb3Igb3B0aW9uIDMNCj4gPC9xdW90ZT4NCj4gDQo+IFNpbmNlIHRoZW4sIEFyaSBzdGFydGVk IGEgdGhyZWFkIHRvIGZpbmQgb3V0IGlmIG9wdGlvbiAzIHdhcyBjYXVzaW5nIG1ham9yIHByb2Js ZW1zIGZvciBwZW9wbGUsIGFuZCBpZiBzbywgaWYgdGhlcmUgd2VyZSBhIChiZXR0ZXIgPykgd2F5 IG9mIGFkZHJlc3NpbmcgdGhvc2UuIFRoaXMgaXMgZXNzZW50aWFseSB3aGF0IHRoaXMgd2hvbGUg IklDRSB1cGRhdGVkIG9mZmVyIiB0aHJlYWQgaGFzIGJlZW4gYWJvdXQuIA0KPiANCj4gRnJvbSBh IGNoYWlyIHBvaW50IG9mIHZpZXcsIEkgdGhpbmsgaXQncyBmYWlyIHRvIHNheSB0aGF0IHdlIGhh dmUgaGVhcmQgYWRkaXRpb25hbCBwb2ludHMgb2YgdmlldyBhbmQgcHJvcG9zYWxzIGFzIHBhcnQg b2YgdGhpcyB0aHJlYWQsIGJ1dCB0aGF0IHdlIGFsc28gb25seSBoZWFyZCBmcm9tIGEgc3Vic2V0 IG9mIHRoZSBwZW9wbGUgaW52b2x2ZWQgaW4gdGhlIGRpc2N1c3Npb24gYXQgSUVURiA5MC4gV2hh dCBJIHdvdWxkIHN1Z2dlc3QgaXMgdGhhdCB0aGUgYXV0aG9yIChBcmkpIGFjdGl2ZWx5IGVuZ2Fn ZXMgdGhlIHBlb3BsZSB0aGF0IGV4cHJlc3NlZCBhbiBvcGluaW9uIGF0IElFVEYgOTAgaW4gdGhp cyBkaXNjdXNzaW9uIHRvIGdldCB0aGVpciBwb2ludHMgb2Ygdmlldy4gV2UgY2FuIHRoZW4gZGlz Y3VzcyBhdCBJRVRGIDkxIGFnYWluIGFuZCB0YWtlIGFub3RoZXIgY29uc2Vuc3VzIGNhbGwgYmFz ZWQgb24gYWxsIHRoZSBpbmZvcm1hdGlvbiBhdmFpbGFibGUuIFdlIHdpbGwgbWFrZSBzdXJlIHRv IGFsc28gdGFrZSB0aGF0IGNvbnNlbnN1cyBjYWxsIHRvIHRoZSBtYWlsaW5nIGxpc3Qgc3Vic2Vx dWVudGx5IHRvIGhvcGVmdWxseSBhZ3JlZSBvbiB0aGUgd2F5IGZvcndhcmQgKG9yIGF0IGxlYXN0 IGdldCBleHBsaWNpdCBjb25zZW5zdXMpLiANCj4gDQo+IFRoYW5rcyANCj4gDQo+IC0tIEZsZW1t aW5nIChhcyBNTVVTSUMgY28tY2hhaXIpLiANCj4gDQo+IA0KPiANCj4gDQo+IE9uIDEwLzE3LzE0 LCA3OjA4IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4+IEhpLA0KPj4gDQo+PiBUaGVy ZSB3YXMgYSBjb25zZW5zdXMgY2FsbCBmb3IgMywgc28gdGhlIG1pbnV0ZXMgYXJlIGNvcnJlY3Qu DQo+PiANCj4+IEkgYXBvbG9naXplIGlmIEkgc2hvdWxkIGhhdmUgY2hhbGxlbmdlZCB0aGUgbWlu dXRlcywgcmF0aGVyIHRoYW4gd2FpdGluZyBmb3IgYW4gZXhwbGljaXQgdmVyaWZpY2F0aW9uIGNh bGwgZnJvbSB0aGUgY2hhaXJzLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gDQo+PiBDaHJpc3Rlcg0K Pj4gDQo+PiBTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KPj4gRnJvbTogU3RhY2gsIFRob21h cw0KPj4gU2VudDog4oCOMTcv4oCOMTAv4oCOMjAxNCAxMzo1OA0KPj4gVG86IENocmlzdGVyIEhv bG1iZXJnOyBBcmkgS2Vyw6RuZW47IG1tdXNpYw0KPj4gU3ViamVjdDogUkU6IFtNTVVTSUNdICBJ Q0UgdXBkYXRlZCBvZmZlciAtIEJhY2sgdG8gdGhlIGluaXRpYWwgcXVlc3Rpb24NCj4+IA0KPj4g PiANCj4+ID4gSGksDQo+PiA+IA0KPj4gPiBXaGF0ZXZlciBkZWNpc2lvbnMgYXJlIG1hZGUgYXQg dGhlIG1lZXRpbmdzIG11c3QgKG9yLCBhdCBsZWFzdCB0aGF0IHNlZW0gdG8NCj4+ID4gYmUgZGUg ZmFjdG8gcHJhY3Rpc2UpIGJlIGNvbmZpcm1lZCBvbiB0aGUgbWFpbGluZyBsaXN0LiANCj4+IFlv dSdyZSByaWdodCBJIGFsc28gaGF2ZW4ndCBzZWVuIGFuIGV4cGxpY2l0IGNvbnNlbnN1cyBjYWxs IG9uIHRoZSBsaXN0LiANCj4+IEJ1dCB0aGVyZSBhbHNvIHdhc24ndCBvYmplY3Rpb24gYWdhaW5z dCB0aGUgbWludXRlcyBhbmQgdGhleSBzYXk6DQo+PiAiQ2hhaXIgY2FsbHMgY29uc2Vuc3VzIG9u IG9wdGlvbiAzLiINCj4+IE1heWJlIHRoZSBjaGFpcnMgY2FuIGhlbHAgd2hlcmUgd2UgYXJlIHdy dCB0byBjb25zZW5zdXMgb3Igbm90IGNvbnNlbnN1cy4gDQo+PiANCj4+IA0KPj4gDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbW11c2ljIG1h aWxpbmcgbGlzdA0KPj4gDQo+PiBtbXVzaWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+IA0KDQo= From nobody Thu Oct 23 14:46:25 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98851A1AC6 for ; Thu, 23 Oct 2014 14:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBWwhZXL_Lcw for ; Thu, 23 Oct 2014 14:46:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D891A0262 for ; Thu, 23 Oct 2014 14:46:17 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-01-544977279fa4 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.8E.24955.72779445; Thu, 23 Oct 2014 23:46:16 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.174.1; Thu, 23 Oct 2014 23:46:15 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7C06D1102AE; Fri, 24 Oct 2014 00:46:15 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9636D4E980; Fri, 24 Oct 2014 00:48:32 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3009B4E695; Fri, 24 Oct 2014 00:48:32 +0300 (EEST) Message-ID: <54497730.6070502@ericsson.com> Date: Fri, 24 Oct 2014 00:46:24 +0300 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" , Simon Perreault References: <20141017222826.30724.11722.idtracker@ietfa.amsl.com> <761C04CA-32BA-4BF9-87DE-A8EFED61105C@cisco.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja5GuWeIwbM9XBZTlz9msXh/fSWL xfUroQ7MHlN+b2T1WLLkJ5PHvzlPmQOYo7hsUlJzMstSi/TtErgyZs48yFhwja9i+w/3BsbP 3F2MnBwSAiYSGxrOsEPYYhIX7q1n62Lk4hASOMoosW3rFyYIZwOjxIrFj6CcvYwSDbcOMUI4 6xgllv45BdWzglFi5ZU9TCDDeAW0JVYvmw82mEVAVaJ/+1Q2EJtNwF7i5oTrYHFRgWSJNVsn sUPUC0qcnPmEBcQWEYiR+DdnEVg9s4CMxIyzjWAzhQV0Jbqe3wOrERJ4wSgxsTkOxOYUsJV4 ceobO0S9rcSFOddZIGx5ie1v5zBDPKcmcfXcJmaIXlWJq/9eMU5gFJ2FZPUsJO2zkLQvYGRe xShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYJwe3/FbdwXj5jeMhRgEORiUe3oSZHiFCrIll xZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExVkg9oH1334qnGfeM f+tMqYhv+20gUy6yRLiYXcSOm3NtQX3h659G9yuOX+3STr0S/nP15v7fM2W9Sn9f4C06YhTh cTQ+vr+25I2d2oTZbm89JE6LyCR/mdNYlvJAgP9+iAhfxPvbvwOu7zzy/dc2mRfqDdd333I9 sqNkadPqbO7E9Uyt39yVWIozEg21mIuKEwHzwXfvdAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Byi9T7r1I7KIefx4eYeLSbFoWI4 Cc: mmusic Subject: Re: [MMUSIC] ICE Dual Stack Fairness X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 21:46:20 -0000 On 10/23/14 10:53 AM, Pal Martinsen (palmarti) wrote: > > On 21 Oct 2014, at 16:53, Simon Perreault > wrote: > >> >> On Tue, Oct 21, 2014 at 4:11 AM, Pal Martinsen (palmarti) >> > wrote: >> >> We submitted a new draft that we believe cover the new milestone. >> >> https://tools.ietf.org/html/draft-martinsen-mmusic-ice-dualstack-fairness-00 >> >> >> I just read this for the first time. Forgive me if this has been >> discussed before... As an implementer I would prefer if there was "the >> one true" algorithm that I can go and implement and not have to think. >> Having an example algorithm in an appendix makes me uneasy. If the >> algorithm is not contentious, why not make it normative? >> > > This have been briefly discussed. Some ICE implementations already do > similar tricks to solve this problem. The main purpose of the draft is > to make implementers aware that their might be a problem and hint that > there is a solution they can use. > > That said, I completely agree that the algorithm should be normative. > > The algorithm in the draft already has wording in there to allow for > implementation specific modifications. And should be able to handle any > old ICE implementations without braking anything. > > Anyone with objections regarding making the proposed algorithm normative > in the draft? We discussed this topic at #89 IETF: http://www.ietf.org/proceedings/89/minutes/minutes-89-mmusic#h.caj5s2i38ck0 The algorithm as such is not, to best of my knowledge, contentious, but making it something mandatory to follow was considered a bad idea. As individual, I think one (RFC 2119) MAY/OPTIONAL default algorithm would make sense, but having it as MUST would not be a good idea. Cheers, Ari From nobody Thu Oct 23 15:09:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73B31A1BF9 for ; Thu, 23 Oct 2014 15:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F9otZMDOrFD for ; Thu, 23 Oct 2014 15:09:53 -0700 (PDT) Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4DA1A2130 for ; Thu, 23 Oct 2014 15:09:53 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id z6so808466yhz.40 for ; Thu, 23 Oct 2014 15:09:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=WL5XQ0rUj/bhjKzTP3Tb1SdYahBpZ0efoKY8gsg+2lU=; b=GN2xnRjNshDLdUjHkkGR4ri2FQVf8hmIf8KPYVPS8A8nfJq+pR9BdNSTHXXFMi9iod w7T9CyBBq3OVhYngyoHlhraJ8Vshikcc1AqysL4B4VtiYI9T5z4Sk83QYrX+7sua7556 35G4TFmKzLJRAlxVVpCY/P4dSeAwQOEfvuVEhEStqjOAQr4Y2+N9GTyPkM+i2rViUi3x b0avZJKsPtXqzQzLpir65p6f8y4W+MstgltsRNPNJQcRebAaeSIsOWq7ttL4TiYqSBnL Ot7wBeMBPQ5DPIaNh1yBRTRqRApnc1wwYFP7cZyJKWL8x9ZyhehGsIecFmXIZVxaxNuL PJTQ== X-Gm-Message-State: ALoCoQmJLd22IFGBsaAeJgVKI8wQLsir9vXbh8Rk954xRmPwgjdC5Bq32hRkHsfhvY/lHsMv1z9T X-Received: by 10.170.164.213 with SMTP id g204mr285003ykd.55.1414102190833; Thu, 23 Oct 2014 15:09:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Thu, 23 Oct 2014 15:09:30 -0700 (PDT) In-Reply-To: <9D7FB942-5159-4E12-B224-E2F79D6C5745@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> <54494934.2020302@alum.mit.edu> <9D7FB942-5159-4E12-B224-E2F79D6C5745@csperkins.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 24 Oct 2014 00:09:30 +0200 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_MO4ZhT7efKm50vY-JP-blT4GJ8 Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2014 22:09:55 -0000 2014-10-23 20:44 GMT+02:00 Colin Perkins : > there could be environments where using RTP in a non-symmetric manner mak= es sense. May at least somebody give a real example of that? Just curious. --=20 I=C3=B1aki Baz Castillo From nobody Thu Oct 23 17:42:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF071AD5A0 for ; Thu, 23 Oct 2014 17:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztIVJQC_xmzT for ; Thu, 23 Oct 2014 17:42:32 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B325C1A86E7 for ; Thu, 23 Oct 2014 17:42:32 -0700 (PDT) Received: from ppp118-209-190-136.lns20.mel8.internode.on.net ([118.209.190.136]:56406 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XhSxW-0007Ut-Bz for mmusic@ietf.org; Fri, 24 Oct 2014 11:42:26 +1100 Message-ID: <5449A071.1000204@nteczone.com> Date: Fri, 24 Oct 2014 11:42:25 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> <54494934.2020302@alum.mit.edu> <9D7FB942-5159-4E12-B224-E2F79D6C5745@csperkins.org> <54494F45.4080106@alum.mit.edu> In-Reply-To: <54494F45.4080106@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/eY65yKbOCSKgH5gwZ7xmhNMacxk Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 00:42:34 -0000 Doesn't CLUE reply on non-symmetric RTP (i.e. media streams are described as sendonly)? and given that multiple streams are used also a good candidate to use BUNDLE? Christian On 24/10/2014 5:56 AM, Paul Kyzivat wrote: > On 10/23/14 2:44 PM, Colin Perkins wrote: >> Paul, >> >> On 23 Oct 2014, at 19:30, Paul Kyzivat wrote: >>> Colin, >>> >>> I don't know how to interpret your response. >>> Are you saying that it is ok to mandate symmetric RTP because it is >>> already required for RTCWEB and BUNDLE is *only* for RTCWEB??? >> >> No, I was merely clarifying that WebRTC requires symmetric RTP, >> irrespective of whether ICE is used. I made no comment about what >> should go in the BUNDLE draft. >> >>> If we consider use of BUNDLE in other contexts, what would the >>> reason be to require symmetric RTP? >> >> Don’t know - I haven’t thought about this. >> >>> As I said before - if the current wisdom is that RTP should *always* >>> be used in a symmetric fashion, then can we just state that somewhere? >> >> I have no objection to mandating symmetric RTP for some particular >> scenarios, but I don’t think a blanket statement that it MUST be used >> is appropriate, since there could be environments where using RTP in >> a non-symmetric manner makes sense. > > Well then, ISTM that if there are scenarios where non-symmetric RTP > makes sense, then there could well be a reason to use BUNDLE with > those scenarios. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Oct 23 19:08:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265721AD8ED for ; Thu, 23 Oct 2014 19:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Kd3dg_hgAF5 for ; Thu, 23 Oct 2014 19:08:26 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8A91AD845 for ; Thu, 23 Oct 2014 19:08:26 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-06v.sys.comcast.net with comcast id 6q831p0044ueUHc01q8R4p; Fri, 24 Oct 2014 02:08:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-03v.sys.comcast.net with comcast id 6q8P1p00A3Ge9ey01q8Q00; Fri, 24 Oct 2014 02:08:25 +0000 Message-ID: <5449B497.8050003@alum.mit.edu> Date: Thu, 23 Oct 2014 22:08:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> <54494934.2020302@alum.mit.edu> <9D7FB942-5159-4E12-B224-E2F79D6C5745@csperkins.org> <54494F45.4080106@alum.mit.edu> <5449A071.1000204@nteczone.com> In-Reply-To: <5449A071.1000204@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414116505; bh=H0bI9QB7ilPBiveNO6GwemHuOFUTy/2iQge49icwRxs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M9D6RTvLBmIiwIaV/pEBKG07pFb8hBLa3ZJrsETDaLDAU4hwtKUhvuJMjTrCNi6+G II8PXpH25TGc6FpIsg36L25hlRz0fXf3PNqRw4dcR3yx5TKPxhCyzJXFhegicMItM3 lcAkDhOZKf4ZzeyssgHCVM5ZgaZmbkD58bG+vQ6JH44/JVJVnhtljc5eC1VydtxvlG 0P4qKNSfMg4xHDliYtmdtPFkRJ1HFXbORUaz+MQ7kZ95X1xAfZqMsScnuulzjjMCYq Ofhp4vPRuA+HowpW0xwdyt9/U+F1ANlKgR+fANXpIik79QKE8dXt5MRqcXjswT32VB IyPX/GlofH8xg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/HSOzH_pBN6NdJrPkog_2EOamLnA Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 02:08:29 -0000 On 10/23/14 8:42 PM, Christian Groves wrote: > Doesn't CLUE reply on non-symmetric RTP (i.e. media streams are > described as sendonly)? and given that multiple streams are used also a > good candidate to use BUNDLE? Practically speaking we are talking about 2-party RTP *sessions* here. So for BUNDLE it would be for the whole bundle. And for clue without BUNDLE, two RTP *sessions*, each with one m-line, one sendonly and one recvonly, are independent wrt this discussion. Thanks, Paul > Christian > > On 24/10/2014 5:56 AM, Paul Kyzivat wrote: >> On 10/23/14 2:44 PM, Colin Perkins wrote: >>> Paul, >>> >>> On 23 Oct 2014, at 19:30, Paul Kyzivat wrote: >>>> Colin, >>>> >>>> I don't know how to interpret your response. >>>> Are you saying that it is ok to mandate symmetric RTP because it is >>>> already required for RTCWEB and BUNDLE is *only* for RTCWEB??? >>> >>> No, I was merely clarifying that WebRTC requires symmetric RTP, >>> irrespective of whether ICE is used. I made no comment about what >>> should go in the BUNDLE draft. >>> >>>> If we consider use of BUNDLE in other contexts, what would the >>>> reason be to require symmetric RTP? >>> >>> Don’t know - I haven’t thought about this. >>> >>>> As I said before - if the current wisdom is that RTP should *always* >>>> be used in a symmetric fashion, then can we just state that somewhere? >>> >>> I have no objection to mandating symmetric RTP for some particular >>> scenarios, but I don’t think a blanket statement that it MUST be used >>> is appropriate, since there could be environments where using RTP in >>> a non-symmetric manner makes sense. >> >> Well then, ISTM that if there are scenarios where non-symmetric RTP >> makes sense, then there could well be a reason to use BUNDLE with >> those scenarios. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 nobody Thu Oct 23 20:11:56 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C672C1A87D0 for ; Thu, 23 Oct 2014 20:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q93ow6eD-yky for ; Thu, 23 Oct 2014 20:11:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084081A1AD6 for ; Thu, 23 Oct 2014 20:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3109; q=dns/txt; s=iport; t=1414120312; x=1415329912; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9ZLlYmZ59CrHsKCPSwtav5dpm8H+I4OnI5jDOM5EKVo=; b=IUO5FW7+25VC84V7L7wh3NpHvXSbdHoEOCKivKLo/OEuzTSVSTDMw1xq q/5HyqNOHLEtOEg+RzJG6RBoD83tK86ew4gerVw5FvM3UK2XCyHmAIJOB rqChUHjNV1e3lITc9+z66e3u0tOy4e7byjVjXAn623BQuZv1+kclx66rT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkLANvCSVStJV2a/2dsb2JhbABcDoMAukABAQEBAQEFAXSaPwKBDxYBfYQCAQEBAwE4QAEFCwsOCgkWDwkDAgECAUUGAQwBBwEBiDUIyisBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhiWKADMHhEsBBJ1dh2yOQIM4XCGCegEBAQ X-IronPort-AV: E=Sophos;i="5.04,778,1406592000"; d="scan'208";a="89827549" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 24 Oct 2014 03:11:51 +0000 Received: from [10.86.244.90] ([10.86.244.90]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9O3BnIA026171; Fri, 24 Oct 2014 03:11:50 GMT Message-ID: <5449C375.3080807@cisco.com> Date: Thu, 23 Oct 2014 23:11:49 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Kyzivat , "mmusic-chairs@tools.ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D4AF4E7@ESESSMB209.ericsson.se> <5444805E.8030104@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4B19C3@ESESSMB209.ericsson.se> <54454148.7070407@alum.mit.edu> In-Reply-To: <54454148.7070407@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CC9RtnBmONz9TVr-BMhvuC54a_w Cc: IETF MMUSIC WG , Christer Holmberg Subject: Re: [MMUSIC] SDP Directorate Review: New SDP attribute sections in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 03:11:54 -0000 On 10/20/14, 1:07 PM, Paul Kyzivat wrote: > Chairs: > I don't think this is something the chairs should decide (at least not at this point). It would be good to hear what the WG thinks first (maybe a discussion point for IETF91 if we don't hear further before then. > Do you want to expand the scope of this effort to include O/A and > BUNDLE considerations for the attributes defined in this draft? > > The pro is that this will further set an example for how future > attributes should be defined. > > The con is that this will require reproducing, or moving, information > that is currently defined in other drafts. > I think Christer brings up a really good point on O/A procedures. If we can reference 3264 for the ones covered there, and include some text for the rest, I think that would be ideal. It would be good to hear from others though. In terms of bundle, the mux-attributes already covers RFC 4566 and its attributes and I don't think we want to introduce a dependency on 4566bis for mux-attributes. In other words, those attributes should still be covered in the mux-attributes draft (no change). I do believe we want Bundle procedures included as part of 4566bis in terms of procedures required to register new attributes going forward. Since 4566bis will be replacing 4566, I think it makes sense to have 4566bis include mux-categories for the attributes (the IANA registries will need to be updated to point to 4566bis instead of 4566). As you note, this sets a good precedence for further drafts as well. Makes sense ? Thanks -- Flemming > Thanks, > Paul > > On 10/20/14 3:01 AM, Christer Holmberg wrote: >> Hi Paul, >> >>>> Offer/Answer considerations: >>>> >>>> ======================== >>>> >>>> Normally, when we define new SDP attributes, we are also supposed to >>>> define the associated Offer/Answer procedures (following the rules in >>>> RFC 3264). >>>> >>>> However, the O/A procedures are missing from the attributes defined in >>>> the draft, nor is it anywhere said that they must be defined for new >>>> attributes. >>> >>> Well, a number of them are covered in 3261 and 3264. >> >> Correct. >> >> My issue is more about the fact that that there is no text on >> specifying the O/A procedures for new attributes. Currently we rely >> on the MMUSIC participants/chairs and SDP directorate to make sure >> it's there. >> >> >>>> BUNDLE considerations: >>>> >>>> ==================== >>>> >>>> Should we mandate to indicate which "category" >>>> [draft-ietf-mmusic-sdp-mux-attributes] an attribute is associated >>>> with. >>> >>> I had the impression that the mux draft was going to do that >>> specification for all the > attributes it has considered. >>> But attributes defined in the future will have to cover this. >> >> Correct. >> >> So, again, the issue is more about the guidelines and procedures for >> defining new attributes. >> >> Regards, >> >> Christer >> > > . > From nobody Fri Oct 24 00:26:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB31AD6C7 for ; Fri, 24 Oct 2014 00:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9d5B8WnkWt5 for ; Fri, 24 Oct 2014 00:26:15 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540CC1A19F6 for ; Fri, 24 Oct 2014 00:26:15 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-66-5449ff15599a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C8.2A.21334.51FF9445; Fri, 24 Oct 2014 09:26:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 09:26:12 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: Mandating symmetric RTP? Thread-Index: Ac/t+TLxySzzhSPRThmnhInx0Sm2EAA9FwCA//+L8ICAAAueAP//1XQggABB1wD//9huEIAAWBMAgAACxACAAAQDAIAAAziAgABgxICAABgFgP//hkjw Date: Fri, 24 Oct 2014 07:26:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C5D28@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C1713@ESESSMB209.ericsson.se> <0323BE4E-BC68-4848-BE90-227CF769BE23@cisco.com> <54490AA8.7030802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C408F@ESESSMB209.ericsson.se> <54491E32.80509@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C41F2@ESESSMB209.ericsson.se> <93D764D0-A23E-42B9-9F34-2B188A78D6DD@csperkins.org> <54494934.2020302@alum.mit.edu> <9D7FB942-5159-4E12-B224-E2F79D6C5745@csperkins.org> <54494F45.4080106@alum.mit.edu> <5449A071.1000204@nteczone.com> <5449B497.8050003@alum.mit.edu> In-Reply-To: <5449B497.8050003@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja7of88Qg3dPpS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj3dnTzAVXxSs2bL/D3sC4TLiLkZNDQsBE omfmezYIW0ziwr31QDYXh5DAUUaJ6QevQTlLGCV6/+9n6mLk4GATsJDo/qcN0iAi4Cvx7PFt NpCwsICZxPfH3hBhc4ntM38wgrSKCDQxSuyes40JJMEioCpxZ8tTFhCbF6j32OcuJoj5n1gk VjdsBktwCuhITDm4C6yBEeii76fWgNnMAuISt57MZ4K4VEBiyZ7zzBC2qMTLx/9YIWwlibWH t7NA1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFx brqRsV5qUWZycXF+nl5easkmRmCkHNzyW3cH4+rXjocYBTgYlXh4F2zyDBFiTSwrrsw9xCjN waIkzrvo3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzaJmfSptUG3bSrTr9p8GohQ8WH qoMBf+1W3GaKrZSzzpeqXMm5fM/Bi8mrZ+4xfb5AjuMAt9DlOW6SXx+nWNgsyMqUFp759SjD 1Ocbu8/1c7/Vbnq3jHWvq0DNy0tHI5de0vV6fcOxtlaZI+H4m+BSsQ1L962Xf1e0fZKWgtqW lYIChz01BY8qsRRnJBpqMRcVJwIASBBCB3UCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZfGVPLqQlhIAlvrq0yPK4Di7mus Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 07:26:18 -0000 Hi, Paul is correct. The issue is not about mandating bi-directional media, but= whether we mandate symmetric RTP when we DO have bi-directional media asso= ciated with a bundled m- line. Assuming we would not mandate symmetric RTP, are people ok still mandating = using a single address:port for sending all bundled media? Or, should we al= so allow using separate addresses:ports for sending bundled media? Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 24 October 2014 05:08 To: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE: Mandating symmetric RTP? On 10/23/14 8:42 PM, Christian Groves wrote: > Doesn't CLUE reply on non-symmetric RTP (i.e. media streams are=20 > described as sendonly)? and given that multiple streams are used also=20 > a good candidate to use BUNDLE? Practically speaking we are talking about 2-party RTP *sessions* here.=20 So for BUNDLE it would be for the whole bundle. And for clue without BUNDLE, two RTP *sessions*, each with one m-line, one = sendonly and one recvonly, are independent wrt this discussion. Thanks, Paul > Christian > > On 24/10/2014 5:56 AM, Paul Kyzivat wrote: >> On 10/23/14 2:44 PM, Colin Perkins wrote: >>> Paul, >>> >>> On 23 Oct 2014, at 19:30, Paul Kyzivat wrote: >>>> Colin, >>>> >>>> I don't know how to interpret your response. >>>> Are you saying that it is ok to mandate symmetric RTP because it is=20 >>>> already required for RTCWEB and BUNDLE is *only* for RTCWEB??? >>> >>> No, I was merely clarifying that WebRTC requires symmetric RTP,=20 >>> irrespective of whether ICE is used. I made no comment about what=20 >>> should go in the BUNDLE draft. >>> >>>> If we consider use of BUNDLE in other contexts, what would the=20 >>>> reason be to require symmetric RTP? >>> >>> Don't know - I haven't thought about this. >>> >>>> As I said before - if the current wisdom is that RTP should=20 >>>> *always* be used in a symmetric fashion, then can we just state that s= omewhere? >>> >>> I have no objection to mandating symmetric RTP for some particular=20 >>> scenarios, but I don't think a blanket statement that it MUST be=20 >>> used is appropriate, since there could be environments where using=20 >>> RTP in a non-symmetric manner makes sense. >> >> Well then, ISTM that if there are scenarios where non-symmetric RTP=20 >> makes sense, then there could well be a reason to use BUNDLE with=20 >> those scenarios. >> >> Thanks, >> Paul >> >> _______________________________________________ >> 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 nobody Fri Oct 24 06:41:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63271A00A7 for ; Fri, 24 Oct 2014 06:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odhdo24DlEuE for ; Fri, 24 Oct 2014 06:41:16 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7321A0097 for ; Fri, 24 Oct 2014 06:41:15 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 696201EB8470; Fri, 24 Oct 2014 15:41:14 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 15:41:14 +0200 From: "Hutton, Andrew" To: =?utf-8?B?QXJpIEtlcsOkbmVu?= , Eric Rescorla , Jonathan Lennox Thread-Topic: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] Thread-Index: AQHP7oM7DJC/6A6Aj0+7L4XC22OMYZw+FLoAgAEf17A= Date: Fri, 24 Oct 2014 13:41:13 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E5D3FB7@MCHP04MSX.global-ad.net> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D481271@ESESSMB209.ericsson.se> <544893BD.2030706@cisco.com> <959D853E-7890-4A19-8E24-43FEF51B523E@ericsson.com> In-Reply-To: <959D853E-7890-4A19-8E24-43FEF51B523E@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DTUuZM1R20nmT7fUYbzcrypBogU Cc: Flemming Andreasen , mmusic , Christer Holmberg Subject: Re: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 13:41:18 -0000 SSBwYXJ0aWNpcGF0ZWQgaW4gdGhlIGRpc2N1c3NlZCBkdXJpbmcgSUVURjkwIGFuZCBoYXZlIHJl YWQgdGhyb3VnaCB0aGUgbGF0ZXN0IHRocmVhZC4NCg0KRHVyaW5nIHRoZSBtZWV0aW5nIEkgd2Fz IGluIGZhdm9yIG9mIG9wdGlvbiAzIChFa3IncyBwcm9wb3NhbDogeW91IGRvIGl0IG9yIGRvbuKA mXQgZG8gaXQsIGJ1dCB5b3UgaW5kaWNhdGUgaW4gdGhlIG8vYSBpZiB5b3XigJlyZSBnb2luZyB0 byBkbyBpdCkgYW5kIEkgaGF2ZSBub3Qgc2VlbiBhbnkgbmV3IGFyZ3VtZW50cyBzbyBJIGFtIHN0 aWxsIG9mIHRoZSBzYW1lIG9waW5pb24uDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQoNCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXJpIEtlcsOkbmVuDQo+IFNlbnQ6IDIzIE9j dG9iZXIgMjAxNCAyMjozOA0KPiBUbzogRXJpYyBSZXNjb3JsYTsgSm9uYXRoYW4gTGVubm94DQo+ IENjOiBGbGVtbWluZyBBbmRyZWFzZW47IG1tdXNpYzsgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gU3Vi amVjdDogUmU6IFtNTVVTSUNdIFJldmlzaXQgY29uc2Vuc3VzID8gW1JlOiBJQ0UgdXBkYXRlZCBv ZmZlciAtIEJhY2sNCj4gdG8gdGhlIGluaXRpYWwgcXVlc3Rpb25dDQo+IA0KPiBFa3IsIEpvbmF0 aGFuLCBldCBhbCwNCj4gDQo+IFdlIGFyZSBub3cgZGlzY3Vzc2luZyB0aGUgbmVlZCBmb3IgSUNF IHVwZGF0ZWQgb2ZmZXIgKHNlZSBiZWxvdyBhbmQgdGhlDQo+IHJlbGF0ZWQgdGhyZWFkcyBvbiB0 aGUgTU1VU0lDIGxpc3QpLiBBcyBGbGVtbWluZyBtZW50aW9uZWQgYmVsb3csIHdlDQo+IGhhdmUg bm90IHlldCBoZWFyZCBvcGluaW9ucyBmcm9tIGV2ZXJ5b25lIHBhcnRpY2lwYXRpbmcgYXQgdGhl DQo+IGRpc2N1c3Npb24gYXQgdGhlIHByZXZpb3VzIG1lZXRpbmcuDQo+IA0KPiBJIHRyaWVkIHRv IHN1bW1hcml6ZSB0aGUgZGlzY3Vzc2lvbnMgc28gZmFyIGFsc28gaGVyZToNCj4gaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9tbXVzaWMvbjFxT0k3VG80THVaUk80MVdHdTRn NzAyVHYNCj4gVQ0KPiANCj4gQ291bGQgeW91IHBsZWFzZSBjb21tZW50IHdpdGggeW91ciB2aWV3 cyBzbyB0aGF0IHdlIGhhdmUgdGhlIGxhdGVzdA0KPiBvcGluaW9ucyBmcm9tIGFsbCBzaWRlcy4N Cj4gDQo+IA0KPiBUaGFua3MsDQo+IEFyaSAoYXMgaW5kaXZpZHVhbCkNCj4gDQo+IE9uIE9jdCAy MywgMjAxNCwgYXQgODozNSBBTSwgRmxlbW1pbmcgQW5kcmVhc2VuIHdyb3RlOg0KPiANCj4gPiBJ biB0ZXJtcyBvZiBjb25zZW5zdXMgY2FsbCwgd2UgaGFkIHByZXR0eSBzdHJvbmcgY29uc2Vuc3Vz IGluIHRoZQ0KPiBtZWV0aW5nIGZvciBvcHRpb24gIzMgKHNlZSB1bmRlcg0KPiBodHRwOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzLzkwL21pbnV0ZXMvbWludXRlcy05MC0NCj4gbW11c2ljI2gu MXljNjNlNzRwYmhpKS4gVG8gcmVjYXAsIHRoZSBvcHRpb25zIGFuZCBjb25zZW5zdXMgb3V0Y29t ZQ0KPiB3ZXJlOg0KPiA+DQo+ID4gPHF1b3RlPg0KPiA+IDMgb3B0aW9ucw0KPiA+IDEuIEN1cnJl bnQgNTI0NSBiZWhhdmlvciAob25seSBpZiBjaGFuZ2UgZnJvbSBkZWZhdWx0IGNhbmRpZGF0ZSkN Cj4gPiAyLiBNVVNUIGFsd2F5cyBkbyB1cGRhdGVkIE8vQSAod2hldGhlciBjaGFuZ2Ugb3Igbm90 KQ0KPiA+IDMuICJFa3IncyIgcHJvcG9zYWw6IHlvdSBkbyBpdCBvciBkb27igJl0IGRvIGl0LCBi dXQgeW91IGluZGljYXRlIGluDQo+IHRoZSBvL2EgaWYgeW914oCZcmUgZ29pbmcgdG8gZG8gaXQu IEJhc2ljYWxseSB3YW50IHRvIGhhdmUgb3B0aW9uIHRvDQo+IG5ldmVyIGRvIHRoZSB1cGRhdGVk IE8vQSBleGNoYW5nZSwgd2l0aCBhbiBpbmRpY2F0aW9uIGluIHRoZSBzaWduYWxpbmcNCj4gdGhh dCB5b3Ugd2lsbCBub3QgYmUgZG9pbmcgaXQuIE9mIGNvdXJzZSBjYW4gYWx3YXlzIGluaXRpYXRl IGEgbmV3IE8vQQ0KPiBleGNoYW5nZSB3aGVuZXZlciB5b3Ugd2FudCB0by4NCj4gPg0KPiA+IENv bnNlbnN1cyBjYWxsIGJ5IGNoYWlyIChGbGVtbWluZyk6DQo+ID4gMCBmb3Igb3B0aW9uIDENCj4g PiAzIGZvciBvcHRpb24gMg0KPiA+IDE1IGZvciBvcHRpb24gMw0KPiA+IDwvcXVvdGU+DQo+ID4N Cj4gPiBTaW5jZSB0aGVuLCBBcmkgc3RhcnRlZCBhIHRocmVhZCB0byBmaW5kIG91dCBpZiBvcHRp b24gMyB3YXMgY2F1c2luZw0KPiBtYWpvciBwcm9ibGVtcyBmb3IgcGVvcGxlLCBhbmQgaWYgc28s IGlmIHRoZXJlIHdlcmUgYSAoYmV0dGVyID8pIHdheSBvZg0KPiBhZGRyZXNzaW5nIHRob3NlLiBU aGlzIGlzIGVzc2VudGlhbHkgd2hhdCB0aGlzIHdob2xlICJJQ0UgdXBkYXRlZA0KPiBvZmZlciIg dGhyZWFkIGhhcyBiZWVuIGFib3V0Lg0KPiA+DQo+ID4gRnJvbSBhIGNoYWlyIHBvaW50IG9mIHZp ZXcsIEkgdGhpbmsgaXQncyBmYWlyIHRvIHNheSB0aGF0IHdlIGhhdmUNCj4gaGVhcmQgYWRkaXRp b25hbCBwb2ludHMgb2YgdmlldyBhbmQgcHJvcG9zYWxzIGFzIHBhcnQgb2YgdGhpcyB0aHJlYWQs DQo+IGJ1dCB0aGF0IHdlIGFsc28gb25seSBoZWFyZCBmcm9tIGEgc3Vic2V0IG9mIHRoZSBwZW9w bGUgaW52b2x2ZWQgaW4gdGhlDQo+IGRpc2N1c3Npb24gYXQgSUVURiA5MC4gV2hhdCBJIHdvdWxk IHN1Z2dlc3QgaXMgdGhhdCB0aGUgYXV0aG9yIChBcmkpDQo+IGFjdGl2ZWx5IGVuZ2FnZXMgdGhl IHBlb3BsZSB0aGF0IGV4cHJlc3NlZCBhbiBvcGluaW9uIGF0IElFVEYgOTAgaW4NCj4gdGhpcyBk aXNjdXNzaW9uIHRvIGdldCB0aGVpciBwb2ludHMgb2Ygdmlldy4gV2UgY2FuIHRoZW4gZGlzY3Vz cyBhdA0KPiBJRVRGIDkxIGFnYWluIGFuZCB0YWtlIGFub3RoZXIgY29uc2Vuc3VzIGNhbGwgYmFz ZWQgb24gYWxsIHRoZQ0KPiBpbmZvcm1hdGlvbiBhdmFpbGFibGUuIFdlIHdpbGwgbWFrZSBzdXJl IHRvIGFsc28gdGFrZSB0aGF0IGNvbnNlbnN1cw0KPiBjYWxsIHRvIHRoZSBtYWlsaW5nIGxpc3Qg c3Vic2VxdWVudGx5IHRvIGhvcGVmdWxseSBhZ3JlZSBvbiB0aGUgd2F5DQo+IGZvcndhcmQgKG9y IGF0IGxlYXN0IGdldCBleHBsaWNpdCBjb25zZW5zdXMpLg0KPiA+DQo+ID4gVGhhbmtzDQo+ID4N Cj4gPiAtLSBGbGVtbWluZyAoYXMgTU1VU0lDIGNvLWNoYWlyKS4NCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+IE9uIDEwLzE3LzE0LCA3OjA4IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4g Pj4gSGksDQo+ID4+DQo+ID4+IFRoZXJlIHdhcyBhIGNvbnNlbnN1cyBjYWxsIGZvciAzLCBzbyB0 aGUgbWludXRlcyBhcmUgY29ycmVjdC4NCj4gPj4NCj4gPj4gSSBhcG9sb2dpemUgaWYgSSBzaG91 bGQgaGF2ZSBjaGFsbGVuZ2VkIHRoZSBtaW51dGVzLCByYXRoZXIgdGhhbg0KPiB3YWl0aW5nIGZv ciBhbiBleHBsaWNpdCB2ZXJpZmljYXRpb24gY2FsbCBmcm9tIHRoZSBjaGFpcnMuDQo+ID4+DQo+ ID4+IFJlZ2FyZHMsDQo+ID4+DQo+ID4+IENocmlzdGVyDQo+ID4+DQo+ID4+IFNlbnQgZnJvbSBt eSBXaW5kb3dzIFBob25lDQo+ID4+IEZyb206IFN0YWNoLCBUaG9tYXMNCj4gPj4gU2VudDog4oCO MTcv4oCOMTAv4oCOMjAxNCAxMzo1OA0KPiA+PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IEFyaSBL ZXLDpG5lbjsgbW11c2ljDQo+ID4+IFN1YmplY3Q6IFJFOiBbTU1VU0lDXSAgSUNFIHVwZGF0ZWQg b2ZmZXIgLSBCYWNrIHRvIHRoZSBpbml0aWFsDQo+IHF1ZXN0aW9uDQo+ID4+DQo+ID4+ID4NCj4g Pj4gPiBIaSwNCj4gPj4gPg0KPiA+PiA+IFdoYXRldmVyIGRlY2lzaW9ucyBhcmUgbWFkZSBhdCB0 aGUgbWVldGluZ3MgbXVzdCAob3IsIGF0IGxlYXN0DQo+IHRoYXQgc2VlbSB0bw0KPiA+PiA+IGJl IGRlIGZhY3RvIHByYWN0aXNlKSBiZSBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdC4NCj4g Pj4gWW91J3JlIHJpZ2h0IEkgYWxzbyBoYXZlbid0IHNlZW4gYW4gZXhwbGljaXQgY29uc2Vuc3Vz IGNhbGwgb24gdGhlDQo+IGxpc3QuDQo+ID4+IEJ1dCB0aGVyZSBhbHNvIHdhc24ndCBvYmplY3Rp b24gYWdhaW5zdCB0aGUgbWludXRlcyBhbmQgdGhleSBzYXk6DQo+ID4+ICJDaGFpciBjYWxscyBj b25zZW5zdXMgb24gb3B0aW9uIDMuIg0KPiA+PiBNYXliZSB0aGUgY2hhaXJzIGNhbiBoZWxwIHdo ZXJlIHdlIGFyZSB3cnQgdG8gY29uc2Vuc3VzIG9yIG5vdA0KPiBjb25zZW5zdXMuDQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gPj4NCj4gPj4gbW11c2ljQGlldGYu b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+ ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gbW11c2ljQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo= From nobody Fri Oct 24 06:44:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1233A1A0065 for ; Fri, 24 Oct 2014 06:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgOf8-RqVKVu for ; Fri, 24 Oct 2014 06:44:06 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 33F161A0054 for ; Fri, 24 Oct 2014 06:44:06 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 9C2311EB8594; Fri, 24 Oct 2014 15:44:05 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 15:44:05 +0200 From: "Stach, Thomas" To: Christer Holmberg Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions Thread-Index: AQHP75CTvBFIIQRDbESCu6Pn9ArNiw== Date: Fri, 24 Oct 2014 13:44:04 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C427D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C427D@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mkZhNakOIvjpu8tRFzpG8u5W_Nk Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 13:44:08 -0000 Christer, > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Donnerstag, 23. Oktober 2014 18:31 > To: Stach, Thomas > Cc: 'mmusic' > Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12= - > ICE Interactions >=20 > Hi, >=20 > > Section 11.2.1 > > > > When an offerer or answerer assigns a unique address to a bundled > > "m=3D" line (excluding bundle-only "m=3D" lines), it MUST also assign > > unique ICE candidates [RFC5245] to the "m=3D" line. > > > > Why does the answerer assign a unique address to a bundled m-line? > > The m-line either bundled, then it is shared address. > > Or if the answerer assigns a unique address, the m-line is not bundled. >=20 > Unique addresses must be used in the initial offer, before it is known wh= ether > the answerer supports BUNDLE. [TS] Certainly true for the offer, but I asked about the answer. Here is my reasoning with corrected grammar: The m-line is either bundled, then a shared address was assigned by the ans= werer. Or if the answerer assigned a unique address, then the m-line is not bundle= d. >=20 > --------------------------------- >=20 > > When an offerer or answerer assigns a shared address (i.e. a > > previously selected BUNDLE address) to one or more bundled "m=3D" lin= e > > (including bundle-only "m=3D" lines), and when it assigns an address > > with a zero port value to one or more bundle-only "m=3D" lines, it MU= ST > > assign identical ICE candidates (referred to as shared ICE > > candidates) to each of those "m=3D" lines. > > > > What are these identical ICE candidates? >=20 > The ICE candidate values are identical. >=20 > > Are these the unique ICE candidates from the 1st para? >=20 > It is the ICE candidate associated with the m- line that was selected for= the > offerer BUNDLE address. [TS] Then the candidates for all m-lines in the BUNDLE are identical to the= se.=20 But what happens due to the bundle-only m-lines that carry port zero? You will not have a default candidate that matches port zero in the m-line. Wouldn't this result in an ICE-mismatch for all these m-lines if you follow= the RFC5245 rules blindly? I see various ways how this could be addressed:=20 by stating an exemption from the 5245 rules for bundle-only m-linesor=20 adding an additional candidate with port 0 to bundle-only m-lines or=20 just omitting the candidates complete from a bundle-only m-line. In the latter case, a non-BUNDLE answerer would ignore that m-line in the o= ffer anyhow=20 and an answerer in support of BUNDLE would know how to deal with it (based = on some text that we would still need to provide). >=20 > --------------------------------- >=20 > > Section 11.2.3 > > When an answerer generates an answer, which contains a BUNDLE group, > > the answerer MUST assign shared ICE candidates to each bundled "m=3D" > > line (including "m=3D" lines that were indicated as bundle-only in th= e > > associated offer) in the answer. > > > > Does this mean that the answerer copies of all candidates into every m-= line > of a > > BUNDLE? > > > > If the ICE candidates are shared, wouldn't it be sufficient to include = them > only once? >=20 > I believe this was discussed quite a while ago, and the outcome was that = we > should not use assign candidate values in an implicit way. [TS] I'll look it up. It might be good to include the reasons in the text t= o avoid repeated questions. Regards Thomas >=20 > Regards, >=20 > Christer From nobody Fri Oct 24 06:44:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857A1A00B2 for ; Fri, 24 Oct 2014 06:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4Y5p37aMEj5 for ; Fri, 24 Oct 2014 06:44:12 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 494E91A00B0 for ; Fri, 24 Oct 2014 06:44:12 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id B154B1EB843F; Fri, 24 Oct 2014 15:44:11 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 15:44:11 +0200 From: "Stach, Thomas" To: Christer Holmberg Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS handling Thread-Index: AQHP75CXM1ocQz3ZQUOxH3uVAx+DHw== Date: Fri, 24 Oct 2014 13:44:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C4262@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C4262@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ckcAMLDe4QgEqPMjQTwRnRivT7g Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 13:44:13 -0000 Christer, > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Donnerstag, 23. Oktober 2014 18:21 > To: Stach, Thomas > Cc: 'mmusic' > Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12= - > BAS handling >=20 > Hi, >=20 > Must-send-BAS played a central part in the agreement to merge the pre-mer= ger > BUNDLE mechanism with Cullen's mechanism. >=20 > And, the reason for sending it is the same as for sending the updated ICE > offer. [TS] And for that exact reason it needs to treated in the same way.=20 But let's wait for the outcome of that other discussion on the ICE updated = offer >=20 > Also keep in mind that you can use BUNDLE without ICE, in which case SDP = is > the only way (as you don't send STUN requests) to inform the remote endpo= int > about the selected address. [TS] Who is the remote endpoint? Offerer and Answerer certainly know the selected addresses from the SDP ans= wer. Regards Thomas >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@unify.com] > Sent: 23 October 2014 18:35 > To: Christer Holmberg > Cc: 'mmusic' > Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - B= AS > handling >=20 > All, >=20 > as noted in the draft: > The main purpose of the BAS offer is to ensure that > intermediaries, that might not support the BUNDLE extension, have > correct information regarding the address is going to be used to > transport the bundled media. > This is the same motivation as for the "ICE updated offer". >=20 > Consequently, BUNDLE and ICE need to behave in the same way. > I don't want to restart the corresponding discussion for BAS again, but I > personally prefer, that BAS should be optional, with the offerer indicati= ng if > it will perform BAS or not. >=20 > Regards > Thomas From nobody Fri Oct 24 06:45:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F371A0065 for ; Fri, 24 Oct 2014 06:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3kWB66moBnB for ; Fri, 24 Oct 2014 06:45:19 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4731A0054 for ; Fri, 24 Oct 2014 06:45:18 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 9790523F06BC; Fri, 24 Oct 2014 15:45:17 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 15:45:17 +0200 From: "Stach, Thomas" To: Christer Holmberg Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology Thread-Index: AQHP75C+xP9ueOyQhU+z/AR0yQ5D5A== Date: Fri, 24 Oct 2014 13:45:16 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C429D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C429D@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E23248AMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XVMs5c0bNnLjDThitBnlcW7vv_s Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 13:45:22 -0000 --_000_F81CEE99482EFE438DAE2A652361EE121E23248AMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There has been many long discussions in order to come up with the terminolo= gy. [TS] I know that much effort was already put into that. Also, considering the number of editorial re-structures that have already taken p= lace, and the impact this would have on the document, I would suggest to NO= T do the change. [TS] I understand that there is not much appetite for putting more editoria= l work into the document. Nevertheless, I still think that understanding the text is still unnecessar= ily cumbersome, which in turn could lead to unnecessary misinterpretations during implement= ation. But maybe it is just me, who has this problem, in which case I probably jus= t have to improve my reading skills. ;-) But, if you think the existing definitions can be clarified, we can discuss= that. [TS] Well, considering reuse of the RFC5888 terminology might be still wort= hwhile. That would e.g. include replacing "mid attribute value" with "identificati= on-tag", etc. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 23 October 2014 18:34 To: Christer Holmberg Cc: 'mmusic' Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Ter= minology All Terminology Offerer suggested BUNDLE mid: The first mid value in a given SDP 'group:BUNDLE' attribute mid list in an offer. and Answerer selected BUNDLE mid: The first mid value in a given SDP 'group:BUNDLE' attribute mid list in an answer. These terms are not very intuitive and make the reading the related text qu= ite cumbersome. Since you are talking about the identification-tags from RFC5888 group-attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) mid-attribute =3D "a=3Dmid:" identification-tag may I suggest re-using that terminology and propose using a single, more pr= egnant term for both together with additional explanation? E.g. BUNDLE-tag: The first element in the list of identification-tags of a 'group:' attribute [RFC5888] with BUNDLE semantics. This tag has special significance in that it identifies the m-line that carries the suggested or selected BUNDLE addres= s. The corresponding m-line will carry the same tag in a 'mid' att= ribute. The offerer suggests a BUNDLE tag. The answerer preferably acce= pts the suggested BUNDLE-tag, but could select a different BUNDLE-tag, if necessary. Example: If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo' would be= the BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE address= . If there is appetite for changing that terminology, I understand that it wo= uld cause quite a few other editorial changes in the remainder of the document. In order to not delay progress of the draft, I can only offer to help in an= y editorial effort and would be happy to propose changed text. Regards Thomas --_000_F81CEE99482EFE438DAE2A652361EE121E23248AMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

&n= bsp;

There h= as been many long discussions in order to come up with the terminology.

[= TS] I know that much effort was already put into that.

<= o:p> 

Also, <= o:p>

conside= ring the number of editorial re-structures that have already taken place, a= nd the impact this would have on the document, I would suggest to NOT do th= e change.

[= TS] I understand that there is not much appetite for putting more editorial= work into the document.

N= evertheless, I still think that understanding the text is still unnecessari= ly cumbersome,  

w= hich in turn could lead to unnecessary misinterpretations during implementa= tion.

B= ut maybe it is just me, who has this problem, in which case I probably just= have to  improve my reading skills.  ;-)

But, if= you think the existing definitions can be clarified, we can discuss that.<= o:p>

[= TS] Well, considering reuse of the RFC5888 terminology might be still worth= while.

T= hat would e.g. include replacing  “mid attribute value” wi= th “identification-tag”, etc.

<= o:p> 

Regards= ,

&n= bsp;

Christe= r

 

From: Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: 23 October 2014 18:34
To: Christer Holmberg
Cc: 'mmusic'
Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-1= 2 - Terminology

 

All

 

Terminology

 

   Offerer suggested BUNDLE mid: The first mid v= alue in a given SDP

   'group:BUNDLE' attribute mid list in an offer= .

and

   Answerer selected BUNDLE mid: The first = mid value in a given SDP

   'group:BUNDLE' attribute mid list in an answe= r.

 

These terms are not very intuitive and make the read= ing the related text quite cumbersome.

Since you are talking about the identification-tags = from RFC5888

group-attribute =3D "a=3Dgroup:" semantics *(SP = identification-tag)

mid-attribute   =3D "a=3Dmid:" identification-tag<=
o:p>

may I suggest re-using that terminology and propose = using a single, more pregnant term for both

together with additional explanation?

E.g.

 

BUNDLE-tag: The first element in the list of identificatio= n-tags of

         &nbs= p;  a 'group:' attribute [RFC5888] with BUNDLE semantics.

         &nbs= p;  This tag has special significance in that it identifies

         &nbs= p;  the m-line that carries the suggested or selected BUNDLE addr= ess.

         &nbs= p;  The corresponding m-line will carry the same tag in a 'mid' a= ttribute.

         &nbs= p;  The offerer suggests a BUNDLE tag. The answerer preferably ac= cepts

         &nbs= p;  the suggested BUNDLE-tag, but could select a different

         &nbs= p;  BUNDLE-tag, if necessary.

         &nbs= p;  Example:

         &nbs= p;  If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo' would be th= e

         &nbs= p;  BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE addre= ss.

 

If there is appetite for changing that terminology, = I understand that it would cause quite a few

other editorial changes in the remainder of the docu= ment.

In order to not delay progress of the draft, I can o= nly offer to help in any editorial effort and would be happy to propose cha= nged text.

 

Regards

Thomas

 

 

--_000_F81CEE99482EFE438DAE2A652361EE121E23248AMCHP04MSXglobal_-- From nobody Fri Oct 24 06:45:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2E51A0065 for ; Fri, 24 Oct 2014 06:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVnVHOeabqjZ for ; Fri, 24 Oct 2014 06:45:33 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 609B01A0054 for ; Fri, 24 Oct 2014 06:45:33 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id C9D5923F04B4; Fri, 24 Oct 2014 15:45:32 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 15:45:32 +0200 From: "Stach, Thomas" To: Christer Holmberg Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits Thread-Index: AQHP75DHU7BgBBr8mEyhcE1sph1Eug== Date: Fri, 24 Oct 2014 13:45:31 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C4243@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C4243@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SWO_gzttCWhRf6jSWlhBKZRRiJQ Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 13:45:36 -0000 Christer,=20 thanks for the response. Two alternative proposal below. > > Section 8.2.2. Request offerer BUNDLE address selection I can't parse t= hat > caption. >=20 > Based on Paul's review, I suggest to change that to "Request the offerer > BUNDLE address". [TS] I think this caption does exactly reflect semantics of what's going on= in that paragraph. The offerer does not request a BUNDLE address, it is rather a suggestion. What about "Suggesting the offerer BUNDLE address" >=20 > >Section 8.5.3, 2nd bullet > >I could hardly parse this. > > o Place the SDP 'mid' attribute value associated with the "m=3D" lin= e > > in the SDP 'group:BUNDLE' attribute mid list associated with the > > BUNDLE group [Section 8.2.2]. > > I think it means that the list of identification-tags (mid-values) in t= he > group-attribute from the previous offer > > needs to be extended with the identification-tag that is carried in the > 'mid' attribute of the additional m-line. Correct? >=20 > Yes. >=20 > I guess I could remove "associated with the BUNDLE group []", if it makes= it > more clear.=20 [TS] That already helps, but what about: "Extend the SDP 'group:BUNDLE' attribute mid list with the additional SDP = 'mid' attribute value." I still think that "mid list" and "mid attribute value " are unfortunate te= rms though. Regards Thomas >That is the wording used for the initial offer, so... >=20 > --------------------- From nobody Fri Oct 24 07:50:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7102D1A19E4 for ; Fri, 24 Oct 2014 07:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOtweJISWyy4 for ; Fri, 24 Oct 2014 07:50:16 -0700 (PDT) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530DC1A033B for ; Fri, 24 Oct 2014 07:50:15 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/24/2014 10:50:13 AM X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 10/17/2014 9:19:05 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-370/SG:2 10/24/2014 10:49:59 AM X-GBUdb-Analysis: 0, 67.231.149.202, Ugly c=0.761941 p=-0.98401 Source White X-Signature-Violations: 0-0-0-4426-c X-Note-419: 0 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 10/24/2014 10:49:56 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.149.202 X-Note-Reverse-DNS: mx0a-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G230 G231 G232 G233 G237 G238 G350 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.149.202] (HELO mx0a-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTP id 165907292 for mmusic@ietf.org; Fri, 24 Oct 2014 10:50:13 -0400 Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id s9OEkt5A026986 for ; Fri, 24 Oct 2014 10:50:12 -0400 Received: from mail.vidyo.com (mail1.vidyo.com [162.209.16.213]) by mx0a-00198e01.pphosted.com with ESMTP id 1q76tt06qg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 24 Oct 2014 10:50:12 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 09:50:11 -0500 From: Jonathan Lennox To: mmusic Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqA== Date: Fri, 24 Oct 2014 14:50:11 +0000 Message-ID: References: <5436E6F2.2010202@cisco.com> In-Reply-To: <5436E6F2.2010202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.17.94.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0B3F3B382269B2498837A632B97762EE@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-24_04:2014-10-24,2014-10-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410240125 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Bg9-QAzqLsM2aTXbaKdOufPR3ts Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 14:50:18 -0000 One issue which I=92ve brought up a number of times in BUNDLE is whether it= =92s valid for an RTP stream to move between bundled m-lines, or be shared = between several bundled m-lines. While (as I=92ve described) there are a number of useful features that this= could enable, it sounded at the last IETF meeting that people weren=92t in= terested in the complexity it introduces. (It=92s certainly something that= wouldn=92t be possible with unbundled m-lines.) As such, I think BUNDLE n= eeds to document that this isn=92t allowed. As such, I suggest adding to the section on MID something like: RTP streams MUST NOT be moved between media descriptions. If a MID is comm= unicated for an RTP stream, that stream's SSRC MUST NOT be reused for anoth= er RTP stream with a different MID value until at least twice the Maximum S= egment Lifetime (MSL) has elapsed since the last time a packet (RTP or RTCP= ) was sent for the old stream. This makes sure that stuck packets in the network can't confuse a stream=92= s MID association. If people *do* want the ability to move streams between m-lines, we will ne= ed some more complicated rules, which I could try to draft if people are in= terested.= From nobody Fri Oct 24 08:26:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39E31A1A2D for ; Fri, 24 Oct 2014 08:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXplrIiBYSl2 for ; Fri, 24 Oct 2014 08:26:39 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6936D1A0115 for ; Fri, 24 Oct 2014 08:26:39 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id B1E46EFB1874; Fri, 24 Oct 2014 15:26:35 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9OFQbsN007695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 11:26:38 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 11:26:38 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: AQHP7t66dy5ZGL+nPEG/1c9gL4hdCZw+EJjQgABWxQCAAPUTgA== Date: Fri, 24 Oct 2014 15:26:37 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> <544966CE.2080709@alum.mit.edu> In-Reply-To: <544966CE.2080709@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/qzyp6nICR8YvXGFjs6hKQ0Ac-XI Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 15:26:41 -0000 >> Suppose the intent is to close one MSRP session and immediately open a > >> new one. Is it permissible to simply update the SDP to describe the ne= w > >> MSRP session, reusing the channel number, without first doing an O/A t= o > >> confirm the closure of the old one? > > > > The intent is not to reuse a datachannel (same or a different subprotoc= ol) > > before close. We will clarify that such a reuse is not supported. > > The problem with such reuse is, previous datachannel MUST be reset befo= re > > it is used for new subprotocol, else the data from previous data channe= l > use > > will interfere with the new data channel use. >=20 > My question is: Can I just close it in-band (with a reset) and then send > an offer for the new usage of the channel? No. To reuse a closed data channel, a new SDP offer/answer, to convey the=20 data channel closure (which excludes the corresponding a=3Ddcmap and may in= clude other new data channels via new a=3Ddcmaps), must be done. This can be done= either=20 in a new offer initiated from this end or in an SDP answer this end generat= es. The reason for this is to avoid various race conditions between SDP offer/a= nswer and SCTP reset arrival times. Also, this is not a limiting thing as a new data channel can easily be crea= ted=20 using a new stream id, range is for which is large, without restarting unde= rlying SCTP/DTLS association. If you agree I will update draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel with these clarifications. BR Raju From nobody Fri Oct 24 08:28:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B014A1A0115 for ; Fri, 24 Oct 2014 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzbCHCYT-VQD for ; Fri, 24 Oct 2014 08:28:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F381D1A0AF7 for ; Fri, 24 Oct 2014 08:28:05 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-df-544a7003bbcc Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.68.24955.3007A445; Fri, 24 Oct 2014 17:28:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 17:28:03 +0200 From: Christer Holmberg To: "Stach, Thomas" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions Thread-Index: Ac/u1uD0Q8E9/mIMRDq8+AIzqzfe/wABsBFgACiLmAAAB1uv0A== Date: Fri, 24 Oct 2014 15:28:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C62C9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C427D@ESESSMB209.ericsson.se> 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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjS5zgVeIwYWfVhZTlz9msTi5cxuz A5PHkiU/mTy29zxmCWCK4rJJSc3JLEst0rdL4MpYtOQ4c0G7fMWCl1fYGxifSnQxcnJICJhI NE3uYIewxSQu3FvP1sXIxSEkcJRR4sWbg1DOEkaJXaemA1VxcLAJWEh0/9MGaRAR0JGYPfMx WDOzgJzEhskv2UBsYYE4iUvtb5ghauIlPhxdxQphO0nsnLOaCcRmEVCVaJq0mAXE5hXwlVi8 dSJYvZDAdUaJicc9QWxOAX+JOcvfg/UyAh33/dQaJohd4hK3nsxngjhaQGLJnvPMELaoxMvH /1ghbCWJRbc/Q9XrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFl FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZg/Bzc8lt1B+PlN46HGAU4GJV4eBds8gwRYk0s K67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MXD9zXZd8rNvC8Tr9 uWTDXFumPVorKi3zbl85anaO2Sdj5lrJrtmGmp/M3a88ur7jbF+swgfRZXuObj9wsF9co/l4 VEiG/9tCk9pi7cvfxTYtXiU2W3l+sEhDWeGnCQFzN3OdXcRYzJJc9z71bWJrWMzDw05P8xkD m0J6vnC8Kj128OLS29v3KbEUZyQaajEXFScCABXK26aAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vU25AbrEpUNV6oS0GAT35LspPYI Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - ICE Interactions X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 15:28:10 -0000 Hi, >>> Section 11.2.1 >>> >>> When an offerer or answerer assigns a unique address to a bundled >>> "m=3D" line (excluding bundle-only "m=3D" lines), it MUST also assign >>> unique ICE candidates [RFC5245] to the "m=3D" line. >>> >>> Why does the answerer assign a unique address to a bundled m-line? >>> The m-line either bundled, then it is shared address. >>> Or if the answerer assigns a unique address, the m-line is not bundled. >>=20 >> Unique addresses must be used in the initial offer, before it is known=20 >> whether the answerer supports BUNDLE. > [TS] Certainly true for the offer, but I asked about the answer. > Here is my reasoning with corrected grammar: > The m-line is either bundled, then a shared address was assigned by the a= nswerer. >Or if the answerer assigned a unique address, then the m-line is not bundl= ed. Aaah... I hear you. The text is a general statement, but there are no cases= where the answerer would assign a unique address to a bundled m- line. So, I can modify the text, and remove "or answerer". =20 --------------------------------- =20 >>> When an offerer or answerer assigns a shared address (i.e. a >>> previously selected BUNDLE address) to one or more bundled "m=3D" lin= e >>> (including bundle-only "m=3D" lines), and when it assigns an address >>> with a zero port value to one or more bundle-only "m=3D" lines, it MU= ST >>> assign identical ICE candidates (referred to as shared ICE >>> candidates) to each of those "m=3D" lines. >>> >>> What are these identical ICE candidates? >>>=20 >> The ICE candidate values are identical. >>=20 >> Are these the unique ICE candidates from the 1st para? >>=20 >> It is the ICE candidate associated with the m- line that was selected=20 >> for the offerer BUNDLE address. >[TS] Then the candidates for all m-lines in the BUNDLE are identical to th= ese.=20 >But what happens due to the bundle-only m-lines that carry port zero? >You will not have a default candidate that matches port zero in the m-line= . >Wouldn't this result in an ICE-mismatch for all these m-lines if you follo= w the >RFC5245 rules blindly? > >I see various ways how this could be addressed:=20 >by stating an exemption from the 5245 rules for bundle-only m-linesor addi= ng an >additional candidate with port 0 to bundle-only m-lines or just omit= ting the >candidates complete from a bundle-only m-line. >In the latter case, a non-BUNDLE answerer would ignore that m-line in the = offer >anyhow and an answerer in support of BUNDLE would know how to deal w= ith it >(based on some text that we would still need to provide). When the offerer assigns a shared address, the usage of BUNDLE has already = been negotiated. So, in that case we perhaps don't need to assign port zero= to new bundle-only m- lines - it is enough to assign the bundle-only attri= bute. But, when you send the initial offer, with unique addresses, the bundle-onl= y m- lines will contain port zero.=20 --------------------------------- =20 >> Section 11.2.3 >> When an answerer generates an answer, which contains a BUNDLE group, >> the answerer MUST assign shared ICE candidates to each bundled "m=3D" >> line (including "m=3D" lines that were indicated as bundle-only in the >> associated offer) in the answer. >> >> Does this mean that the answerer copies of all candidates into every=20 >> m-line of a BUNDLE? >> >> If the ICE candidates are shared, wouldn't it be sufficient to=20 >> include them only once? >>=20 >> I believe this was discussed quite a while ago, and the outcome was=20 >> that we should not use assign candidate values in an implicit way. > [TS] I'll look it up. It might be good to include the reasons in the text= to avoid=20 > repeated questions. I think the general reason for not having implicit information is to avoid = problems with intermediaries. Regards, Christer From nobody Fri Oct 24 08:31:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC44E1A1A2D for ; Fri, 24 Oct 2014 08:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C3cO3M1cHz9 for ; Fri, 24 Oct 2014 08:31:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29901A1A01 for ; Fri, 24 Oct 2014 08:31:25 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-2d-544a70cbff19 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D7.84.04081.BC07A445; Fri, 24 Oct 2014 17:31:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 17:31:23 +0200 From: Christer Holmberg To: "Stach, Thomas" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS handling Thread-Index: Ac/u1taQOLbO/QrPTb2C6VqW5Nw7IgABTnqAACjwrQAAB9Sv8A== Date: Fri, 24 Oct 2014 15:31:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C62FC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C4262@ESESSMB209.ericsson.se> 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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7pAq8Qg3n9mhZTlz9msTi5cxuz A5PHkiU/mTy29zxmCWCK4rJJSc3JLEst0rdL4MqY9HMSS8FKvoplP5ewNjAu4+5i5OSQEDCR 2PmkmxHCFpO4cG89WxcjF4eQwFFGiY/9L1ghnCWMEl1b5zN3MXJwsAlYSHT/0wZpEBHQkZg9 8zE7iM0sICexYfJLNhBbWCBKYue6WywQNdESj6acZQRpFRFwkvjxpAAkzCKgKnHn9VVWEJtX wFfi7oZ+qL3XGSXm/dwNNpNTwF9i1aUWsCJGoOO+n1rDBLFLXOLWk/lMEEcLSCzZc54ZwhaV ePn4HyuErSSx6PZnqHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoW MLKsYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMn4NbfhvsYHz53PEQowAHoxIP74JNniFC rIllxZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGRVdIwrvpu9fS4 Q3I3UwQnH1/0u/nhC6/Snybu5l3cKuz7lpW+39JayKL3L/PHQau4hkV6Lv/3z12wMnVS0erw Z/1zBRvtduSml0rtkK3mqnrJ84TV6dDOQ3ef6q45tvbiZBmt3nCLUhn5dXXP8rhfXStVebxh oY3dpz+T/Bk48/95fHK+wmSqxFKckWioxVxUnAgAn9qq64ACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/t5GNci9Rr4NF0xaO975he1UosJY Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - BAS handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 15:31:27 -0000 Hi, >> Must-send-BAS played a central part in the agreement to merge the=20 >> pre-merger BUNDLE mechanism with Cullen's mechanism. >>=20 >> And, the reason for sending it is the same as for sending the updated=20 >> ICE offer. > > [TS] And for that exact reason it needs to treated in the same way.=20 > But let's wait for the outcome of that other discussion on the ICE update= d offer We can wait, but I once again want to remind you that must-send-BAS was pro= bably the main reason why we could agree on a single BUNDLE mechanism. >> Also keep in mind that you can use BUNDLE without ICE, in which case=20 >> SDP is the only way (as you don't send STUN requests) to inform the=20 >> remote endpoint about the selected address. > > [TS] Who is the remote endpoint? > Offerer and Answerer certainly know the selected addresses from the SDP a= nswer. Sorry, I meant intermediaries. Regards, Christer > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@unify.com] > Sent: 23 October 2014 18:35 > To: Christer Holmberg > Cc: 'mmusic' > Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12=20 > - BAS handling >=20 > All, >=20 > as noted in the draft: > The main purpose of the BAS offer is to ensure that > intermediaries, that might not support the BUNDLE extension, have > correct information regarding the address is going to be used to > transport the bundled media. > This is the same motivation as for the "ICE updated offer". >=20 > Consequently, BUNDLE and ICE need to behave in the same way. > I don't want to restart the corresponding discussion for BAS again,=20 > but I personally prefer, that BAS should be optional, with the offerer=20 > indicating if it will perform BAS or not. >=20 > Regards > Thomas From nobody Fri Oct 24 08:46:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D391A1AD3 for ; Fri, 24 Oct 2014 08:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkx53StmPDMK for ; Fri, 24 Oct 2014 08:46:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22A81A1AB6 for ; Fri, 24 Oct 2014 08:45:01 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-fa-544a73fba495 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 37.9C.04387.BF37A445; Fri, 24 Oct 2014 17:44:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 17:44:59 +0200 From: Christer Holmberg To: "Stach, Thomas" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits Thread-Index: Ac/u1r6MPHtnXAm3R8uZQhYrmpbrZAAApkLQACmq+IAACAD+cA== Date: Fri, 24 Oct 2014 15:44:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C633C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C4243@ESESSMB209.ericsson.se> 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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje7vYq8Qg8svrCymLn/MYnFy5zZm ByaPJUt+Mnls73nMEsAUxWWTkpqTWZZapG+XwJWxtOMNW8FhvopFxw+wNTAe4+5i5OSQEDCR WL/vNRuELSZx4d56IJuLQ0jgKKPExFcPGSGcJYwSP5vuAGU4ONgELCS6/2mDNIgI6EjMnvmY HcRmFpCT2DD5JdggYYEYie5rX9ggamIlHu1oZ4SwnSQurJ3AAmKzCKhKvJqzFayXV8BXYsrm qUwQu64D7VpzkRUkwSngLzHz6nmwZkag676fWsMEsUxc4taT+UwQVwtILNlznhnCFpV4+fgf K4StJLHo9meoeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYxis5CMnYWkZRaSlllIWhYwsqxi FC1OLS7OTTcy0kstykwuLs7P08tLLdnECIygg1t+W+1gPPjc8RCjAAejEg/vgk2eIUKsiWXF lbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFsX1334Us99ck5F3kW Vns+aJwTtnLz2stKWQ66+1IjEi87Ch9okjq0/t+Cw2/DFVc/tRCrFd3mpef9gLn+U8GqvRn+ t1Oz1v34PdG4VZxPVXn7Mktzpr9KLqZTW55s0Vq/VLS4fr/s2bwfYscingR8lNxnsSGgnKcn lYlz+dvQoA17ti61W6PEUpyRaKjFXFScCABRls+igQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TDxZcf43Qtg9bcrcd87trq_c93g Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 15:46:39 -0000 Hi, >>> Section 8.2.2. Request offerer BUNDLE address selection I can't=20 >>> parse that caption. >>=20 >> Based on Paul's review, I suggest to change that to "Request the=20 >> offerer BUNDLE address". > [TS] I think this caption does exactly reflect semantics of what's going = on in that=20 > paragraph. > > The offerer does not request a BUNDLE address, it is rather a suggestion. > What about "Suggesting the offerer BUNDLE address" We would have to go through the text and make sure it doesn't cause misalig= ned terminology. In addition, there is a section named "Request a new offerer BUNDLE address= ", which we also would have to change. >>>Section 8.5.3, 2nd bullet >>>I could hardly parse this. >>> o Place the SDP 'mid' attribute value associated with the "m=3D" lin= e >>> in the SDP 'group:BUNDLE' attribute mid list associated with the >>> BUNDLE group [Section 8.2.2]. >>> I think it means that the list of identification-tags (mid-values)=20 >>> in the group-attribute from the previous offer >>> needs to be extended with the identification-tag that is carried in=20 >>> the 'mid' attribute of the additional m-line. Correct? >>=20 >> Yes. >>=20 >> I guess I could remove "associated with the BUNDLE group []", if it=20 >> makes it more clear. > [TS] That already helps, but what about: > "Extend the SDP 'group:BUNDLE' attribute mid list with the additional SDP= 'mid'=20 > attribute value." I can do that, but I don't think we need both "Extend" and "additional".=20 So, perhaps: "Extend the SDP 'group:BUNDLE' attribute mid list with the SDP 'mid'=20 attribute value associated with the "m=3D" line." > I still think that "mid list" and "mid attribute value " are unfortunate = terms though. We'll discuss that in the dedicated thread. Regards, Christer From nobody Fri Oct 24 09:01:17 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795F61A1B75 for ; Fri, 24 Oct 2014 09:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu0YhX1HUsLN for ; Fri, 24 Oct 2014 09:01:06 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054D11A1A9E for ; Fri, 24 Oct 2014 09:01:03 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-3e-544a77beabce Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F5.58.04081.EB77A445; Fri, 24 Oct 2014 18:01:02 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 18:01:01 +0200 From: Christer Holmberg To: Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQ Date: Fri, 24 Oct 2014 16:01:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> References: <5436E6F2.2010202@cisco.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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje6+cq8Qgw+vBSz2Lz7PbDF1+WMW ByaPJUt+Mnm0PbvDHsAUxWWTkpqTWZZapG+XwJXx8/wqxoIGwYrt1/6wNDDe4O1i5OSQEDCR eLnzPDOELSZx4d56ti5GLg4hgaOMEnvWr2eFcJYwSkzdu4Wxi5GDg03AQqL7nzZIg4iAk8TR OSvBmoUFwiVmLLzDDhGPkGi79Z8dpFxEwEhi/49YkDCLgKpE+5pHYOW8Ar4SP7Z8YQOxhQSi JZ6d6QFr5RSwlVi75goLiM0IdM/3U2uYQGxmAXGJW0/mM0HcKSCxZA/MzaISLx//Y4WwlSQW 3f4MVa8jsWD3JzYIW1ti2cLXUHsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMosWpxUm5 6UZGeqlFmcnFxfl5enmpJZsYgVFycMtvgx2ML587HmIU4GBU4uFdsMkzRIg1say4MvcQozQH i5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MJqfcLjz195i62XX8qXXJL/9+FOh zic0517iMtlKtY5tr+4n7o9Y8u4df9GG+kPhXz1eB3On/rre/GZrv6LZBUvZgE7JSYv91R8c /h71a3Pj8lsuVQExVttYdsXOPsDDecb2VlNrVd4aOeXmQy381699rgvQuHNs+YIeOzH5s4u5 ry4T8HQS0VNiKc5INNRiLipOBAAuRSH9cwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/0CUn-NnRKEBZ8rCT8AGGyMOERIE Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 16:01:11 -0000 Hi Jonathan, In the RTP Considerations section, we currently have the following text: "A given SSRC MUST NOT transmit RTP packets using payload types that=20 originate from different bundled "m=3D" lines." That doesn't cover what you are talking about, but perhaps we could add a s= tatement saying something like: "A given SSCR MUST NOT transmit RTP packets associated with different "m= =3D" lines. When the RTP MID header extension is used, the SSRC MUST use the same 'mid' val= ue in every RTP packet." ...or something like that. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lennox Sent: 24 October 2014 17:50 To: mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lin= es, or not One issue which I've brought up a number of times in BUNDLE is whether it's= valid for an RTP stream to move between bundled m-lines, or be shared betw= een several bundled m-lines. While (as I've described) there are a number of useful features that this c= ould enable, it sounded at the last IETF meeting that people weren't intere= sted in the complexity it introduces. (It's certainly something that would= n't be possible with unbundled m-lines.) As such, I think BUNDLE needs to = document that this isn't allowed. As such, I suggest adding to the section on MID something like: RTP streams MUST NOT be moved between media descriptions. If a MID is comm= unicated for an RTP stream, that stream's SSRC MUST NOT be reused for anoth= er RTP stream with a different MID value until at least twice the Maximum S= egment Lifetime (MSL) has elapsed since the last time a packet (RTP or RTCP= ) was sent for the old stream. This makes sure that stuck packets in the network can't confuse a stream's = MID association. If people *do* want the ability to move streams between m-lines, we will ne= ed some more complicated rules, which I could try to draft if people are in= terested. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Oct 24 09:07:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA611A1BBD for ; Fri, 24 Oct 2014 09:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o97JzSKwEI94 for ; Fri, 24 Oct 2014 09:07:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9993D1A1B8E for ; Fri, 24 Oct 2014 09:07:39 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-b2-544a79490ff8 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 49.09.04081.9497A445; Fri, 24 Oct 2014 18:07:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 18:07:37 +0200 From: Christer Holmberg To: Jonathan Lennox , mmusic Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQgAAFRoA= Date: Fri, 24 Oct 2014 16:07:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja5npVeIwfLPhhb7F59ntpi6/DGL A5PHkiU/mTzant1hD2CK4rJJSc3JLEst0rdL4Mr43/abpaBRtGL1/h6WBsYWwS5GTg4JAROJ 1QduskPYYhIX7q1n62Lk4hASOMoocfz9TlYIZwmjxMoP7UAOBwebgIVE9z9tkAYRASeJo3NW MoPYwgLhEjMW3mGHiEdItN36D2VbSTQdnQRWwyKgKjF31TIWEJtXwFfixJ4JjBDz5zNK/Lh8 jBEkwSngJ9HVfoUJxGYEuuj7qTVgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW0li0e3P UPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqclJtu ZKSXWpSZXFycn6eXl1qyiREYKQe3/DbYwfjyueMhRgEORiUe3gWbPEOEWBPLiitzDzFKc7Ao ifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenFDBSkt9vMPlwXPPNjc0ROY+P1HJ+rZQW eOYk4GKcdJvxV47x5Rk3V8wp5orZdW12gL7N7MVTtFMC0g9pdl3rPTTNYfuEz5YReesr9+oa By+5uLf79As18ZCQw3VvL73YOGXb6XKN9dt//9a8eejq7Gs/C/5z6avK75yucKVmjwiH490p v338si9sUmIpzkg01GIuKk4EANpT3VJ1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Nixpf-I9Pgc-dc2Kq430yWqKvGQ Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 16:07:42 -0000 ...and, obviously the SSRC would also always use the same MID in the RTCP S= DES MID item. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 24 October 2014 19:01 To: Jonathan Lennox; mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lin= es, or not Hi Jonathan, In the RTP Considerations section, we currently have the following text: "A given SSRC MUST NOT transmit RTP packets using payload types that=20 originate from different bundled "m=3D" lines." That doesn't cover what you are talking about, but perhaps we could add a s= tatement saying something like: "A given SSCR MUST NOT transmit RTP packets associated with different "m= =3D" lines. When the RTP MID header extension is used, the SSRC MUST use the same 'mid' val= ue in every RTP packet." ...or something like that. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lennox Sent: 24 October 2014 17:50 To: mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lin= es, or not One issue which I've brought up a number of times in BUNDLE is whether it's= valid for an RTP stream to move between bundled m-lines, or be shared betw= een several bundled m-lines. While (as I've described) there are a number of useful features that this c= ould enable, it sounded at the last IETF meeting that people weren't intere= sted in the complexity it introduces. (It's certainly something that would= n't be possible with unbundled m-lines.) As such, I think BUNDLE needs to = document that this isn't allowed. As such, I suggest adding to the section on MID something like: RTP streams MUST NOT be moved between media descriptions. If a MID is comm= unicated for an RTP stream, that stream's SSRC MUST NOT be reused for anoth= er RTP stream with a different MID value until at least twice the Maximum S= egment Lifetime (MSL) has elapsed since the last time a packet (RTP or RTCP= ) was sent for the old stream. This makes sure that stuck packets in the network can't confuse a stream's = MID association. If people *do* want the ability to move streams between m-lines, we will ne= ed some more complicated rules, which I could try to draft if people are in= terested. _______________________________________________ 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 nobody Fri Oct 24 09:16:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9361A1BEC for ; Fri, 24 Oct 2014 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRjzUj-VDvud for ; Fri, 24 Oct 2014 09:16:01 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3D01A1BE5 for ; Fri, 24 Oct 2014 09:16:01 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-12v.sys.comcast.net with comcast id 74Fh1p00258ss0Y014G09o; Fri, 24 Oct 2014 16:16:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id 74Fz1p00N3Ge9ey014G09l; Fri, 24 Oct 2014 16:16:00 +0000 Message-ID: <544A7B3F.3020000@alum.mit.edu> Date: Fri, 24 Oct 2014 12:15:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4C4243@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C633C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C633C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414167360; bh=9nMRKia8aPPL09JVJWI1yXly9cVEuSoWt6iKSUyTjZI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Si0Jcvs1jWL7/2al/jdBWs4nCdlB1b9ptd/eabHYSmMEUbVrcZqllZH6G8YZ6wYFl CX1AABjIBBxewTRvC2CnRYEH0Ybt9hvYuwKFAxlw+QxPDXTBycxxDSCFAsy3qWqIYF VZyTJK1+ZqScqVxixUnXQBhaeAgoMWjnk2R1hnq074belkJiaHkyZxhr6ekLNKswk5 dpGEmSkipZhhwGW5QcrxZMfJEVgtmSVNvd/Ki+mugcXFkSiPgwp+NPnbzISzURjy/A Jpk3CiihdtS81qBkTALa5E23mHRTbQdPgkMjcaCLD6zZGZg7VZlLUMvAkkaMIO12Yo GldSbDbXNuUsg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/V-C5DPsoE6VizlSrhEqNVEkSa38 Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 16:16:03 -0000 On 10/24/14 11:44 AM, Christer Holmberg wrote: > Hi, > >>>> Section 8.2.2. Request offerer BUNDLE address selection I can't >>>> parse that caption. >>> >>> Based on Paul's review, I suggest to change that to "Request the >>> offerer BUNDLE address". >> [TS] I think this caption does exactly reflect semantics of what's going on in that >> paragraph. >> >> The offerer does not request a BUNDLE address, it is rather a suggestion. >> What about "Suggesting the offerer BUNDLE address" > > We would have to go through the text and make sure it doesn't cause misaligned terminology. > > In addition, there is a section named "Request a new offerer BUNDLE address", which we also would have to change. It seems that Thomas had the same problem with the title that I did, and arrived at the same proposed solution. So I'm in favor of making this change, and then touching up other text if necessary. Thanks, Paul >>>> Section 8.5.3, 2nd bullet >>>> I could hardly parse this. >>>> o Place the SDP 'mid' attribute value associated with the "m=" line >>>> in the SDP 'group:BUNDLE' attribute mid list associated with the >>>> BUNDLE group [Section 8.2.2]. >>>> I think it means that the list of identification-tags (mid-values) >>>> in the group-attribute from the previous offer >>>> needs to be extended with the identification-tag that is carried in >>>> the 'mid' attribute of the additional m-line. Correct? >>> >>> Yes. >>> >>> I guess I could remove "associated with the BUNDLE group []", if it >>> makes it more clear. >> [TS] That already helps, but what about: >> "Extend the SDP 'group:BUNDLE' attribute mid list with the additional SDP 'mid' >> attribute value." > > I can do that, but I don't think we need both "Extend" and "additional". > > So, perhaps: > > "Extend the SDP 'group:BUNDLE' attribute mid list with the SDP 'mid' > attribute value associated with the "m=" line." > >> I still think that "mid list" and "mid attribute value " are unfortunate terms though. > > We'll discuss that in the dedicated thread. > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Oct 24 09:35:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FECB1A6F39 for ; Fri, 24 Oct 2014 09:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pflPJZjFdeE for ; Fri, 24 Oct 2014 09:35:00 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0962E1A6F63 for ; Fri, 24 Oct 2014 09:34:56 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-06v.sys.comcast.net with comcast id 74Yp1p00A57bBgG014avhv; Fri, 24 Oct 2014 16:34:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id 74av1p0023Ge9ey014av1Y; Fri, 24 Oct 2014 16:34:55 +0000 Message-ID: <544A7FAE.1070206@alum.mit.edu> Date: Fri, 24 Oct 2014 12:34:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> <544966CE.2080709@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414168495; bh=NUwQ+ValLgy1Z81+SXqgPAOSalDl7z9tP3C29EotH/s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=c1Q87YvCAWH43XHXZe3oROs2kwo/S8EXUsB0w5gCwqqJqHPqx4QuyytpldHbIPLb0 nqYR18Td6aBdWwrr5CqdIUt1BMT/muETXzebmTFWG5LSMYRv1w8OQ2BtEi4g/ZLNBe ZW3Yc3EqxDyHdflXg15jLVmM0K2Dj/tZHi1FUf1Cih73cltmAHwmYGvPl/0zybYMCn 5cQ6NLNX5cz/HnBonC3pDyHCDesGQhoD4rIup6D5jXL2PX06ySY/ESzW7NDsmJDGMl lOMAW02VrEt9tsepvIhoF+q+R2V1voYJM0yJFvRf4xd6EeVV0kWfMT2oqWlFkAtdki /2noMEgMlhpxg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/rcH2tI78IOFneppkGfquemd8STM Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 16:35:01 -0000 On 10/24/14 11:26 AM, Makaraju, Maridi Raju (Raju) wrote: >>> Suppose the intent is to close one MSRP session and immediately open a >>>> new one. Is it permissible to simply update the SDP to describe the new >>>> MSRP session, reusing the channel number, without first doing an O/A to >>>> confirm the closure of the old one? >>> >>> The intent is not to reuse a datachannel (same or a different subprotocol) >>> before close. We will clarify that such a reuse is not supported. >>> The problem with such reuse is, previous datachannel MUST be reset before >>> it is used for new subprotocol, else the data from previous data channel >> use >>> will interfere with the new data channel use. >> >> My question is: Can I just close it in-band (with a reset) and then send >> an offer for the new usage of the channel? > > > No. To reuse a closed data channel, a new SDP offer/answer, to convey the > data channel closure (which excludes the corresponding a=dcmap and may include > other new data channels via new a=dcmaps), must be done. This can be done either > in a new offer initiated from this end or in an SDP answer this end generates. > The reason for this is to avoid various race conditions between SDP offer/answer > and SCTP reset arrival times. > Also, this is not a limiting thing as a new data channel can easily be created > using a new stream id, range is for which is large, without restarting underlying > SCTP/DTLS association. ISTM there is a useful analogy here to reusing m-lines. It once was thought that if you had been using an m-line for one thing (say an audio session), and then you wanted to stop that and start using that m-line for something else (say T38), you first had to send an offer setting the port to zero on the audio line, and then in a later offer you could then reuse that rejected m-line for T38. Eventually it was clarified that this was silly and unnecessary - that you could simply send a new offer replacing the audio m-line with a T38 m-line. So ISTM that here the following ought to be valid: 1) offer with dcmap for channel C, subprotocol C1, label C1 2) use channel C, subprotocol C1 3) send reset on channel C 4) offer with dcmap for channel C, subprotocol C2, label C2 5) use channel C, subprotocol C2 The following also ought to be valid: 1) offer with dcmap for channel C, subprotocol C1, label C1 2) use channel C, subprotocol C1 3a) offer lacking channel C 3b) send reset on channel C 4) offer with dcmap for channel C, subprotocol C2, label C2 5) use channel C, subprotocol C2 (I think the above is what you are advocating.) The following should *not* be valid: 1) offer with dcmap for channel C, subprotocol C1, label C1 2) use channel C, subprotocol C1 4) offer with different dcmap for channel C, subprotocol C2, label C2 5) use channel C, subprotocol C2 Thanks, Paul From nobody Fri Oct 24 10:43:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CA11A899D for ; Fri, 24 Oct 2014 10:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAB6y95z0nrM for ; Fri, 24 Oct 2014 10:43:33 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EA11A8998 for ; Fri, 24 Oct 2014 10:43:32 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id A5050F07061DE; Fri, 24 Oct 2014 17:43:29 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9OHhUYb020360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 13:43:31 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 13:43:30 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: AQHP7t66dy5ZGL+nPEG/1c9gL4hdCZw+EJjQgABWxQCAAPUTgIAAWcEA//+91kA= Date: Fri, 24 Oct 2014 17:43:30 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> <544966CE.2080709@alum.mit.edu> <544A7FAE.1070206@alum.mit.edu> In-Reply-To: <544A7FAE.1070206@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8tQnd1FeGtYickVOVo_n40tCjYo Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 17:43:34 -0000 > On 10/24/14 11:26 AM, Makaraju, Maridi Raju (Raju) wrote: > >>> Suppose the intent is to close one MSRP session and immediately open = a > >>>> new one. Is it permissible to simply update the SDP to describe the = new > >>>> MSRP session, reusing the channel number, without first doing an O/A= to > >>>> confirm the closure of the old one? > >>> > >>> The intent is not to reuse a datachannel (same or a different > subprotocol) > >>> before close. We will clarify that such a reuse is not supported. > >>> The problem with such reuse is, previous datachannel MUST be reset > before > >>> it is used for new subprotocol, else the data from previous data chan= nel > >> use > >>> will interfere with the new data channel use. > >> > >> My question is: Can I just close it in-band (with a reset) and then se= nd > >> an offer for the new usage of the channel? > > > > > > No. To reuse a closed data channel, a new SDP offer/answer, to convey t= he > > data channel closure (which excludes the corresponding a=3Ddcmap and ma= y > include > > other new data channels via new a=3Ddcmaps), must be done. This can be = done > either > > in a new offer initiated from this end or in an SDP answer this end > generates. > > The reason for this is to avoid various race conditions between SDP > offer/answer > > and SCTP reset arrival times. > > Also, this is not a limiting thing as a new data channel can easily be > created > > using a new stream id, range is for which is large, without restarting > underlying > > SCTP/DTLS association. >=20 > ISTM there is a useful analogy here to reusing m-lines. > It once was thought that if you had been using an m-line for one thing > (say an audio session), and then you wanted to stop that and start using > that m-line for something else (say T38), you first had to send an offer > setting the port to zero on the audio line, and then in a later offer > you could then reuse that rejected m-line for T38. >=20 > Eventually it was clarified that this was silly and unnecessary - that > you could simply send a new offer replacing the audio m-line with a T38 > m-line. The above scenario is very well valid as there is no inband "SCTP Reset" eq= uivalent=20 procedure exists for RTP/UDP based media. Please see my further explanation= below; the SCTP reset makes such a reuse problematic. Also, I think the new offer many= times uses a new transport address (at least the port), which makes such a reuse easy. >=20 > So ISTM that here the following ought to be valid: >=20 > 1) offer with dcmap for channel C, subprotocol C1, label C1 > 2) use channel C, subprotocol C1 > 3) send reset on channel C > 4) offer with dcmap for channel C, subprotocol C2, label C2 > 5) use channel C, subprotocol C2 What if the "SCTP reset" from step3 above arrives at the peer after step4 S= DP offer? If DP arrives first then the data channel will later be closed when SCTP re= set arrives, which is not expected behavior. There is no guarantee that reset arrives first. This is unless the local cl= ient waits for data channel close indication (SCTP reset ack) from data channel stack and = sends new SDP offer. The problem with depending on such "close indication" is: - PeerConnection draft does not clearly say if and when it invokes onclose(= ) callback on the side which invokes close(). Not sure if onclose() is called after SCTP reset is acknowledged or befor= e?! - Not sure if non-browser clients will have a way (API) to know when=20 SCTP reset is acknowledged. This depends on data channel stack implementa= tion. >=20 > The following also ought to be valid: >=20 > 1) offer with dcmap for channel C, subprotocol C1, label C1 > 2) use channel C, subprotocol C1 > 3a) offer lacking channel C > 3b) send reset on channel C > 4) offer with dcmap for channel C, subprotocol C2, label C2 > 5) use channel C, subprotocol C2 >=20 > (I think the above is what you are advocating.) Correct. It is valid, allowed and is what we are advocating. >=20 > The following should *not* be valid: >=20 > 1) offer with dcmap for channel C, subprotocol C1, label C1 > 2) use channel C, subprotocol C1 > 4) offer with different dcmap for channel C, subprotocol C2, label C2 > 5) use channel C, subprotocol C2 Correct. It is not valid. In the first scenario above, this is how it looks like to the peer=20 if SCTP reset is not yet received at the time of this offer arrives. We planned on updating the draft-ejzak-mmusic-data-channel-sdpneg with the = following: 1. In a new SDP offer, if a=3Ddcmap specifies same subprotocol and label as= previous one then the updated subprotocol attributes (in a=3Ddcsa lines) are handled = per the=20 subprotocol semantics. 2. In a new SDP offer, if a=3Ddcmap specifies a different subprotocol and/o= r label than the previous offer then the offer must be rejected entirely so that prev= ious=20 SDP offer/answer is still valid. Appreciate your comments on this as well. Thanks Raju From nobody Fri Oct 24 11:29:12 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BBD1A1B63 for ; Fri, 24 Oct 2014 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYTKjBnJaM9j for ; Fri, 24 Oct 2014 11:29:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA191A037E for ; Fri, 24 Oct 2014 11:29:08 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9OIT4dX043268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2014 13:29:05 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <544A9A70.1010308@nostrum.com> Date: Fri, 24 Oct 2014 13:29:04 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Kyzivat , mmusic@ietf.org, draft-ietf-mmusic-rfc4566bis@tools.ietf.org References: <5446DCDB.6070409@nostrum.com> <544711FF.9020607@alum.mit.edu> In-Reply-To: <544711FF.9020607@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/6EigoD1-4Y8xPPbMRpIWKU0Fa-o Subject: [MMUSIC] Comment on draft-ietf-mmusic-rfc4566bis-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 18:29:10 -0000 On 10/21/14 21:10, Paul Kyzivat wrote: > Please take a look at draft-ietf-mmusic-rfc4566bis-12, where I have > redone the definitions of all the attributes defined there. > > I have adopted a definition style that doesn't use abnf to specify the > *name* of the attribute. So specifying the name in a case-sensitive > way isn't an issue. I suggest you follow that style. > > And, if you object to that style, please provide comments on that draft. That does seem cleaner, and I would think the MSID work should build on it. I do admit that I'm confused by draft-ietf-mmusic-rfc4566bis-12 section 8.2.4. The third bullet calls for an ABNF syntax rule defining for the syntax of the value. The seventh bullet calls for an ABNF definition for the syntax of the value. If this isn't straight-up duplication, then I think the document needs to make a clearer distinction between what it means by these two bullets. I certainly wouldn't know how to conform to these requirements if I needed to register a new attribute. /a From nobody Fri Oct 24 11:38:21 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F2D1A6F60 for ; Fri, 24 Oct 2014 11:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hG0P0sZ7JHl for ; Fri, 24 Oct 2014 11:38:16 -0700 (PDT) Received: from server209.appriver.com (server209i.appriver.com [8.31.233.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA601A0A85 for ; Fri, 24 Oct 2014 11:38:16 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/24/2014 2:38:13 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 10/17/2014 9:19:05 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-152/SG:2 10/24/2014 2:38:01 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.696782 p=-0.986111 Source White X-Signature-Violations: 0-0-0-9233-c X-Note-419: 31.1943 ms. Fail:1 Chk:1329 of 1329 total X-Note: SCH-CT/SI:1-1329/SG:1 10/24/2014 2:37:57 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G230 G231 G232 G233 G237 G238 G350 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTP id 166022844; Fri, 24 Oct 2014 14:38:13 -0400 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id s9OIZAqF009285; Fri, 24 Oct 2014 14:38:13 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.213] (may be forged)) by mx0b-00198e01.pphosted.com with ESMTP id 1q76vk0f2b-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 24 Oct 2014 14:38:13 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 13:38:12 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQgAAFRoCAAH4RgA== Date: Fri, 24 Oct 2014 18:38:11 +0000 Message-ID: <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.17.94.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0A79BA9F1646044DAA43E976B65F54D7@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-24_06:2014-10-24,2014-10-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410240154 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/AlV8jjF0Tnhp6BQft27hQXy91GM Cc: mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 18:38:19 -0000 Right. The case my =93twice the MSL=94 text is designed to handle is the case wher= e an SSRC leaves (sends RTCP bye), and then the sender spins up another SSR= C on a different mid, and happens to pick the same SSRC value. This should= n=92t happen very often (1 in 2^32) if SSRC randomization is implemented pr= operly, but sometimes people use bad random number generators (or are, e.g.= , playing games with not renumbering at a source projecting mixer). This i= sn=92t an SSRC collision, technically, since for the sender the old source = is gone, but if old packets with the old mid are still lingering in the net= work, you=92ll get confused. Thus my recommendation to make sure you wait = before you reuse SSRC values. On Oct 24, 2014, at 12:07 PM, Christer Holmberg wrote: > ...and, obviously the SSRC would also always use the same MID in the RTCP= SDES MID item. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmb= erg > Sent: 24 October 2014 19:01 > To: Jonathan Lennox; mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > Hi Jonathan, >=20 > In the RTP Considerations section, we currently have the following text: >=20 > "A given SSRC MUST NOT transmit RTP packets using payload types that=20 > originate from different bundled "m=3D" lines." >=20 > That doesn't cover what you are talking about, but perhaps we could add a= statement saying something like: >=20 > "A given SSCR MUST NOT transmit RTP packets associated with different "m= =3D" lines. When > the RTP MID header extension is used, the SSRC MUST use the same 'mid' v= alue in every > RTP packet." >=20 > ...or something like that. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lenno= x > Sent: 24 October 2014 17:50 > To: mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > One issue which I've brought up a number of times in BUNDLE is whether it= 's valid for an RTP stream to move between bundled m-lines, or be shared be= tween several bundled m-lines. >=20 > While (as I've described) there are a number of useful features that this= could enable, it sounded at the last IETF meeting that people weren't inte= rested in the complexity it introduces. (It's certainly something that wou= ldn't be possible with unbundled m-lines.) As such, I think BUNDLE needs t= o document that this isn't allowed. >=20 > As such, I suggest adding to the section on MID something like: >=20 > RTP streams MUST NOT be moved between media descriptions. If a MID is co= mmunicated for an RTP stream, that stream's SSRC MUST NOT be reused for ano= ther RTP stream with a different MID value until at least twice the Maximum= Segment Lifetime (MSL) has elapsed since the last time a packet (RTP or RT= CP) was sent for the old stream. >=20 > This makes sure that stuck packets in the network can't confuse a stream'= s MID association. >=20 > If people *do* want the ability to move streams between m-lines, we will = need some more complicated rules, which I could try to draft if people are = interested. > _______________________________________________ > 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 nobody Fri Oct 24 12:00:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9A41A89E9 for ; Fri, 24 Oct 2014 12:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g8iOeTo1hbo for ; Fri, 24 Oct 2014 11:59:58 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B5F1A1B1A for ; Fri, 24 Oct 2014 11:59:58 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-08v.sys.comcast.net with comcast id 76yq1p006516pyw016zyei; Fri, 24 Oct 2014 18:59:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-08v.sys.comcast.net with comcast id 76zw1p0033Ge9ey016zw2h; Fri, 24 Oct 2014 18:59:58 +0000 Message-ID: <544AA1A9.4080905@alum.mit.edu> Date: Fri, 24 Oct 2014 14:59:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adam Roach , mmusic@ietf.org, draft-ietf-mmusic-rfc4566bis@tools.ietf.org References: <5446DCDB.6070409@nostrum.com> <544711FF.9020607@alum.mit.edu> <544A9A70.1010308@nostrum.com> In-Reply-To: <544A9A70.1010308@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414177198; bh=NnbiJLFZTCu3dptcNAMsZtU2D6nnNl4bps+0QRvC5nE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aBtsE7UFTulYU4YMBkP/xZVy5QjNUZm3kyxhaHt5RqwJxvuRU5n+RiNhdLeaTBjth iFwlqArOnsDMNRhquX+Ax3Mq4wUzYK5lDI/Eib992YWESpi83nrJJ4Bumtf8vWkjA0 wH3gwUEXasJQS+tXOvyMCTMdC0YNCh8mCESPSpMIfVYGQOGzPVUobYNEaUn5qp8jp3 nuf4KaEtsGny7BFNVMOgY2TmiQ5Yj4aoDAEsq17HSYOxLLeO4RJ/3Iqkf1lcofzhsR u9xGdnOuLCC7SjKWdsnjXYhro2BzWyH0wcoJXDz2XesblhGiJlQIwPLhPimPX7D1Kn HEabMswl0VDOg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2r1ApuWomGqiTSGFf-H5TMpOoKs Subject: Re: [MMUSIC] Comment on draft-ietf-mmusic-rfc4566bis-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 19:00:00 -0000 On 10/24/14 2:29 PM, Adam Roach wrote: > I do admit that I'm confused by draft-ietf-mmusic-rfc4566bis-12 section > 8.2.4. The third bullet calls for an ABNF syntax rule defining for the > syntax of the value. The seventh bullet calls for an ABNF definition for > the syntax of the value. > > If this isn't straight-up duplication, then I think the document needs > to make a clearer distinction between what it means by these two > bullets. I certainly wouldn't know how to conform to these requirements > if I needed to register a new attribute. The third bullet asks for the *name* of an ABNF rule. The 7th bullet asks for the *definition* of that rule. I thought it was clear. If not, can you suggest a change to improve it? Also note, that the third bullet says to use [] to indicate an optional value. This isn't ABNF, though it looks like it. Attributes with optional values are rare. (There aren't any defined in 4566.) The thing about an optional value is that the ":" separator is only present if the value is. This is a way to say that without including the attribute name in the syntax of the value. (I forget which one, but I reviewed a proposal for a new attribute that did have an optional value, and it had initially put the ":" in when there was no value. It is important that we are consistent about how this is done.) Thanks, Paul From nobody Fri Oct 24 12:12:10 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5571A8AD3 for ; Fri, 24 Oct 2014 12:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_dGzeb4nTqQ for ; Fri, 24 Oct 2014 12:11:57 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EBC1A8A6D for ; Fri, 24 Oct 2014 12:11:55 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-12v.sys.comcast.net with comcast id 77BN1p00353iAfU017Bud7; Fri, 24 Oct 2014 19:11:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-10v.sys.comcast.net with comcast id 77Bu1p0093Ge9ey017BuDt; Fri, 24 Oct 2014 19:11:54 +0000 Message-ID: <544AA47A.9090303@alum.mit.edu> Date: Fri, 24 Oct 2014 15:11:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "mmusic@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> <544966CE.2080709@alum.mit.edu> <544A7FAE.1070206@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414177915; bh=UjSz7zM10rR8htLLJOjue9rqbKUMlCJYsPOcsAZi1Uo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vUu5X98m+NTkT6rCQMt6EPLEsK3P/RFNArCUWMYzhbaTWq7u2uKKhE5XvL6cYKafM OhefWzmkpsawGm7bdf7rr9W1NXNTiMSYnOHihTxkI/NzvPeWNOEPvM5DxkO5LZ0YwQ CYLKsRLnszUSpkYXI+V9FcCFMNTGo6bGhjvtDv6BHnAmqIJvrSzj1Hm5dvGnSzN/V+ pswNOpK6uHNdJGw/Hzj0JLthtufVcBMqkKyTdiygss7YGn0alZUvKosnJbECizZglc ne9+CjlO5V9u1n4DnbZeOOgA/tc+Kj4cRahfW7fpw7rkXdCd2Dg2Ig6/94SAXhaPD4 MMHpwFXYEy7IQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Sufpw_4E1HbpXta3AXKPz8G-fVc Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 19:12:04 -0000 On 10/24/14 1:43 PM, Makaraju, Maridi Raju (Raju) wrote: > >> On 10/24/14 11:26 AM, Makaraju, Maridi Raju (Raju) wrote: >>>>> Suppose the intent is to close one MSRP session and immediately open a >>>>>> new one. Is it permissible to simply update the SDP to describe the new >>>>>> MSRP session, reusing the channel number, without first doing an O/A to >>>>>> confirm the closure of the old one? >>>>> >>>>> The intent is not to reuse a datachannel (same or a different >> subprotocol) >>>>> before close. We will clarify that such a reuse is not supported. >>>>> The problem with such reuse is, previous datachannel MUST be reset >> before >>>>> it is used for new subprotocol, else the data from previous data channel >>>> use >>>>> will interfere with the new data channel use. >>>> >>>> My question is: Can I just close it in-band (with a reset) and then send >>>> an offer for the new usage of the channel? >>> >>> >>> No. To reuse a closed data channel, a new SDP offer/answer, to convey the >>> data channel closure (which excludes the corresponding a=dcmap and may >> include >>> other new data channels via new a=dcmaps), must be done. This can be done >> either >>> in a new offer initiated from this end or in an SDP answer this end >> generates. >>> The reason for this is to avoid various race conditions between SDP >> offer/answer >>> and SCTP reset arrival times. >>> Also, this is not a limiting thing as a new data channel can easily be >> created >>> using a new stream id, range is for which is large, without restarting >> underlying >>> SCTP/DTLS association. >> >> ISTM there is a useful analogy here to reusing m-lines. >> It once was thought that if you had been using an m-line for one thing >> (say an audio session), and then you wanted to stop that and start using >> that m-line for something else (say T38), you first had to send an offer >> setting the port to zero on the audio line, and then in a later offer >> you could then reuse that rejected m-line for T38. >> >> Eventually it was clarified that this was silly and unnecessary - that >> you could simply send a new offer replacing the audio m-line with a T38 >> m-line. > > > The above scenario is very well valid as there is no inband "SCTP Reset" equivalent > procedure exists for RTP/UDP based media. Please see my further explanation below; the > SCTP reset makes such a reuse problematic. I'll comment there. I don't think so. > Also, I think the new offer many times uses > a new transport address (at least the port), which makes such a reuse easy. It might, or not. > > >> >> So ISTM that here the following ought to be valid: >> >> 1) offer with dcmap for channel C, subprotocol C1, label C1 >> 2) use channel C, subprotocol C1 >> 3) send reset on channel C >> 4) offer with dcmap for channel C, subprotocol C2, label C2 >> 5) use channel C, subprotocol C2 > > > What if the "SCTP reset" from step3 above arrives at the peer after step4 SDP offer? > If DP arrives first then the data channel will later be closed when SCTP reset arrives, > which is not expected behavior. > There is no guarantee that reset arrives first. This is unless the local client waits for > data channel close indication (SCTP reset ack) from data channel stack and sends new SDP offer. The offerer won't send data based on the new offer until it has sent the reset, so there will be no ambiguity regarding data sent by the offerer. If the answerer wants to send data based on the new offer before it has received a reset, it can send a reset. Also, I'm a little fuzzy on how the SCTP reset works with channels. Is it necessary for each end to send a reset? If so, that makes it simpler. > The problem with depending on such "close indication" is: > - PeerConnection draft does not clearly say if and when it invokes onclose() callback on the > side which invokes close(). > Not sure if onclose() is called after SCTP reset is acknowledged or before?! Then they should fix it. > - Not sure if non-browser clients will have a way (API) to know when > SCTP reset is acknowledged. This depends on data channel stack implementation. Again, this may depend on whether reset must be sent independently in each direction. I suspect it must, since reset is an SCTP function and SCTP doesn't associate pairs of streams. Thanks, Paul > > >> >> The following also ought to be valid: >> >> 1) offer with dcmap for channel C, subprotocol C1, label C1 >> 2) use channel C, subprotocol C1 >> 3a) offer lacking channel C >> 3b) send reset on channel C >> 4) offer with dcmap for channel C, subprotocol C2, label C2 >> 5) use channel C, subprotocol C2 >> >> (I think the above is what you are advocating.) > > > Correct. It is valid, allowed and is what we are advocating. > > >> >> The following should *not* be valid: >> >> 1) offer with dcmap for channel C, subprotocol C1, label C1 >> 2) use channel C, subprotocol C1 >> 4) offer with different dcmap for channel C, subprotocol C2, label C2 >> 5) use channel C, subprotocol C2 > > > Correct. It is not valid. > In the first scenario above, this is how it looks like to the peer > if SCTP reset is not yet received at the time of this offer arrives. > > We planned on updating the draft-ejzak-mmusic-data-channel-sdpneg with the following: > 1. In a new SDP offer, if a=dcmap specifies same subprotocol and label as previous one > then the updated subprotocol attributes (in a=dcsa lines) are handled per the > subprotocol semantics. > > 2. In a new SDP offer, if a=dcmap specifies a different subprotocol and/or label than > the previous offer then the offer must be rejected entirely so that previous > SDP offer/answer is still valid. > > Appreciate your comments on this as well. > > > Thanks > Raju > From nobody Fri Oct 24 12:25:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2E31A1A38 for ; Fri, 24 Oct 2014 12:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gedfT_Ayy50F for ; Fri, 24 Oct 2014 12:24:57 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398C01A6F97 for ; Fri, 24 Oct 2014 12:24:56 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-71-544aa7861f32 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C2.A5.04081.687AA445; Fri, 24 Oct 2014 21:24:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 21:24:54 +0200 From: Christer Holmberg To: Jonathan Lennox Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQgAAFRoCAAH4RgP//uJeg Date: Fri, 24 Oct 2014 19:24:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> In-Reply-To: <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW7bcq8Qg48TpCz2Lz7PbDF1+WMW ByaPJUt+Mnm0PbvDHsAUxWWTkpqTWZZapG+XwJVx6glnwSuFink7rzA3MG6S6mLk5JAQMJG4 evomG4QtJnHh3nogm4tDSOAoo0TL6R9QzhJGiYs7vjJ2MXJwsAlYSHT/0wZpEBHQkLj47ANY M7OAjMSMs41MILawQLjEjIV32CFqIiTabv2Hst0kru06zAhiswioSsw//gUszivgK7Fw6zt2 iF3TmCSOrJ4BNohTwFaibet7ZhCbEei676fWMEEsE5e49WQ+E8TVAhJL9pxnhrBFJV4+/scK YStJNC55wgpRryOxYPcnqEO1JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUo WpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGD8Ht/w22MH48rnjIUYBDkYlHt4FmzxDhFgTy4or cw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4yrpH3OWbd1+7m7p23kx YR57bvMKVCnv+6I1M77SdrYu15Tlz0M52HbHKaxomL33wq2YC4ukTB81bI/pvcWx+vs2IWcl w49zvnY82L9hU2K7kK5Q+YtU3kpxBZGYNSXV01yMee4/Xly9MHtd/ySvxjvypVxXz7GFXf1i n3ltYZrUnkscvYU+z5RYijMSDbWYi4oTAfp569yAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ahM0L80EklOA4yfnaO3E_0Nsle4 Cc: mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 19:24:59 -0000 Hi, So, is the text I suggested ok, or do you want to write something else? If would be good if we could add the text to the bullet list in the RTP Con= siderations section. But, if you think it requires more text, we'll put it = somewhere else. Regards, Christer -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: 24 October 2014 21:38 To: Christer Holmberg Cc: mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lin= es, or not Right. The case my "twice the MSL" text is designed to handle is the case where an= SSRC leaves (sends RTCP bye), and then the sender spins up another SSRC on= a different mid, and happens to pick the same SSRC value. This shouldn't = happen very often (1 in 2^32) if SSRC randomization is implemented properly= , but sometimes people use bad random number generators (or are, e.g., play= ing games with not renumbering at a source projecting mixer). This isn't a= n SSRC collision, technically, since for the sender the old source is gone,= but if old packets with the old mid are still lingering in the network, yo= u'll get confused. Thus my recommendation to make sure you wait before you= reuse SSRC values. On Oct 24, 2014, at 12:07 PM, Christer Holmberg wrote: > ...and, obviously the SSRC would also always use the same MID in the RTCP= SDES MID item. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmb= erg > Sent: 24 October 2014 19:01 > To: Jonathan Lennox; mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > Hi Jonathan, >=20 > In the RTP Considerations section, we currently have the following text: >=20 > "A given SSRC MUST NOT transmit RTP packets using payload types that=20 > originate from different bundled "m=3D" lines." >=20 > That doesn't cover what you are talking about, but perhaps we could add a= statement saying something like: >=20 > "A given SSCR MUST NOT transmit RTP packets associated with different "m= =3D" lines. When > the RTP MID header extension is used, the SSRC MUST use the same 'mid' v= alue in every > RTP packet." >=20 > ...or something like that. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lenno= x > Sent: 24 October 2014 17:50 > To: mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > One issue which I've brought up a number of times in BUNDLE is whether it= 's valid for an RTP stream to move between bundled m-lines, or be shared be= tween several bundled m-lines. >=20 > While (as I've described) there are a number of useful features that this= could enable, it sounded at the last IETF meeting that people weren't inte= rested in the complexity it introduces. (It's certainly something that wou= ldn't be possible with unbundled m-lines.) As such, I think BUNDLE needs t= o document that this isn't allowed. >=20 > As such, I suggest adding to the section on MID something like: >=20 > RTP streams MUST NOT be moved between media descriptions. If a MID is co= mmunicated for an RTP stream, that stream's SSRC MUST NOT be reused for ano= ther RTP stream with a different MID value until at least twice the Maximum= Segment Lifetime (MSL) has elapsed since the last time a packet (RTP or RT= CP) was sent for the old stream. >=20 > This makes sure that stuck packets in the network can't confuse a stream'= s MID association. >=20 > If people *do* want the ability to move streams between m-lines, we will = need some more complicated rules, which I could try to draft if people are = interested. > _______________________________________________ > 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 nobody Fri Oct 24 12:28:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12281A0372 for ; Fri, 24 Oct 2014 12:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP70UG48eyYI for ; Fri, 24 Oct 2014 12:28:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197041A03A6 for ; Fri, 24 Oct 2014 12:28:27 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-7f-544aa85ac863 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.C5.04081.A58AA445; Fri, 24 Oct 2014 21:28:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 21:28:25 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits Thread-Index: Ac/u1r6MPHtnXAm3R8uZQhYrmpbrZAAApkLQACmq+IAACAD+cP//6gKA//+pd9A= Date: Fri, 24 Oct 2014 19:28:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C676E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C4243@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C633C@ESESSMB209.ericsson.se> <544A7B3F.3020000@alum.mit.edu> In-Reply-To: <544A7B3F.3020000@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW7UCq8Qg1M3RC2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj04M5bAXfRCrO3NjL1sB4U6CLkZNDQsBE 4urGXawQtpjEhXvr2UBsIYGjjBK7Fjl3MXIB2UsYJfb+usnexcjBwSZgIdH9TxukRkTAV+LZ 49tg9cICqRITbv1hhYinSbRves8IUi4i4Cdxf4ITSJhFQFXi2dlXTCA2L1Dr/F89jBDj9zJJ rNixHizBKaAjceP5aWYQmxHonu+n1oDFmQXEJW49mc8EcaeAxJI955khbFGJl4//Qd2vJNG4 5AkrRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYn 5aYbGemlFmUmFxfn5+nlpZZsYgRGycEtvw12ML587niIUYCDUYmHd8EmzxAh1sSy4srcQ4zS HCxK4rwLz80LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCo4C45IWSu/0LxH8c1gv0/vLV4 LDn7ovaN1gXPK/rv/F+iz+QyydmKLf7tRxUxKfbY2z/zOiONo/pvdEx9soCX//vq6w7u26OT D8ZL7n3uecpcx2evm9S7yNoXwlPd3pVa+yz8uYn93wqGeTcOMdXXP7SNUi4W4o/bdOENk+Se in6jIpm8feJKLMUZiYZazEXFiQB2iTP9cwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2Lm_zkIO3K7DYmRmhrlJc0f4g_Y Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 19:28:30 -0000 Hi, >>>>> Section 8.2.2. Request offerer BUNDLE address selection I can't=20 >>>>> parse that caption. >>>> >>>> Based on Paul's review, I suggest to change that to "Request the=20 >>>> offerer BUNDLE address". >>> [TS] I think this caption does exactly reflect semantics of what's=20 >>> going on in that paragraph. >>> >>> The offerer does not request a BUNDLE address, it is rather a suggestio= n. >>> What about "Suggesting the offerer BUNDLE address" >> >> We would have to go through the text and make sure it doesn't cause misa= ligned >> terminology. >> >> In addition, there is a section named "Request a new offerer BUNDLE addr= ess",=20 >> which we also would have to change. > > It seems that Thomas had the same problem with the title that I did, and = arrived at > the same proposed solution. > > So I'm in favor of making this change, and then touching up other text if= necessary. Well, I then kindly ask you to help me by checking the other text, to look = for possible impacts. I guess we'd at least have to change the name of the other section I mentio= ned, but we also need to check the text. Regards, Christer >>>> Section 8.5.3, 2nd bullet >>>> I could hardly parse this. >>>> o Place the SDP 'mid' attribute value associated with the "m=3D" l= ine >>>> in the SDP 'group:BUNDLE' attribute mid list associated with the >>>> BUNDLE group [Section 8.2.2]. >>>> I think it means that the list of identification-tags (mid-values)=20 >>>> in the group-attribute from the previous offer needs to be extended=20 >>>> with the identification-tag that is carried in the 'mid' attribute=20 >>>> of the additional m-line. Correct? >>> >>> Yes. >>> >>> I guess I could remove "associated with the BUNDLE group []", if it=20 >>> makes it more clear. >> [TS] That already helps, but what about: >> "Extend the SDP 'group:BUNDLE' attribute mid list with the additional SD= P 'mid' >> attribute value." > > I can do that, but I don't think we need both "Extend" and "additional". > > So, perhaps: > > "Extend the SDP 'group:BUNDLE' attribute mid list with the SDP 'mid' > attribute value associated with the "m=3D" line." > >> I still think that "mid list" and "mid attribute value " are unfortunate= terms though. > > We'll discuss that in the dedicated thread. > > Regards, > > Christer > > _______________________________________________ > 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 nobody Fri Oct 24 12:28:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B301A0372 for ; Fri, 24 Oct 2014 12:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP90klBbs74f for ; Fri, 24 Oct 2014 12:28:42 -0700 (PDT) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3C41A1A64 for ; Fri, 24 Oct 2014 12:28:42 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/24/2014 3:28:40 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 10/17/2014 9:19:05 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-118/SG:2 10/24/2014 3:28:32 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.762384 p=-0.982854 Source White X-Signature-Violations: 0-0-0-11267-c X-Note-419: 31.2667 ms. Fail:1 Chk:1329 of 1329 total X-Note: SCH-CT/SI:1-1329/SG:1 10/24/2014 3:28:37 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G230 G231 G232 G233 G237 G238 G350 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTP id 21866324; Fri, 24 Oct 2014 15:28:40 -0400 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id s9OJPirG027778; Fri, 24 Oct 2014 15:28:40 -0400 Received: from mail.vidyo.com (mail1.vidyo.com [162.209.16.213]) by mx0b-00198e01.pphosted.com with ESMTP id 1q76vk0fn2-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 24 Oct 2014 15:28:40 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 14:28:39 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQgAAFRoCAAH4RgP//uJeggABVgQA= Date: Fri, 24 Oct 2014 19:28:38 +0000 Message-ID: <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.17.94.228] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9F67A0D7B84E0A409CBCAA963A981486@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-24_06:2014-10-24,2014-10-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410240162 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aAWh_MjB9QzWXuvleyMcsoCOwws Cc: mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 19:28:46 -0000 My worry is that your text (as modified to include RTCP), interpreted liter= ally, would be too constraining for very-long-lived sessions, where you mig= ht have used an SSRC on one m-line three weeks ago, and now you need to rem= ember it forever so you don=92t reuse that same value on a different one.=20 On Oct 24, 2014, at 3:24 PM, Christer Holmberg wrote: > Hi, >=20 > So, is the text I suggested ok, or do you want to write something else? >=20 > If would be good if we could add the text to the bullet list in the RTP C= onsiderations section. But, if you think it requires more text, we'll put i= t somewhere else. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 > Sent: 24 October 2014 21:38 > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > Right. >=20 > The case my "twice the MSL" text is designed to handle is the case where = an SSRC leaves (sends RTCP bye), and then the sender spins up another SSRC = on a different mid, and happens to pick the same SSRC value. This shouldn'= t happen very often (1 in 2^32) if SSRC randomization is implemented proper= ly, but sometimes people use bad random number generators (or are, e.g., pl= aying games with not renumbering at a source projecting mixer). This isn't= an SSRC collision, technically, since for the sender the old source is gon= e, but if old packets with the old mid are still lingering in the network, = you'll get confused. Thus my recommendation to make sure you wait before y= ou reuse SSRC values. >=20 > On Oct 24, 2014, at 12:07 PM, Christer Holmberg wrote: >=20 >> ...and, obviously the SSRC would also always use the same MID in the RTC= P SDES MID item. >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holm= berg >> Sent: 24 October 2014 19:01 >> To: Jonathan Lennox; mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-= lines, or not >>=20 >> Hi Jonathan, >>=20 >> In the RTP Considerations section, we currently have the following text: >>=20 >> "A given SSRC MUST NOT transmit RTP packets using payload types that=20 >> originate from different bundled "m=3D" lines." >>=20 >> That doesn't cover what you are talking about, but perhaps we could add = a statement saying something like: >>=20 >> "A given SSCR MUST NOT transmit RTP packets associated with different "= m=3D" lines. When >> the RTP MID header extension is used, the SSRC MUST use the same 'mid' = value in every >> RTP packet." >>=20 >> ...or something like that. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lenn= ox >> Sent: 24 October 2014 17:50 >> To: mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-= lines, or not >>=20 >> One issue which I've brought up a number of times in BUNDLE is whether i= t's valid for an RTP stream to move between bundled m-lines, or be shared b= etween several bundled m-lines. >>=20 >> While (as I've described) there are a number of useful features that thi= s could enable, it sounded at the last IETF meeting that people weren't int= erested in the complexity it introduces. (It's certainly something that wo= uldn't be possible with unbundled m-lines.) As such, I think BUNDLE needs = to document that this isn't allowed. >>=20 >> As such, I suggest adding to the section on MID something like: >>=20 >> RTP streams MUST NOT be moved between media descriptions. If a MID is c= ommunicated for an RTP stream, that stream's SSRC MUST NOT be reused for an= other RTP stream with a different MID value until at least twice the Maximu= m Segment Lifetime (MSL) has elapsed since the last time a packet (RTP or R= TCP) was sent for the old stream. >>=20 >> This makes sure that stuck packets in the network can't confuse a stream= 's MID association. >>=20 >> If people *do* want the ability to move streams between m-lines, we will= need some more complicated rules, which I could try to draft if people are= interested. >> _______________________________________________ >> 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 From nobody Fri Oct 24 12:36:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A081A893E for ; Fri, 24 Oct 2014 12:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiAYHhajbGGq for ; Fri, 24 Oct 2014 12:36:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3EE51A8701 for ; Fri, 24 Oct 2014 12:36:30 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-13-544aaa3c6d2e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.16.04081.C3AAA445; Fri, 24 Oct 2014 21:36:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 21:36:28 +0200 From: Christer Holmberg To: Jonathan Lennox Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQgAAFRoCAAH4RgP//uJeggABVgQD//6y0sA== Date: Fri, 24 Oct 2014 19:36:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> In-Reply-To: <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvja7tKq8Qg0dNbBb7F59ntpi6/DGL A5PHkiU/mTzant1hD2CK4rJJSc3JLEst0rdL4Mpom/iPqeC7ZsXMnYuYGhifK3YxcnJICJhI bJwxkwnCFpO4cG89WxcjF4eQwFFGiZ3TjzBBOEuAnI0zmLsYOTjYBCwkuv9pgzSICGhIXHz2 gQ3EZhaQkZhxthFskLBAuMSMhXfYIWoiJNpu/YeywyROnPvKCmKzCKhKHJ7dBNbLK+Arca91 AgvErl5miTdT14I1cArYSuz5dJQZxGYEuu77qTVMEMvEJW49mQ91tYDEkj3nmSFsUYmXj/+x QthKEo1LnrBC1OtILNj9CepQbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYx ihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbQwS2/DXYwvnzueIhRgINRiYd3wSbPECHWxLLi ytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwJj85NK6+ut7N6odmNu3 89Hl5I9PFYy8Li9Q2/DD0+N335qrteY+PNu/3JJ9UmAnP/vUjHBPYx6+v+b73l38Z/CW7900 jqdbdK6JLeJ+vnjndAFxxsUOMvkPLV064tr11pnb1MX/vmVxN95ybzXzH/t9LY03XxnNc4+a r2I9f/rUyXnfczYlOu9SYinOSDTUYi4qTgQAVrt8RIECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/n6hqqHs2xNvvCplO10sXMHN3MhE Cc: mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 19:36:33 -0000 Hi, What about: "A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets associ= ated with different "m=3D" lines. There needs to be a time period, long eno= ugh to make sure there are no packets associate with the previous "m=3D" li= ne in the network, before the SSRC starts to transmit RTP/RTCP packets asso= ciated with a new "m=3D" line." Regards, Christer -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 Sent: 24 October 2014 22:29 To: Christer Holmberg Cc: mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lin= es, or not My worry is that your text (as modified to include RTCP), interpreted liter= ally, would be too constraining for very-long-lived sessions, where you mig= ht have used an SSRC on one m-line three weeks ago, and now you need to rem= ember it forever so you don't reuse that same value on a different one.=20 On Oct 24, 2014, at 3:24 PM, Christer Holmberg wrote: > Hi, >=20 > So, is the text I suggested ok, or do you want to write something else? >=20 > If would be good if we could add the text to the bullet list in the RTP C= onsiderations section. But, if you think it requires more text, we'll put i= t somewhere else. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 > Sent: 24 October 2014 21:38 > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > Right. >=20 > The case my "twice the MSL" text is designed to handle is the case where = an SSRC leaves (sends RTCP bye), and then the sender spins up another SSRC = on a different mid, and happens to pick the same SSRC value. This shouldn'= t happen very often (1 in 2^32) if SSRC randomization is implemented proper= ly, but sometimes people use bad random number generators (or are, e.g., pl= aying games with not renumbering at a source projecting mixer). This isn't= an SSRC collision, technically, since for the sender the old source is gon= e, but if old packets with the old mid are still lingering in the network, = you'll get confused. Thus my recommendation to make sure you wait before y= ou reuse SSRC values. >=20 > On Oct 24, 2014, at 12:07 PM, Christer Holmberg wrote: >=20 >> ...and, obviously the SSRC would also always use the same MID in the RTC= P SDES MID item. >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holm= berg >> Sent: 24 October 2014 19:01 >> To: Jonathan Lennox; mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-= lines, or not >>=20 >> Hi Jonathan, >>=20 >> In the RTP Considerations section, we currently have the following text: >>=20 >> "A given SSRC MUST NOT transmit RTP packets using payload types that=20 >> originate from different bundled "m=3D" lines." >>=20 >> That doesn't cover what you are talking about, but perhaps we could add = a statement saying something like: >>=20 >> "A given SSCR MUST NOT transmit RTP packets associated with different "= m=3D" lines. When >> the RTP MID header extension is used, the SSRC MUST use the same 'mid' = value in every >> RTP packet." >>=20 >> ...or something like that. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lenn= ox >> Sent: 24 October 2014 17:50 >> To: mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-= lines, or not >>=20 >> One issue which I've brought up a number of times in BUNDLE is whether i= t's valid for an RTP stream to move between bundled m-lines, or be shared b= etween several bundled m-lines. >>=20 >> While (as I've described) there are a number of useful features that thi= s could enable, it sounded at the last IETF meeting that people weren't int= erested in the complexity it introduces. (It's certainly something that wo= uldn't be possible with unbundled m-lines.) As such, I think BUNDLE needs = to document that this isn't allowed. >>=20 >> As such, I suggest adding to the section on MID something like: >>=20 >> RTP streams MUST NOT be moved between media descriptions. If a MID is c= ommunicated for an RTP stream, that stream's SSRC MUST NOT be reused for an= other RTP stream with a different MID value until at least twice the Maximu= m Segment Lifetime (MSL) has elapsed since the last time a packet (RTP or R= TCP) was sent for the old stream. >>=20 >> This makes sure that stuck packets in the network can't confuse a stream= 's MID association. >>=20 >> If people *do* want the ability to move streams between m-lines, we will= need some more complicated rules, which I could try to draft if people are= interested. >> _______________________________________________ >> 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 From nobody Fri Oct 24 13:03:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B05E1A1B21 for ; Fri, 24 Oct 2014 13:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHVGmE28gvud for ; Fri, 24 Oct 2014 13:03:02 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300061A0248 for ; Fri, 24 Oct 2014 13:03:01 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 562586D7D28F9; Fri, 24 Oct 2014 20:02:58 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s9OK302L005695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 16:03:00 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 16:03:00 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: AQHP7t66dy5ZGL+nPEG/1c9gL4hdCZw+EJjQgABWxQCAAPUTgIAAWcEA//+91kCAAG4IAP//wSjw Date: Fri, 24 Oct 2014 20:02:59 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> <544966CE.2080709@alum.mit.edu> <544A7FAE.1070206@alum.mit.edu> <544AA47A.9090303@alum.mit.edu> In-Reply-To: <544AA47A.9090303@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/_V5SorWXF3Y8xko_852xE75M_nk Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 24 Oct 2014 20:03:05 -0000 > >> So ISTM that here the following ought to be valid: > >> > >> 1) offer with dcmap for channel C, subprotocol C1, label C1 > >> 2) use channel C, subprotocol C1 > >> 3) send reset on channel C > >> 4) offer with dcmap for channel C, subprotocol C2, label C2 > >> 5) use channel C, subprotocol C2 > > > > > > What if the "SCTP reset" from step3 above arrives at the peer after ste= p4 > SDP offer? > > If DP arrives first then the data channel will later be closed when SCT= P > reset arrives, > > which is not expected behavior. > > There is no guarantee that reset arrives first. This is unless the loca= l > client waits for > > data channel close indication (SCTP reset ack) from data channel stack = and > sends new SDP offer. >=20 > The offerer won't send data based on the new offer until it has sent the > reset, so there will be no ambiguity regarding data sent by the offerer. > If the answerer wants to send data based on the new offer before it has > received a reset, it can send a reset. I also don't see any ambiguity wrt sending new data on either side. The issue is what happens if the SDP offer arrives before SCTP reset? Per comment below you seem to indicate that a new SDP offer which reuses closed stream MUST happen only after SCTP reset seq is acknowledged. >=20 > Also, I'm a little fuzzy on how the SCTP reset works with channels. Is > it necessary for each end to send a reset? If so, that makes it simpler. You are right on the SCTP resets. https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.7 s= ays both=20 incoming and outgoing streams are reset. >=20 > > The problem with depending on such "close indication" is: > > - PeerConnection draft does not clearly say if and when it invokes > onclose() callback on the > > side which invokes close(). > > Not sure if onclose() is called after SCTP reset is acknowledged or > before?! >=20 > Then they should fix it. I checked http://w3c.github.io/webrtc-pc/#data-transport-closed=20 It seems to indicate that if close() is called by client then onclose() won= 't be called. " An RTCDataChannel object's underlying data transport may be torn down in = a non-abrupt manner by running the closing procedure. When that happens the= user agent must, unless the procedure was initiated by the close() method,= queue a task that sets the object's readyState attribute to closing. This = will eventually render the data transport closed." I can discuss with w3c to "trigger onclose() for close() case as well and o= nly when=20 both SCTP incoming/outgoing streams are reset". >=20 > > - Not sure if non-browser clients will have a way (API) to know when > > SCTP reset is acknowledged. This depends on data channel stack > implementation. >=20 > Again, this may depend on whether reset must be sent independently in > each direction. I suspect it must, since reset is an SCTP function and > SCTP doesn't associate pairs of streams. non-browser data channel stack implementations must also inform the applica= tion only when SCTP streams are reset in both the directions. If such notificati= on is available then a new SDP offer can be initiated to reuse a closed stream= . We can update the drafts to indicate a stream can only be reused after SCTP= resets are done in both the directions. If a data channel stack implementation (in= cluding browsers) does not have such an API to inform the client then it can't reuse the stre= ams without an additional SDP offer/answer to close it first. Thanks Raju From nobody Sat Oct 25 06:56:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB111A0015 for ; Sat, 25 Oct 2014 06:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VfutCaUgCvM for ; Sat, 25 Oct 2014 06:56:55 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195851A0011 for ; Sat, 25 Oct 2014 06:56:55 -0700 (PDT) Received: from [81.187.2.149] (port=34430 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xi1pr-0000DK-0p; Sat, 25 Oct 2014 14:56:53 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> Date: Sat, 25 Oct 2014 14:56:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UAxz0MmjeU8XwkaalqP5KCsrwjc Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 13:56:57 -0000 Hi, I suggest that the timeout period be 5 times the RTCP reporting = interval. This is the SSRC timeout interval defined in RFC 3550 section = 6.3.5, and is how long a receiver will consider an SSRC valid if that = SSRC stops sending and it=92s RTCP BYE is lost. Colin On 24 Oct 2014, at 20:36, Christer Holmberg = wrote: > Hi, >=20 > What about: >=20 > "A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets = associated with different "m=3D" lines. There needs to be a time period, = long enough to make sure there are no packets associate with the = previous "m=3D" line in the network, before the SSRC starts to transmit = RTP/RTCP packets associated with a new "m=3D" line." >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 > Sent: 24 October 2014 22:29 > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >=20 > My worry is that your text (as modified to include RTCP), interpreted = literally, would be too constraining for very-long-lived sessions, where = you might have used an SSRC on one m-line three weeks ago, and now you = need to remember it forever so you don't reuse that same value on a = different one.=20 >=20 > On Oct 24, 2014, at 3:24 PM, Christer Holmberg = wrote: >=20 >> Hi, >>=20 >> So, is the text I suggested ok, or do you want to write something = else? >>=20 >> If would be good if we could add the text to the bullet list in the = RTP Considerations section. But, if you think it requires more text, = we'll put it somewhere else. >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >> Sent: 24 October 2014 21:38 >> To: Christer Holmberg >> Cc: mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >>=20 >> Right. >>=20 >> The case my "twice the MSL" text is designed to handle is the case = where an SSRC leaves (sends RTCP bye), and then the sender spins up = another SSRC on a different mid, and happens to pick the same SSRC = value. This shouldn't happen very often (1 in 2^32) if SSRC = randomization is implemented properly, but sometimes people use bad = random number generators (or are, e.g., playing games with not = renumbering at a source projecting mixer). This isn't an SSRC = collision, technically, since for the sender the old source is gone, but = if old packets with the old mid are still lingering in the network, = you'll get confused. Thus my recommendation to make sure you wait = before you reuse SSRC values. >>=20 >> On Oct 24, 2014, at 12:07 PM, Christer Holmberg = wrote: >>=20 >>> ...and, obviously the SSRC would also always use the same MID in the = RTCP SDES MID item. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer = Holmberg >>> Sent: 24 October 2014 19:01 >>> To: Jonathan Lennox; mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>=20 >>> Hi Jonathan, >>>=20 >>> In the RTP Considerations section, we currently have the following = text: >>>=20 >>> "A given SSRC MUST NOT transmit RTP packets using payload types = that=20 >>> originate from different bundled "m=3D" lines." >>>=20 >>> That doesn't cover what you are talking about, but perhaps we could = add a statement saying something like: >>>=20 >>> "A given SSCR MUST NOT transmit RTP packets associated with = different "m=3D" lines. When >>> the RTP MID header extension is used, the SSRC MUST use the same = 'mid' value in every >>> RTP packet." >>>=20 >>> ...or something like that. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan = Lennox >>> Sent: 24 October 2014 17:50 >>> To: mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>=20 >>> One issue which I've brought up a number of times in BUNDLE is = whether it's valid for an RTP stream to move between bundled m-lines, or = be shared between several bundled m-lines. >>>=20 >>> While (as I've described) there are a number of useful features that = this could enable, it sounded at the last IETF meeting that people = weren't interested in the complexity it introduces. (It's certainly = something that wouldn't be possible with unbundled m-lines.) As such, I = think BUNDLE needs to document that this isn't allowed. >>>=20 >>> As such, I suggest adding to the section on MID something like: >>>=20 >>> RTP streams MUST NOT be moved between media descriptions. If a MID = is communicated for an RTP stream, that stream's SSRC MUST NOT be reused = for another RTP stream with a different MID value until at least twice = the Maximum Segment Lifetime (MSL) has elapsed since the last time a = packet (RTP or RTCP) was sent for the old stream. >>>=20 >>> This makes sure that stuck packets in the network can't confuse a = stream's MID association. >>>=20 >>> If people *do* want the ability to move streams between m-lines, we = will need some more complicated rules, which I could try to draft if = people are interested. >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ From nobody Sat Oct 25 07:28:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1691A0035 for ; Sat, 25 Oct 2014 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5t1ty-aTQSe for ; Sat, 25 Oct 2014 07:28:39 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A508D1A002F for ; Sat, 25 Oct 2014 07:28:38 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-c9-544bb394cc4e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1D.48.24955.493BB445; Sat, 25 Oct 2014 16:28:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 16:28:35 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQgAAFRoCAAH4RgP//uJeggABVgQD//6y0sIABE4MAgAAn96A= Date: Sat, 25 Oct 2014 14:28:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C8201@ESESSMB209.ericsson.se> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> 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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje6Uzd4hBpN/a1gsf3mC0WL/4vPM FlOXP2ZxYPaYdv8+m8eSJT+ZPNqe3WEPYI7isklJzcksSy3St0vgytiwZDpbwQvTign31rM3 MO7R7mLk5JAQMJFYvmweI4QtJnHh3nq2LkYuDiGBo4wSKxqPsUA4SxglNk44CuRwcLAJWEh0 /wNrFhFQldhx/B9YM7OAk8SfnfeYQGxhgXCJGQvvsEPUREi03foPZSdJXGl+DlbDAtS78NMh VhCbV8BXovdkB9TiDhaJfS9XgTVwCjhKdE6/DmYzAl33/dQaJohl4hK3nsxngrhaQGLJnvPM ELaoxMvH/1ghbCWJFdsvQR2nI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTMQtIy C0nLAkaWVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBUXVwy2/VHYyX3zgeYhTgYFTi4VVg 8Q4RYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MDU6q6h/P v3rxjIl9m35PqfOz2ELeFR5mZ1Y9ddY/zXHa1uWM5AxpZ2lWtyT+4IUXVkzLKbznpdpksTfH 5svqOR1Bk9nC0hUlj8S2XMoM5VVamcsYrWCzTP+/VvTMPl6RWL+rAk+NjK79WW8SxH7ZRejP 38AqG9UHM2O+l1o979us7Lb2Z5oSS3FGoqEWc1FxIgBhm1fNiwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DZS1nnHX-jvTWTsd1BjbvhFFH5c Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 14:28:42 -0000 Hi Colin, Thanks for your input. So, perhaps something like: A given SSRC MUST, at any given time, only transmit RTP/RTCP packets associ= ated with a single "m=3D" line. If the SSRC wants to switch "m=3D" line, th= ere MUST be a timeout interval of 5 times the RTCP reporting interval befor= e the SSRC starts to transmit RTP/RTCP packets associated with the new "m= =3D" line, as that will ensure that any remaining packets associated with t= he previous "m=3D" line will be considered invalid [RFC3550]." Regards, Christer -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: 25 October 2014 16:57 To: Christer Holmberg Cc: Jonathan Lennox; mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lin= es, or not Hi, I suggest that the timeout period be 5 times the RTCP reporting interval. T= his is the SSRC timeout interval defined in RFC 3550 section 6.3.5, and is = how long a receiver will consider an SSRC valid if that SSRC stops sending = and it's RTCP BYE is lost. Colin On 24 Oct 2014, at 20:36, Christer Holmberg wrote: > Hi, >=20 > What about: >=20 > "A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets asso= ciated with different "m=3D" lines. There needs to be a time period, long e= nough to make sure there are no packets associate with the previous "m=3D" = line in the network, before the SSRC starts to transmit RTP/RTCP packets as= sociated with a new "m=3D" line." >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 > Sent: 24 October 2014 22:29 > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > My worry is that your text (as modified to include RTCP), interpreted lit= erally, would be too constraining for very-long-lived sessions, where you m= ight have used an SSRC on one m-line three weeks ago, and now you need to r= emember it forever so you don't reuse that same value on a different one.=20 >=20 > On Oct 24, 2014, at 3:24 PM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> So, is the text I suggested ok, or do you want to write something else? >>=20 >> If would be good if we could add the text to the bullet list in the RTP = Considerations section. But, if you think it requires more text, we'll put = it somewhere else. >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >> Sent: 24 October 2014 21:38 >> To: Christer Holmberg >> Cc: mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-= lines, or not >>=20 >> Right. >>=20 >> The case my "twice the MSL" text is designed to handle is the case where= an SSRC leaves (sends RTCP bye), and then the sender spins up another SSRC= on a different mid, and happens to pick the same SSRC value. This shouldn= 't happen very often (1 in 2^32) if SSRC randomization is implemented prope= rly, but sometimes people use bad random number generators (or are, e.g., p= laying games with not renumbering at a source projecting mixer). This isn'= t an SSRC collision, technically, since for the sender the old source is go= ne, but if old packets with the old mid are still lingering in the network,= you'll get confused. Thus my recommendation to make sure you wait before = you reuse SSRC values. >>=20 >> On Oct 24, 2014, at 12:07 PM, Christer Holmberg wrote: >>=20 >>> ...and, obviously the SSRC would also always use the same MID in the RT= CP SDES MID item. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Hol= mberg >>> Sent: 24 October 2014 19:01 >>> To: Jonathan Lennox; mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m= -lines, or not >>>=20 >>> Hi Jonathan, >>>=20 >>> In the RTP Considerations section, we currently have the following text= : >>>=20 >>> "A given SSRC MUST NOT transmit RTP packets using payload types that=20 >>> originate from different bundled "m=3D" lines." >>>=20 >>> That doesn't cover what you are talking about, but perhaps we could add= a statement saying something like: >>>=20 >>> "A given SSCR MUST NOT transmit RTP packets associated with different = "m=3D" lines. When >>> the RTP MID header extension is used, the SSRC MUST use the same 'mid'= value in every >>> RTP packet." >>>=20 >>> ...or something like that. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Len= nox >>> Sent: 24 October 2014 17:50 >>> To: mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m= -lines, or not >>>=20 >>> One issue which I've brought up a number of times in BUNDLE is whether = it's valid for an RTP stream to move between bundled m-lines, or be shared = between several bundled m-lines. >>>=20 >>> While (as I've described) there are a number of useful features that th= is could enable, it sounded at the last IETF meeting that people weren't in= terested in the complexity it introduces. (It's certainly something that w= ouldn't be possible with unbundled m-lines.) As such, I think BUNDLE needs= to document that this isn't allowed. >>>=20 >>> As such, I suggest adding to the section on MID something like: >>>=20 >>> RTP streams MUST NOT be moved between media descriptions. If a MID is = communicated for an RTP stream, that stream's SSRC MUST NOT be reused for a= nother RTP stream with a different MID value until at least twice the Maxim= um Segment Lifetime (MSL) has elapsed since the last time a packet (RTP or = RTCP) was sent for the old stream. >>>=20 >>> This makes sure that stuck packets in the network can't confuse a strea= m's MID association. >>>=20 >>> If people *do* want the ability to move streams between m-lines, we wil= l need some more complicated rules, which I could try to draft if people ar= e interested. >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ From nobody Sat Oct 25 07:31:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188D41A004E for ; Sat, 25 Oct 2014 07:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjrACqBADcIv for ; Sat, 25 Oct 2014 07:31:32 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF771A0040 for ; Sat, 25 Oct 2014 07:31:31 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-b2-544bb441b172 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.78.24955.144BB445; Sat, 25 Oct 2014 16:31:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 16:31:29 +0200 From: Christer Holmberg To: "Stach, Thomas" , "pkyzivat@alum.mit.edu" Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology Thread-Index: Ac/u1sSmOrC76dpuRG2RzgUhUCSTWAACEKxAACg8ywAAOBE3oA== Date: Sat, 25 Oct 2014 14:31:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C8236@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C429D@ESESSMB209.ericsson.se> 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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4C8236ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvja7TFu8Qg1fdbBZTlz9msVix4QCr xcmd25gdmD3+vv/A5LFkyU8mj+09j1kCmKO4bFJSczLLUov07RK4MpoubWcreNHLWPFhx3X2 BsZ3NV2MnBwSAiYS/64eYoKwxSQu3FvP1sXIxSEkcJRR4vDUpawQzhJGicmPW4AcDg42AQuJ 7n/aIA0iAvESM08tYgexmQXkJDZMfskGYgsLREr8f3mXCaImSqL1dDM7SKuIgJPE1C4TkDCL gKrEkgObwcp5BXwlDt+5xA6x6jqjxOdNHSwgCU4Bf4k9/+eD2YxAx30/tYYJYpe4xK0n86GO FpBYsuc8M4QtKvHy8T9WCFtJYsX2S4wQ9fkSXW3TWCCWCUqcnPmEZQKj6Cwko2YhKZuFpAwi riOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiM woNbfqvuYLz8xvEQowAHoxIPrwKLd4gQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamA0+qt+7cvDQodrbGJGyZ2nBTtKVvfMUDFqV8xg4E0t3vFC8lvfzL9n Stp15AVOrbqU4doQrj5b+EHsgsaG9PBZnNvcTaPMH8XsXLx1yqOoBqOW9TVnLHeWyv93XNRa 83l2PbvB1+ul7GsPPylcGN1avJKBfaNn47oPu6PVHlpFHXc6zC9WZ6zEUpyRaKjFXFScCAA3 Y1EcowIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/y1sj6d5-6NdCeiaYa0aID5EFlAs Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 14:31:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4C8236ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd like to hear Paul's opinions on this, because he is the one who suggest= ed the current terminology. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 24 October 2014 16:45 To: Christer Holmberg Cc: 'mmusic' Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 -= Terminology Hi, There has been many long discussions in order to come up with the terminolo= gy. [TS] I know that much effort was already put into that. Also, considering the number of editorial re-structures that have already taken p= lace, and the impact this would have on the document, I would suggest to NO= T do the change. [TS] I understand that there is not much appetite for putting more editoria= l work into the document. Nevertheless, I still think that understanding the text is still unnecessar= ily cumbersome, which in turn could lead to unnecessary misinterpretations during implement= ation. But maybe it is just me, who has this problem, in which case I probably jus= t have to improve my reading skills. ;-) But, if you think the existing definitions can be clarified, we can discuss= that. [TS] Well, considering reuse of the RFC5888 terminology might be still wort= hwhile. That would e.g. include replacing "mid attribute value" with "identificati= on-tag", etc. Regards, Christer From: Stach, Thomas [mailto:thomas.stach@unify.com] Sent: 23 October 2014 18:34 To: Christer Holmberg Cc: 'mmusic' Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Ter= minology All Terminology Offerer suggested BUNDLE mid: The first mid value in a given SDP 'group:BUNDLE' attribute mid list in an offer. and Answerer selected BUNDLE mid: The first mid value in a given SDP 'group:BUNDLE' attribute mid list in an answer. These terms are not very intuitive and make the reading the related text qu= ite cumbersome. Since you are talking about the identification-tags from RFC5888 group-attribute =3D "a=3Dgroup:" semantics *(SP identification-tag) mid-attribute =3D "a=3Dmid:" identification-tag may I suggest re-using that terminology and propose using a single, more pr= egnant term for both together with additional explanation? E.g. BUNDLE-tag: The first element in the list of identification-tags of a 'group:' attribute [RFC5888] with BUNDLE semantics. This tag has special significance in that it identifies the m-line that carries the suggested or selected BUNDLE addres= s. The corresponding m-line will carry the same tag in a 'mid' att= ribute. The offerer suggests a BUNDLE tag. The answerer preferably acce= pts the suggested BUNDLE-tag, but could select a different BUNDLE-tag, if necessary. Example: If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'foo' would be= the BUNDLE-tag and 'a=3Dmid:foo' the m-line with the BUNDLE address= . If there is appetite for changing that terminology, I understand that it wo= uld cause quite a few other editorial changes in the remainder of the document. In order to not delay progress of the draft, I can only offer to help in an= y editorial effort and would be happy to propose changed text. Regards Thomas --_000_7594FB04B1934943A5C02806D1A2204B1D4C8236ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’d like to hear Paul’s opinions on this, because he is th= e one who suggested the current terminology.

 

Regards,

 

Christer

 

From: Stach, Thomas [mailto:thomas.stach@unify.com]
Sent: 24 October 2014 16:45
To: Christer Holmberg
Cc: 'mmusic'
Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiati= on-12 - Terminology

 

 

Hi,<= /p>

 

There has been many lo= ng discussions in order to come up with the terminology.

[TS] I know that= much effort was already put into that.

 

Also,

considering the number= of editorial re-structures that have already taken place, and the impact t= his would have on the document, I would suggest to NOT do the change.<= /o:p>

[TS] I understan= d that there is not much appetite for putting more editorial work into the = document.

Nevertheless, I = still think that understanding the text is still unnecessarily cumbersome, =  

which in turn co= uld lead to unnecessary misinterpretations during implementation.

But maybe it is = just me, who has this problem, in which case I probably just have to  = improve my reading skills.  ;-)

But, if you think the = existing definitions can be clarified, we can discuss that.

[TS] Well, consi= dering reuse of the RFC5888 terminology might be still worthwhile.

That would e.g. = include replacing  “mid attribute value” with “ident= ification-tag”, etc.

 

Regards,

 

Christer

 

From: Stach, Thomas [mailto= :thomas.stach@unify.com]
Sent: 23 October 2014 18:34
To: Christer Holmberg
Cc: 'mmusic'
Subject: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-1= 2 - Terminology

 

All

 

Terminology

 

   Offerer suggested BUNDLE mid: = The first mid value in a given SDP

   'group:BUNDLE' attribute mid l= ist in an offer.

and

   Answerer selected BUNDLE = mid: The first mid value in a given SDP

   'group:BUNDLE' attribute mid l= ist in an answer.

 

These terms are not very intuit= ive and make the reading the related text quite cumbersome.

Since you are talking about the= identification-tags from RFC5888

group-attribute =3D "a=3Dgroup:" = semantics *(SP identification-tag)

mid-attribute   =3D "a=3Dmid:"=
; identification-tag

may I suggest re-using that ter= minology and propose using a single, more pregnant term for both

together with additional explan= ation?

E.g.

 

BUNDLE-tag: The first element in the list o= f identification-tags of

       &= nbsp;    a 'group:' attribute [RFC5888] with BUNDLE sem= antics.

       &= nbsp;    This tag has special significance in that it i= dentifies

       &= nbsp;    the m-line that carries the suggested or selec= ted BUNDLE address.

       &= nbsp;    The corresponding m-line will carry the same t= ag in a 'mid' attribute.

       &= nbsp;    The offerer suggests a BUNDLE tag. The answere= r preferably accepts

       &= nbsp;    the suggested BUNDLE-tag, but could select a d= ifferent

       &= nbsp;    BUNDLE-tag, if necessary.

       &= nbsp;    Example:

       &= nbsp;    If we have e.g. 'a=3Dgroup:BUNDLE foo bar', then 'f= oo' would be the

       &= nbsp;    BUNDLE-tag and 'a=3Dmid:foo' the m-line with t= he BUNDLE address.

 

If there is appetite for changi= ng that terminology, I understand that it would cause quite a few

other editorial changes in the = remainder of the document.

In order to not delay progress = of the draft, I can only offer to help in any editorial effort and would be= happy to propose changed text.

 

Regards

Thomas

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D4C8236ESESSMB209erics_-- From nobody Sat Oct 25 07:33:54 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63F31A0039 for ; Sat, 25 Oct 2014 07:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIl1bqPMoKug for ; Sat, 25 Oct 2014 07:33:50 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381C81A0010 for ; Sat, 25 Oct 2014 07:33:50 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-28-544bb4cb23d2 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.8A.04387.BC4BB445; Sat, 25 Oct 2014 16:33:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 16:33:47 +0200 From: Christer Holmberg To: "Hutton, Andrew" , =?utf-8?B?QXJpIEtlcsOkbmVu?= , Eric Rescorla , Jonathan Lennox Thread-Topic: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] Thread-Index: AQHP75AvWIZdbW4BM02mid9bX9HbEJxA4iAg Date: Sat, 25 Oct 2014 14:33:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C826E@ESESSMB209.ericsson.se> References: <543CDB90.7050509@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D4810A8@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1D481271@ESESSMB209.ericsson.se> <544893BD.2030706@cisco.com> <959D853E-7890-4A19-8E24-43FEF51B523E@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF1E5D3FB7@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E5D3FB7@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3RvfMFu8QgxZri20bSi1WvD7HbvH+ gq7F/sXnmS2mLn/M4sDqMeX3RlaPJUt+MnlMftzG7LG95zGLR9uzO+wBrFFcNimpOZllqUX6 dglcGTv2vGEumGNasfTCDvYGxjfGXYycHBICJhJbpi1khLDFJC7cW8/WxcjFISRwlFHiSdMl ZghnCaPEsj3HmboYOTjYBCwkuv9pgzSICKxnlLi/3xXEZhZwlVh0ZSvYIGGBJImzBw+wQNQk SzxaeIMNwjaS2HNnL1gNi4CqxJ2Xn5hAbF4BX4mrK8+wQ+y6wSxx6/ZXdpAEp4C/xNY5U8GK GIGu+35qDRPEMnGJW0/mM0FcLSCxZM95ZghbVOLl43+sELaSxIrtlxhBbmYW0JRYv0sfolVR Ykr3Q3aIvYISJ2c+YZnAKDYLydRZCB2zkHTMQtKxgJFlFaNocWpxcW66kZFealFmcnFxfp5e XmrJJkZgzB3c8ttqB+PB546HGAU4GJV4eBVYvEOEWBPLiitzDzFKc7AoifMuPDcvWEggPbEk NTs1tSC1KL6oNCe1+BAjEwenVAPj/EOsBzkenpGJujT1QKvThTg13yVN53gt+fsOFH28z2Ia OsfNlbvf+aBHg2XaPuu+yYWJNZHzjhfmMW59uNyHgz2v/d7TX6GH1bP3cCiu+3nhst2F2419 J+647jr87mf+ka826lnfmHKS157/+2DmqQL9gD7N+St9P+5Y1FUaPDFXIcq2zLhAiaU4I9FQ i7moOBEASj5zF5oCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/I4o5y5PN8fv1JLOWyhDfgvQcHtA Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 14:33:53 -0000 SGksDQoNCkkgYW0gb2sgaW5kaWNhdGluZyBpbiB0aGUgQU5TV0VSIHdoZXRoZXIgaXQgc2hhbGwg YmUgc2VudCBvciBub3QuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBIdXR0b24sIEFuZHJldyBbbWFpbHRvOmFuZHJldy5odXR0b25A dW5pZnkuY29tXSANClNlbnQ6IDI0IE9jdG9iZXIgMjAxNCAxNjo0MQ0KVG86IEFyaSBLZXLDpG5l bjsgRXJpYyBSZXNjb3JsYTsgSm9uYXRoYW4gTGVubm94DQpDYzogRmxlbW1pbmcgQW5kcmVhc2Vu OyBtbXVzaWM7IENocmlzdGVyIEhvbG1iZXJnDQpTdWJqZWN0OiBSRTogW01NVVNJQ10gUmV2aXNp dCBjb25zZW5zdXMgPyBbUmU6IElDRSB1cGRhdGVkIG9mZmVyIC0gQmFjayB0byB0aGUgaW5pdGlh bCBxdWVzdGlvbl0NCg0KSSBwYXJ0aWNpcGF0ZWQgaW4gdGhlIGRpc2N1c3NlZCBkdXJpbmcgSUVU RjkwIGFuZCBoYXZlIHJlYWQgdGhyb3VnaCB0aGUgbGF0ZXN0IHRocmVhZC4NCg0KRHVyaW5nIHRo ZSBtZWV0aW5nIEkgd2FzIGluIGZhdm9yIG9mIG9wdGlvbiAzIChFa3IncyBwcm9wb3NhbDogeW91 IGRvIGl0IG9yIGRvbuKAmXQgZG8gaXQsIGJ1dCB5b3UgaW5kaWNhdGUgaW4gdGhlIG8vYSBpZiB5 b3XigJlyZSBnb2luZyB0byBkbyBpdCkgYW5kIEkgaGF2ZSBub3Qgc2VlbiBhbnkgbmV3IGFyZ3Vt ZW50cyBzbyBJIGFtIHN0aWxsIG9mIHRoZSBzYW1lIG9waW5pb24uDQoNClJlZ2FyZHMNCkFuZHkN Cg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1tdXNpYyBb bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXJpIEtlcsOkbmVu DQo+IFNlbnQ6IDIzIE9jdG9iZXIgMjAxNCAyMjozOA0KPiBUbzogRXJpYyBSZXNjb3JsYTsgSm9u YXRoYW4gTGVubm94DQo+IENjOiBGbGVtbWluZyBBbmRyZWFzZW47IG1tdXNpYzsgQ2hyaXN0ZXIg SG9sbWJlcmcNCj4gU3ViamVjdDogUmU6IFtNTVVTSUNdIFJldmlzaXQgY29uc2Vuc3VzID8gW1Jl OiBJQ0UgdXBkYXRlZCBvZmZlciAtIA0KPiBCYWNrIHRvIHRoZSBpbml0aWFsIHF1ZXN0aW9uXQ0K PiANCj4gRWtyLCBKb25hdGhhbiwgZXQgYWwsDQo+IA0KPiBXZSBhcmUgbm93IGRpc2N1c3Npbmcg dGhlIG5lZWQgZm9yIElDRSB1cGRhdGVkIG9mZmVyIChzZWUgYmVsb3cgYW5kIA0KPiB0aGUgcmVs YXRlZCB0aHJlYWRzIG9uIHRoZSBNTVVTSUMgbGlzdCkuIEFzIEZsZW1taW5nIG1lbnRpb25lZCBi ZWxvdywgDQo+IHdlIGhhdmUgbm90IHlldCBoZWFyZCBvcGluaW9ucyBmcm9tIGV2ZXJ5b25lIHBh cnRpY2lwYXRpbmcgYXQgdGhlIA0KPiBkaXNjdXNzaW9uIGF0IHRoZSBwcmV2aW91cyBtZWV0aW5n Lg0KPiANCj4gSSB0cmllZCB0byBzdW1tYXJpemUgdGhlIGRpc2N1c3Npb25zIHNvIGZhciBhbHNv IGhlcmU6DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbW11c2ljL24x cU9JN1RvNEx1WlJPNDFXR3U0ZzcwMlQNCj4gdg0KPiBVDQo+IA0KPiBDb3VsZCB5b3UgcGxlYXNl IGNvbW1lbnQgd2l0aCB5b3VyIHZpZXdzIHNvIHRoYXQgd2UgaGF2ZSB0aGUgbGF0ZXN0IA0KPiBv cGluaW9ucyBmcm9tIGFsbCBzaWRlcy4NCj4gDQo+IA0KPiBUaGFua3MsDQo+IEFyaSAoYXMgaW5k aXZpZHVhbCkNCj4gDQo+IE9uIE9jdCAyMywgMjAxNCwgYXQgODozNSBBTSwgRmxlbW1pbmcgQW5k cmVhc2VuIHdyb3RlOg0KPiANCj4gPiBJbiB0ZXJtcyBvZiBjb25zZW5zdXMgY2FsbCwgd2UgaGFk IHByZXR0eSBzdHJvbmcgY29uc2Vuc3VzIGluIHRoZQ0KPiBtZWV0aW5nIGZvciBvcHRpb24gIzMg KHNlZSB1bmRlcg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkwL21pbnV0ZXMv bWludXRlcy05MC0NCj4gbW11c2ljI2guMXljNjNlNzRwYmhpKS4gVG8gcmVjYXAsIHRoZSBvcHRp b25zIGFuZCBjb25zZW5zdXMgb3V0Y29tZQ0KPiB3ZXJlOg0KPiA+DQo+ID4gPHF1b3RlPg0KPiA+ IDMgb3B0aW9ucw0KPiA+IDEuIEN1cnJlbnQgNTI0NSBiZWhhdmlvciAob25seSBpZiBjaGFuZ2Ug ZnJvbSBkZWZhdWx0IGNhbmRpZGF0ZSkgMi4gDQo+ID4gTVVTVCBhbHdheXMgZG8gdXBkYXRlZCBP L0EgKHdoZXRoZXIgY2hhbmdlIG9yIG5vdCkgMy4gIkVrcidzIiANCj4gPiBwcm9wb3NhbDogeW91 IGRvIGl0IG9yIGRvbuKAmXQgZG8gaXQsIGJ1dCB5b3UgaW5kaWNhdGUgaW4NCj4gdGhlIG8vYSBp ZiB5b3XigJlyZSBnb2luZyB0byBkbyBpdC4gQmFzaWNhbGx5IHdhbnQgdG8gaGF2ZSBvcHRpb24g dG8gDQo+IG5ldmVyIGRvIHRoZSB1cGRhdGVkIE8vQSBleGNoYW5nZSwgd2l0aCBhbiBpbmRpY2F0 aW9uIGluIHRoZSBzaWduYWxpbmcgDQo+IHRoYXQgeW91IHdpbGwgbm90IGJlIGRvaW5nIGl0LiBP ZiBjb3Vyc2UgY2FuIGFsd2F5cyBpbml0aWF0ZSBhIG5ldyBPL0EgDQo+IGV4Y2hhbmdlIHdoZW5l dmVyIHlvdSB3YW50IHRvLg0KPiA+DQo+ID4gQ29uc2Vuc3VzIGNhbGwgYnkgY2hhaXIgKEZsZW1t aW5nKToNCj4gPiAwIGZvciBvcHRpb24gMQ0KPiA+IDMgZm9yIG9wdGlvbiAyDQo+ID4gMTUgZm9y IG9wdGlvbiAzDQo+ID4gPC9xdW90ZT4NCj4gPg0KPiA+IFNpbmNlIHRoZW4sIEFyaSBzdGFydGVk IGEgdGhyZWFkIHRvIGZpbmQgb3V0IGlmIG9wdGlvbiAzIHdhcyBjYXVzaW5nDQo+IG1ham9yIHBy b2JsZW1zIGZvciBwZW9wbGUsIGFuZCBpZiBzbywgaWYgdGhlcmUgd2VyZSBhIChiZXR0ZXIgPykg d2F5IA0KPiBvZiBhZGRyZXNzaW5nIHRob3NlLiBUaGlzIGlzIGVzc2VudGlhbHkgd2hhdCB0aGlz IHdob2xlICJJQ0UgdXBkYXRlZCANCj4gb2ZmZXIiIHRocmVhZCBoYXMgYmVlbiBhYm91dC4NCj4g Pg0KPiA+IEZyb20gYSBjaGFpciBwb2ludCBvZiB2aWV3LCBJIHRoaW5rIGl0J3MgZmFpciB0byBz YXkgdGhhdCB3ZSBoYXZlDQo+IGhlYXJkIGFkZGl0aW9uYWwgcG9pbnRzIG9mIHZpZXcgYW5kIHBy b3Bvc2FscyBhcyBwYXJ0IG9mIHRoaXMgdGhyZWFkLCANCj4gYnV0IHRoYXQgd2UgYWxzbyBvbmx5 IGhlYXJkIGZyb20gYSBzdWJzZXQgb2YgdGhlIHBlb3BsZSBpbnZvbHZlZCBpbiANCj4gdGhlIGRp c2N1c3Npb24gYXQgSUVURiA5MC4gV2hhdCBJIHdvdWxkIHN1Z2dlc3QgaXMgdGhhdCB0aGUgYXV0 aG9yIA0KPiAoQXJpKSBhY3RpdmVseSBlbmdhZ2VzIHRoZSBwZW9wbGUgdGhhdCBleHByZXNzZWQg YW4gb3BpbmlvbiBhdCBJRVRGIDkwIA0KPiBpbiB0aGlzIGRpc2N1c3Npb24gdG8gZ2V0IHRoZWly IHBvaW50cyBvZiB2aWV3LiBXZSBjYW4gdGhlbiBkaXNjdXNzIGF0IA0KPiBJRVRGIDkxIGFnYWlu IGFuZCB0YWtlIGFub3RoZXIgY29uc2Vuc3VzIGNhbGwgYmFzZWQgb24gYWxsIHRoZSANCj4gaW5m b3JtYXRpb24gYXZhaWxhYmxlLiBXZSB3aWxsIG1ha2Ugc3VyZSB0byBhbHNvIHRha2UgdGhhdCBj b25zZW5zdXMgDQo+IGNhbGwgdG8gdGhlIG1haWxpbmcgbGlzdCBzdWJzZXF1ZW50bHkgdG8gaG9w ZWZ1bGx5IGFncmVlIG9uIHRoZSB3YXkgDQo+IGZvcndhcmQgKG9yIGF0IGxlYXN0IGdldCBleHBs aWNpdCBjb25zZW5zdXMpLg0KPiA+DQo+ID4gVGhhbmtzDQo+ID4NCj4gPiAtLSBGbGVtbWluZyAo YXMgTU1VU0lDIGNvLWNoYWlyKS4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIDEwLzE3LzE0 LCA3OjA4IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gPj4gSGksDQo+ID4+DQo+ID4+ IFRoZXJlIHdhcyBhIGNvbnNlbnN1cyBjYWxsIGZvciAzLCBzbyB0aGUgbWludXRlcyBhcmUgY29y cmVjdC4NCj4gPj4NCj4gPj4gSSBhcG9sb2dpemUgaWYgSSBzaG91bGQgaGF2ZSBjaGFsbGVuZ2Vk IHRoZSBtaW51dGVzLCByYXRoZXIgdGhhbg0KPiB3YWl0aW5nIGZvciBhbiBleHBsaWNpdCB2ZXJp ZmljYXRpb24gY2FsbCBmcm9tIHRoZSBjaGFpcnMuDQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+ DQo+ID4+IENocmlzdGVyDQo+ID4+DQo+ID4+IFNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQo+ ID4+IEZyb206IFN0YWNoLCBUaG9tYXMNCj4gPj4gU2VudDog4oCOMTcv4oCOMTAv4oCOMjAxNCAx Mzo1OA0KPiA+PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IEFyaSBLZXLDpG5lbjsgbW11c2ljDQo+ ID4+IFN1YmplY3Q6IFJFOiBbTU1VU0lDXSAgSUNFIHVwZGF0ZWQgb2ZmZXIgLSBCYWNrIHRvIHRo ZSBpbml0aWFsDQo+IHF1ZXN0aW9uDQo+ID4+DQo+ID4+ID4NCj4gPj4gPiBIaSwNCj4gPj4gPg0K PiA+PiA+IFdoYXRldmVyIGRlY2lzaW9ucyBhcmUgbWFkZSBhdCB0aGUgbWVldGluZ3MgbXVzdCAo b3IsIGF0IGxlYXN0DQo+IHRoYXQgc2VlbSB0bw0KPiA+PiA+IGJlIGRlIGZhY3RvIHByYWN0aXNl KSBiZSBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdC4NCj4gPj4gWW91J3JlIHJpZ2h0IEkg YWxzbyBoYXZlbid0IHNlZW4gYW4gZXhwbGljaXQgY29uc2Vuc3VzIGNhbGwgb24gdGhlDQo+IGxp c3QuDQo+ID4+IEJ1dCB0aGVyZSBhbHNvIHdhc24ndCBvYmplY3Rpb24gYWdhaW5zdCB0aGUgbWlu dXRlcyBhbmQgdGhleSBzYXk6DQo+ID4+ICJDaGFpciBjYWxscyBjb25zZW5zdXMgb24gb3B0aW9u IDMuIg0KPiA+PiBNYXliZSB0aGUgY2hhaXJzIGNhbiBoZWxwIHdoZXJlIHdlIGFyZSB3cnQgdG8g Y29uc2Vuc3VzIG9yIG5vdA0KPiBjb25zZW5zdXMuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG1tdXNp YyBtYWlsaW5nIGxpc3QNCj4gPj4NCj4gPj4gbW11c2ljQGlldGYub3JnDQo+ID4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+ID4NCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5n IGxpc3QNCj4gbW11c2ljQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQo= From nobody Sat Oct 25 07:37:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33CA1A0039 for ; Sat, 25 Oct 2014 07:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUH2tIQe_7C2 for ; Sat, 25 Oct 2014 07:37:14 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADFA1A0030 for ; Sat, 25 Oct 2014 07:37:14 -0700 (PDT) Received: from [81.187.2.149] (port=40679 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xi2Ss-0004ZQ-3J; Sat, 25 Oct 2014 15:37:11 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C8201@ESESSMB209.ericsson.se> Date: Sat, 25 Oct 2014 15:36:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8201@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/d0LRfd1CxTgLBuDLMfAkSRQf7e8 Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 14:37:17 -0000 Hi, Possibly, although that suggests that an SSRC can switch m=3D lines, = whereas what happens is that the SSRC leaves the session and re-joins as = a different m=3D line. Perhaps: A given SSRC MUST, at any given time, only transmit RTP/RTCP packets = associated with a single =93m=3D" line. An SSRC can leave the session = and rejoin under a different =93m=3D=93 line, however to do so it MUST = send an RTCP BYE packet, then MUST wait for a timeout interval of 5 = times the RTCP reporting interval, before the SSRC starts to transmit = RTP/RTCP packets associated with the new =93m=3D=93 line. The RTCP BYE = and timeout interval ensure that any remaining packets and state = associated with the SSRC on the previous =93m=3D=93 line will be = considered invalid [RFC3550]. Colin On 25 Oct 2014, at 15:28, Christer Holmberg = wrote: > Hi Colin, >=20 > Thanks for your input. >=20 > So, perhaps something like: >=20 > A given SSRC MUST, at any given time, only transmit RTP/RTCP packets = associated with a single "m=3D" line. If the SSRC wants to switch "m=3D" = line, there MUST be a timeout interval of 5 times the RTCP reporting = interval before the SSRC starts to transmit RTP/RTCP packets associated = with the new "m=3D" line, as that will ensure that any remaining packets = associated with the previous "m=3D" line will be considered invalid = [RFC3550]." >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: 25 October 2014 16:57 > To: Christer Holmberg > Cc: Jonathan Lennox; mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >=20 > Hi, >=20 > I suggest that the timeout period be 5 times the RTCP reporting = interval. This is the SSRC timeout interval defined in RFC 3550 section = 6.3.5, and is how long a receiver will consider an SSRC valid if that = SSRC stops sending and it's RTCP BYE is lost. >=20 > Colin >=20 >=20 >=20 > On 24 Oct 2014, at 20:36, Christer Holmberg = wrote: >> Hi, >>=20 >> What about: >>=20 >> "A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets = associated with different "m=3D" lines. There needs to be a time period, = long enough to make sure there are no packets associate with the = previous "m=3D" line in the network, before the SSRC starts to transmit = RTP/RTCP packets associated with a new "m=3D" line." >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >> Sent: 24 October 2014 22:29 >> To: Christer Holmberg >> Cc: mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >>=20 >> My worry is that your text (as modified to include RTCP), interpreted = literally, would be too constraining for very-long-lived sessions, where = you might have used an SSRC on one m-line three weeks ago, and now you = need to remember it forever so you don't reuse that same value on a = different one.=20 >>=20 >> On Oct 24, 2014, at 3:24 PM, Christer Holmberg = wrote: >>=20 >>> Hi, >>>=20 >>> So, is the text I suggested ok, or do you want to write something = else? >>>=20 >>> If would be good if we could add the text to the bullet list in the = RTP Considerations section. But, if you think it requires more text, = we'll put it somewhere else. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >>> Sent: 24 October 2014 21:38 >>> To: Christer Holmberg >>> Cc: mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>=20 >>> Right. >>>=20 >>> The case my "twice the MSL" text is designed to handle is the case = where an SSRC leaves (sends RTCP bye), and then the sender spins up = another SSRC on a different mid, and happens to pick the same SSRC = value. This shouldn't happen very often (1 in 2^32) if SSRC = randomization is implemented properly, but sometimes people use bad = random number generators (or are, e.g., playing games with not = renumbering at a source projecting mixer). This isn't an SSRC = collision, technically, since for the sender the old source is gone, but = if old packets with the old mid are still lingering in the network, = you'll get confused. Thus my recommendation to make sure you wait = before you reuse SSRC values. >>>=20 >>> On Oct 24, 2014, at 12:07 PM, Christer Holmberg = wrote: >>>=20 >>>> ...and, obviously the SSRC would also always use the same MID in = the RTCP SDES MID item. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> -----Original Message----- >>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer = Holmberg >>>> Sent: 24 October 2014 19:01 >>>> To: Jonathan Lennox; mmusic >>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>>=20 >>>> Hi Jonathan, >>>>=20 >>>> In the RTP Considerations section, we currently have the following = text: >>>>=20 >>>> "A given SSRC MUST NOT transmit RTP packets using payload types = that=20 >>>> originate from different bundled "m=3D" lines." >>>>=20 >>>> That doesn't cover what you are talking about, but perhaps we could = add a statement saying something like: >>>>=20 >>>> "A given SSCR MUST NOT transmit RTP packets associated with = different "m=3D" lines. When >>>> the RTP MID header extension is used, the SSRC MUST use the same = 'mid' value in every >>>> RTP packet." >>>>=20 >>>> ...or something like that. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan = Lennox >>>> Sent: 24 October 2014 17:50 >>>> To: mmusic >>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>>=20 >>>> One issue which I've brought up a number of times in BUNDLE is = whether it's valid for an RTP stream to move between bundled m-lines, or = be shared between several bundled m-lines. >>>>=20 >>>> While (as I've described) there are a number of useful features = that this could enable, it sounded at the last IETF meeting that people = weren't interested in the complexity it introduces. (It's certainly = something that wouldn't be possible with unbundled m-lines.) As such, I = think BUNDLE needs to document that this isn't allowed. >>>>=20 >>>> As such, I suggest adding to the section on MID something like: >>>>=20 >>>> RTP streams MUST NOT be moved between media descriptions. If a MID = is communicated for an RTP stream, that stream's SSRC MUST NOT be reused = for another RTP stream with a different MID value until at least twice = the Maximum Segment Lifetime (MSL) has elapsed since the last time a = packet (RTP or RTCP) was sent for the old stream. >>>>=20 >>>> This makes sure that stuck packets in the network can't confuse a = stream's MID association. >>>>=20 >>>> If people *do* want the ability to move streams between m-lines, we = will need some more complicated rules, which I could try to draft if = people are interested. >>>> _______________________________________________ >>>> 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 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ From nobody Sat Oct 25 07:52:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EC91A005C for ; Sat, 25 Oct 2014 07:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH-OBCEHtMzn for ; Sat, 25 Oct 2014 07:52:37 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A041A0059 for ; Sat, 25 Oct 2014 07:52:36 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-53-544bb9325723 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 39.69.24955.239BB445; Sat, 25 Oct 2014 16:52:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 16:52:33 +0200 From: Christer Holmberg To: Paul Kyzivat , Adam Roach , "mmusic@ietf.org" , "draft-ietf-mmusic-rfc4566bis@tools.ietf.org" Thread-Topic: [MMUSIC] Comment on draft-ietf-mmusic-rfc4566bis-12 Thread-Index: AQHP77hqkEUU/ijxfUiPnCSFJmS0AZw/eGuAgAFs7MA= Date: Sat, 25 Oct 2014 14:52:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C82C5@ESESSMB209.ericsson.se> References: <5446DCDB.6070409@nostrum.com> <544711FF.9020607@alum.mit.edu> <544A9A70.1010308@nostrum.com> <544AA1A9.4080905@alum.mit.edu> In-Reply-To: <544AA1A9.4080905@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja7RTu8Qg8u3VC32/F3EbjF93htW i6nLH7NYrNhwgNWBxePv+w9MHkuW/GTymLXzCYvHl8uf2QJYorhsUlJzMstSi/TtErgyXl9Y xVzQylGxee551gbG9WxdjJwcEgImEu/3XIGyxSQu3AOJc3EICRxllDj6posdwlnCKLHucR+Q w8HBJmAh0f1PG6RBROA8o0TP61gQW1jAQeLElz0sEHFHicZ7J5ggbCuJhTMWsYLYLAKqEnea zoDV8Ar4Six89g0sLiRwiVGioZEbxOYU0JHo238JrIYR6KDvp9aAzWEWEJe49WQ+E8ShAhJL 9pxnhrBFJV4+/scKYStJrNh+iRGiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFp mYWkZRaSlgWMLKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAuPp4JbfqjsYL79xPMQowMGo xMOrwOIdIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGHXF 093dv/unvdxczPVlZsCnIGdOpeNNUzJXd2U7mj05tLzn+Mknk1+HtJ+acyWcVUUkSUPHx0Ow ke9CZdV9nYUrS1e8/Lkhl2PL1Z4ZvE7nGL8oCETsktzbfGxCoPDk10uk1dd8fxEYsEN623l1 wwYTgz28jv9cTwZ4Xqn+IqOdsW3i8uzZLUosxRmJhlrMRcWJADAuHMiIAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/QwjBv3ZPHHyKeBAa_imOzNK2C6w Subject: Re: [MMUSIC] Comment on draft-ietf-mmusic-rfc4566bis-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 14:52:38 -0000 Hi, >> I do admit that I'm confused by draft-ietf-mmusic-rfc4566bis-12=20 >> section 8.2.4. The third bullet calls for an ABNF syntax rule defining=20 >> for the syntax of the value. The seventh bullet calls for an ABNF=20 >> definition for the syntax of the value. >> >> If this isn't straight-up duplication, then I think the document needs=20 >> to make a clearer distinction between what it means by these two=20 >> bullets. I certainly wouldn't know how to conform to these=20 >> requirements if I needed to register a new attribute. > > The third bullet asks for the *name* of an ABNF rule. > > The 7th bullet asks for the *definition* of that rule. I thought it was c= lear. If not, can > you suggest a change to improve it? My suggestion would be to remove the 3rd bullet. IANA does not need that in= formation, and there is no need to put it in any registry. The 7th bullet would ask for a reference to where the syntax, offer/answer = considerations etc, are defined. Regards, Christer From nobody Sat Oct 25 07:56:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BDC1A00DB for ; Sat, 25 Oct 2014 07:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKt2ZfHAXn5S for ; Sat, 25 Oct 2014 07:56:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4CD1A00E1 for ; Sat, 25 Oct 2014 07:56:35 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-d0-544bba21691d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A1.B9.24955.12ABB445; Sat, 25 Oct 2014 16:56:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 16:56:33 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQgAAFRoCAAH4RgP//uJeggABVgQD//6y0sIABE4MAgAAn96D//+NSgAAE0cNw Date: Sat, 25 Oct 2014 14:56:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C830D@ESESSMB209.ericsson.se> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8201@ESESSMB209.ericsson.se> 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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja7SLu8Qg19/2S2WvzzBaLF/8Xlm i6nLH7M4MHtMu3+fzWPJkp9MHm3P7rAHMEdx2aSk5mSWpRbp2yVwZSz7/5GxYINTRc/MM+wN jHdNuxg5OSQETCRWtX9ng7DFJC7cWw9kc3EICRxllGg8/RrKWcIoMe3EaaYuRg4ONgELie5/ 2iANIgKqEjuO/2MEsZkFnCT+7LzHBGILC4RLzFh4hx2iJkKi7dZ/KDtP4saFO6wgNgtQ74pP T8HqeQV8JfYd2c4OsauZVaLxTiszyC5OAUeJv1cNQGoYgY77fmoNE8QucYlbT+YzQRwtILFk z3lmCFtU4uXjf6wQtpLEiu2XoG7TkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDYLydhZSFpm IWmZhaRlASPLKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAmDq45bfqDsbLbxwPMQpwMCrx 8CqweIcIsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGYiW9 69zHt0b1FyS5RiXMl9mq1xH/Y1HMDbsz7EJ92cJ29/z+lv9+oeqeWLlQucd8yS4J8zVLHk2s 2Py4jenxca43U7r/qDFNNNXb/KPxwIx5VzS9zI+48008Zah1w6bcqK13Ovudf/e3JYpvUJB6 qDHJh4ld4Me/pq8nbft/+0sppyz5/M1GiaU4I9FQi7moOBEALZCuiooCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VRmOcE6bHmqVA4EiDRLepYH4v_c Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 14:56:39 -0000 Hi Colin, Your suggested text looks good. But, doesn't RFC 3550 specify the sending o= f RTCP BYE for leaving a session? If so, I don't think we should use "MUST"= in the BUNDLE draft. We should simply indicate that a RTCP BYE is sent. Regards, Christer -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: 25 October 2014 17:37 To: Christer Holmberg Cc: Jonathan Lennox; mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lin= es, or not Hi, Possibly, although that suggests that an SSRC can switch m=3D lines, wherea= s what happens is that the SSRC leaves the session and re-joins as a differ= ent m=3D line. Perhaps: A given SSRC MUST, at any given time, only transmit RTP/RTCP packets associ= ated with a single "m=3D" line. An SSRC can leave the session and rejoin un= der a different "m=3D" line, however to do so it MUST send an RTCP BYE pack= et, then MUST wait for a timeout interval of 5 times the RTCP reporting int= erval, before the SSRC starts to transmit RTP/RTCP packets associated with = the new "m=3D" line. The RTCP BYE and timeout interval ensure that any rema= ining packets and state associated with the SSRC on the previous "m=3D" lin= e will be considered invalid [RFC3550]. Colin On 25 Oct 2014, at 15:28, Christer Holmberg wrote: > Hi Colin, >=20 > Thanks for your input. >=20 > So, perhaps something like: >=20 > A given SSRC MUST, at any given time, only transmit RTP/RTCP packets asso= ciated with a single "m=3D" line. If the SSRC wants to switch "m=3D" line, = there MUST be a timeout interval of 5 times the RTCP reporting interval bef= ore the SSRC starts to transmit RTP/RTCP packets associated with the new "m= =3D" line, as that will ensure that any remaining packets associated with t= he previous "m=3D" line will be considered invalid [RFC3550]." >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: 25 October 2014 16:57 > To: Christer Holmberg > Cc: Jonathan Lennox; mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > Hi, >=20 > I suggest that the timeout period be 5 times the RTCP reporting interval.= This is the SSRC timeout interval defined in RFC 3550 section 6.3.5, and i= s how long a receiver will consider an SSRC valid if that SSRC stops sendin= g and it's RTCP BYE is lost. >=20 > Colin >=20 >=20 >=20 > On 24 Oct 2014, at 20:36, Christer Holmberg wrote: >> Hi, >>=20 >> What about: >>=20 >> "A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets ass= ociated with different "m=3D" lines. There needs to be a time period, long = enough to make sure there are no packets associate with the previous "m=3D"= line in the network, before the SSRC starts to transmit RTP/RTCP packets a= ssociated with a new "m=3D" line." >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >> Sent: 24 October 2014 22:29 >> To: Christer Holmberg >> Cc: mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-= lines, or not >>=20 >> My worry is that your text (as modified to include RTCP), interpreted li= terally, would be too constraining for very-long-lived sessions, where you = might have used an SSRC on one m-line three weeks ago, and now you need to = remember it forever so you don't reuse that same value on a different one.= =20 >>=20 >> On Oct 24, 2014, at 3:24 PM, Christer Holmberg wrote: >>=20 >>> Hi, >>>=20 >>> So, is the text I suggested ok, or do you want to write something else? >>>=20 >>> If would be good if we could add the text to the bullet list in the RTP= Considerations section. But, if you think it requires more text, we'll put= it somewhere else. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >>> Sent: 24 October 2014 21:38 >>> To: Christer Holmberg >>> Cc: mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m= -lines, or not >>>=20 >>> Right. >>>=20 >>> The case my "twice the MSL" text is designed to handle is the case wher= e an SSRC leaves (sends RTCP bye), and then the sender spins up another SSR= C on a different mid, and happens to pick the same SSRC value. This should= n't happen very often (1 in 2^32) if SSRC randomization is implemented prop= erly, but sometimes people use bad random number generators (or are, e.g., = playing games with not renumbering at a source projecting mixer). This isn= 't an SSRC collision, technically, since for the sender the old source is g= one, but if old packets with the old mid are still lingering in the network= , you'll get confused. Thus my recommendation to make sure you wait before= you reuse SSRC values. >>>=20 >>> On Oct 24, 2014, at 12:07 PM, Christer Holmberg wrote: >>>=20 >>>> ...and, obviously the SSRC would also always use the same MID in the R= TCP SDES MID item. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> -----Original Message----- >>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Ho= lmberg >>>> Sent: 24 October 2014 19:01 >>>> To: Jonathan Lennox; mmusic >>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >>>>=20 >>>> Hi Jonathan, >>>>=20 >>>> In the RTP Considerations section, we currently have the following tex= t: >>>>=20 >>>> "A given SSRC MUST NOT transmit RTP packets using payload types that= =20 >>>> originate from different bundled "m=3D" lines." >>>>=20 >>>> That doesn't cover what you are talking about, but perhaps we could ad= d a statement saying something like: >>>>=20 >>>> "A given SSCR MUST NOT transmit RTP packets associated with different= "m=3D" lines. When >>>> the RTP MID header extension is used, the SSRC MUST use the same 'mid= ' value in every >>>> RTP packet." >>>>=20 >>>> ...or something like that. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Le= nnox >>>> Sent: 24 October 2014 17:50 >>>> To: mmusic >>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >>>>=20 >>>> One issue which I've brought up a number of times in BUNDLE is whether= it's valid for an RTP stream to move between bundled m-lines, or be shared= between several bundled m-lines. >>>>=20 >>>> While (as I've described) there are a number of useful features that t= his could enable, it sounded at the last IETF meeting that people weren't i= nterested in the complexity it introduces. (It's certainly something that = wouldn't be possible with unbundled m-lines.) As such, I think BUNDLE need= s to document that this isn't allowed. >>>>=20 >>>> As such, I suggest adding to the section on MID something like: >>>>=20 >>>> RTP streams MUST NOT be moved between media descriptions. If a MID is= communicated for an RTP stream, that stream's SSRC MUST NOT be reused for = another RTP stream with a different MID value until at least twice the Maxi= mum Segment Lifetime (MSL) has elapsed since the last time a packet (RTP or= RTCP) was sent for the old stream. >>>>=20 >>>> This makes sure that stuck packets in the network can't confuse a stre= am's MID association. >>>>=20 >>>> If people *do* want the ability to move streams between m-lines, we wi= ll need some more complicated rules, which I could try to draft if people a= re interested. >>>> _______________________________________________ >>>> 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 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ From nobody Sat Oct 25 08:03:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435801A00EB for ; Sat, 25 Oct 2014 08:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd_VSJNycnIP for ; Sat, 25 Oct 2014 08:02:56 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181EC1A00AA for ; Sat, 25 Oct 2014 08:02:56 -0700 (PDT) Received: from [81.187.2.149] (port=46070 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xi2rj-00076A-Eb; Sat, 25 Oct 2014 16:02:53 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C830D@ESESSMB209.ericsson.se> Date: Sat, 25 Oct 2014 16:02:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <833C4F60-7CBF-441B-965C-F87B64E74B94@csperkins.org> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8201@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C830D@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/31_NH0J8O2xxQzad9CfymPEO-5U Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 15:02:59 -0000 Hi, You could say =93=85it has to first send an RTCP BYE following the rules = in section 6.3.7 of RFC3550, then it MUST wait for a timeout=85=94? Colin On 25 Oct 2014, at 15:56, Christer Holmberg = wrote: > Hi Colin, >=20 > Your suggested text looks good. But, doesn't RFC 3550 specify the = sending of RTCP BYE for leaving a session? If so, I don't think we = should use "MUST" in the BUNDLE draft. We should simply indicate that a = RTCP BYE is sent. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: 25 October 2014 17:37 > To: Christer Holmberg > Cc: Jonathan Lennox; mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >=20 > Hi, >=20 > Possibly, although that suggests that an SSRC can switch m=3D lines, = whereas what happens is that the SSRC leaves the session and re-joins as = a different m=3D line. Perhaps: >=20 > A given SSRC MUST, at any given time, only transmit RTP/RTCP packets = associated with a single "m=3D" line. An SSRC can leave the session and = rejoin under a different "m=3D" line, however to do so it MUST send an = RTCP BYE packet, then MUST wait for a timeout interval of 5 times the = RTCP reporting interval, before the SSRC starts to transmit RTP/RTCP = packets associated with the new "m=3D" line. The RTCP BYE and timeout = interval ensure that any remaining packets and state associated with the = SSRC on the previous "m=3D" line will be considered invalid [RFC3550]. >=20 > Colin >=20 >=20 >=20 > On 25 Oct 2014, at 15:28, Christer Holmberg = wrote: >> Hi Colin, >>=20 >> Thanks for your input. >>=20 >> So, perhaps something like: >>=20 >> A given SSRC MUST, at any given time, only transmit RTP/RTCP packets = associated with a single "m=3D" line. If the SSRC wants to switch "m=3D" = line, there MUST be a timeout interval of 5 times the RTCP reporting = interval before the SSRC starts to transmit RTP/RTCP packets associated = with the new "m=3D" line, as that will ensure that any remaining packets = associated with the previous "m=3D" line will be considered invalid = [RFC3550]." >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org]=20 >> Sent: 25 October 2014 16:57 >> To: Christer Holmberg >> Cc: Jonathan Lennox; mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >>=20 >> Hi, >>=20 >> I suggest that the timeout period be 5 times the RTCP reporting = interval. This is the SSRC timeout interval defined in RFC 3550 section = 6.3.5, and is how long a receiver will consider an SSRC valid if that = SSRC stops sending and it's RTCP BYE is lost. >>=20 >> Colin >>=20 >>=20 >>=20 >> On 24 Oct 2014, at 20:36, Christer Holmberg = wrote: >>> Hi, >>>=20 >>> What about: >>>=20 >>> "A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets = associated with different "m=3D" lines. There needs to be a time period, = long enough to make sure there are no packets associate with the = previous "m=3D" line in the network, before the SSRC starts to transmit = RTP/RTCP packets associated with a new "m=3D" line." >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >>> Sent: 24 October 2014 22:29 >>> To: Christer Holmberg >>> Cc: mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>=20 >>> My worry is that your text (as modified to include RTCP), = interpreted literally, would be too constraining for very-long-lived = sessions, where you might have used an SSRC on one m-line three weeks = ago, and now you need to remember it forever so you don't reuse that = same value on a different one.=20 >>>=20 >>> On Oct 24, 2014, at 3:24 PM, Christer Holmberg = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> So, is the text I suggested ok, or do you want to write something = else? >>>>=20 >>>> If would be good if we could add the text to the bullet list in the = RTP Considerations section. But, if you think it requires more text, = we'll put it somewhere else. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> -----Original Message----- >>>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >>>> Sent: 24 October 2014 21:38 >>>> To: Christer Holmberg >>>> Cc: mmusic >>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>>=20 >>>> Right. >>>>=20 >>>> The case my "twice the MSL" text is designed to handle is the case = where an SSRC leaves (sends RTCP bye), and then the sender spins up = another SSRC on a different mid, and happens to pick the same SSRC = value. This shouldn't happen very often (1 in 2^32) if SSRC = randomization is implemented properly, but sometimes people use bad = random number generators (or are, e.g., playing games with not = renumbering at a source projecting mixer). This isn't an SSRC = collision, technically, since for the sender the old source is gone, but = if old packets with the old mid are still lingering in the network, = you'll get confused. Thus my recommendation to make sure you wait = before you reuse SSRC values. >>>>=20 >>>> On Oct 24, 2014, at 12:07 PM, Christer Holmberg = wrote: >>>>=20 >>>>> ...and, obviously the SSRC would also always use the same MID in = the RTCP SDES MID item. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> -----Original Message----- >>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of = Christer Holmberg >>>>> Sent: 24 October 2014 19:01 >>>>> To: Jonathan Lennox; mmusic >>>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>>>=20 >>>>> Hi Jonathan, >>>>>=20 >>>>> In the RTP Considerations section, we currently have the following = text: >>>>>=20 >>>>> "A given SSRC MUST NOT transmit RTP packets using payload types = that=20 >>>>> originate from different bundled "m=3D" lines." >>>>>=20 >>>>> That doesn't cover what you are talking about, but perhaps we = could add a statement saying something like: >>>>>=20 >>>>> "A given SSCR MUST NOT transmit RTP packets associated with = different "m=3D" lines. When >>>>> the RTP MID header extension is used, the SSRC MUST use the same = 'mid' value in every >>>>> RTP packet." >>>>>=20 >>>>> ...or something like that. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of = Jonathan Lennox >>>>> Sent: 24 October 2014 17:50 >>>>> To: mmusic >>>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between = bundled m-lines, or not >>>>>=20 >>>>> One issue which I've brought up a number of times in BUNDLE is = whether it's valid for an RTP stream to move between bundled m-lines, or = be shared between several bundled m-lines. >>>>>=20 >>>>> While (as I've described) there are a number of useful features = that this could enable, it sounded at the last IETF meeting that people = weren't interested in the complexity it introduces. (It's certainly = something that wouldn't be possible with unbundled m-lines.) As such, I = think BUNDLE needs to document that this isn't allowed. >>>>>=20 >>>>> As such, I suggest adding to the section on MID something like: >>>>>=20 >>>>> RTP streams MUST NOT be moved between media descriptions. If a = MID is communicated for an RTP stream, that stream's SSRC MUST NOT be = reused for another RTP stream with a different MID value until at least = twice the Maximum Segment Lifetime (MSL) has elapsed since the last time = a packet (RTP or RTCP) was sent for the old stream. >>>>>=20 >>>>> This makes sure that stuck packets in the network can't confuse a = stream's MID association. >>>>>=20 >>>>> If people *do* want the ability to move streams between m-lines, = we will need some more complicated rules, which I could try to draft if = people are interested. >>>>> _______________________________________________ >>>>> 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 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Sat Oct 25 10:04:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704851A007F for ; Sat, 25 Oct 2014 10:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orCCvZ3kEypd for ; Sat, 25 Oct 2014 10:04:33 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EC21A0019 for ; Sat, 25 Oct 2014 10:04:33 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-11v.sys.comcast.net with comcast id 7V4Z1p0034zp9eg01V4Z6f; Sat, 25 Oct 2014 17:04:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-07v.sys.comcast.net with comcast id 7V4X1p00L3Ge9ey01V4Ymd; Sat, 25 Oct 2014 17:04:32 +0000 Message-ID: <544BD81F.6030407@alum.mit.edu> Date: Sat, 25 Oct 2014 13:04:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , Adam Roach , "mmusic@ietf.org" , "draft-ietf-mmusic-rfc4566bis@tools.ietf.org" References: <5446DCDB.6070409@nostrum.com> <544711FF.9020607@alum.mit.edu> <544A9A70.1010308@nostrum.com> <544AA1A9.4080905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C82C5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C82C5@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414256673; bh=NSROJWSF6wtShwObA8HBkBZ3+iMh+emE7vxOQVjZtYw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G+BBhZ1vl18m735+Zu239r7ASeXYN2ae09moGZdPNA7j9Bh9Mrxiwf3zmkjVIP/VX CXOIxaTK3RHoB7ljOsKxIs85qBLqJJkn144rqmZzhLXSHcYcUb68wlcrVPgPzXx/LF cF2ObxqeuNfchnBMrJrUG7rHAbcsy26YlFZ6KBDUxVIXy6lGCB2LpWyzYFJxwtauGD dUeIZ+td07GdCMFIYRYuuOcs8+QDQ5K4YJ256Cpmwu+br910Rg7QcvzUY+H5v6ekBE Vyd/noehySmW2P1R8Flhk5pfGwDAKt2eAzppiQdqcOpG6yiKCLz7GzHahftL/JwIDx svWxDDnGrFgMQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/aZVPWwNS5WXpSOBR4kNj-jthgNg Subject: Re: [MMUSIC] Comment on draft-ietf-mmusic-rfc4566bis-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 17:04:34 -0000 On 10/25/14 10:52 AM, Christer Holmberg wrote: > Hi, > >>> I do admit that I'm confused by draft-ietf-mmusic-rfc4566bis-12 >>> section 8.2.4. The third bullet calls for an ABNF syntax rule defining >>> for the syntax of the value. The seventh bullet calls for an ABNF >>> definition for the syntax of the value. >>> >>> If this isn't straight-up duplication, then I think the document needs >>> to make a clearer distinction between what it means by these two >>> bullets. I certainly wouldn't know how to conform to these >>> requirements if I needed to register a new attribute. >> >> The third bullet asks for the *name* of an ABNF rule. >> >> The 7th bullet asks for the *definition* of that rule. I thought it was clear. If not, can > you suggest a change to improve it? > > My suggestion would be to remove the 3rd bullet. IANA does not need that information, and there is no need to put it in any registry. > > The 7th bullet would ask for a reference to where the syntax, offer/answer considerations etc, are defined. This isn't just a matter of what IANA needs to know. 4566bis must define the complete set of information that must be provided about an attribute. The IANA registry doesn't need to contain all that info. It minimally needs to contain the name of the attribute and a reference to the document that contains the rest. We put more of the info in the registry for convenience. In particular, it isn't practical to put the abnf for the value into the registry. Nor the semantics for the attribute, beyond some basics like session/media/source level. Thanks, Paul Thanks, Paul From nobody Sat Oct 25 10:20:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4CD1A1A96 for ; Sat, 25 Oct 2014 10:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87SKktdQUBay for ; Sat, 25 Oct 2014 10:20:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769A81A0039 for ; Sat, 25 Oct 2014 10:20:46 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-69-544bdbec52cd Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.FF.24955.CEBDB445; Sat, 25 Oct 2014 19:20:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 19:20:44 +0200 From: Christer Holmberg To: Paul Kyzivat , Adam Roach , "mmusic@ietf.org" , "draft-ietf-mmusic-rfc4566bis@tools.ietf.org" Thread-Topic: [MMUSIC] Comment on draft-ietf-mmusic-rfc4566bis-12 Thread-Index: AQHP77hqkEUU/ijxfUiPnCSFJmS0AZw/eGuAgAFs7MCAAAUtgIAAJIBw Date: Sat, 25 Oct 2014 17:20:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C8448@ESESSMB209.ericsson.se> References: <5446DCDB.6070409@nostrum.com> <544711FF.9020607@alum.mit.edu> <544A9A70.1010308@nostrum.com> <544AA1A9.4080905@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C82C5@ESESSMB209.ericsson.se> <544BD81F.6030407@alum.mit.edu> In-Reply-To: <544BD81F.6030407@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje6b294hBl9XyVrs+buI3WL6vDes FlOXP2axWLHhAKsDi8ff9x+YPJYs+cnkMWvnExaPL5c/swWwRHHZpKTmZJalFunbJXBl/Fn6 hbHgh0DF+0X32RsYt/F2MXJySAiYSEzft4odwhaTuHBvPVsXIxeHkMBRRonu9p9MEM4SRolr h18CORwcbAIWEt3/tEEaRATOM0r0vI4FsYUFHCROfNnDAhF3lGi8d4IJwnaT2DG9CcxmEVCV mH7vBCuIzSvgK7GtbQZYvZDADiaJ/nm5IDangI7E3N2rmUFsRqCDvp9aA9bLLCAucevJfCaI QwUkluw5zwxhi0q8fPyPFcJWklh0+zNUvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEbRWUjG zkLSMgtJyywkLQsYWVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBMbTwS2/VXcwXn7jeIhR gINRiYdXgcU7RIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MMZPs1s/16Zrajfv13tmz6xP5nty3ebq9lq65eGv7ktXnBSzJ0xmVCyUfmrzkuWVoaDqPOtv N6YuzCiXOR10Nin+DYOdG9+HEyrLLzSpKerrdpX/er5PvfrpO6XGe7M8pcxrhVTe//I89cPS cl7aAg7Ob2r5l9n+ff3LqbTra/cq486Ar1UnypRYijMSDbWYi4oTAVpOnaCIAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/mc1p85ip-EkNbSHoZJW3dyuRdgE Subject: Re: [MMUSIC] Comment on draft-ietf-mmusic-rfc4566bis-12 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 17:20:48 -0000 Hi, >>>> I do admit that I'm confused by draft-ietf-mmusic-rfc4566bis-12=20 >>>> section 8.2.4. The third bullet calls for an ABNF syntax rule=20 >>>> defining for the syntax of the value. The seventh bullet calls for=20 >>>> an ABNF definition for the syntax of the value. >>>> >>>> If this isn't straight-up duplication, then I think the document=20 >>>> needs to make a clearer distinction between what it means by these=20 >>>> two bullets. I certainly wouldn't know how to conform to these=20 >>>> requirements if I needed to register a new attribute. >>> >>> The third bullet asks for the *name* of an ABNF rule. >>> >>> The 7th bullet asks for the *definition* of that rule. I thought it was= clear. If not, can > you suggest a change to improve it? >> >> My suggestion would be to remove the 3rd bullet. IANA does not need that= information, and there is no need to put it in any registry. >> >> The 7th bullet would ask for a reference to where the syntax, offer/answ= er considerations etc, are defined. > > This isn't just a matter of what IANA needs to know. > > 4566bis must define the complete set of information that must be provided= about an attribute. The=20 > IANA registry doesn't need to contain all that info. It minimally needs t= o contain the name of the attribute=20 > and a reference to the document that contains the rest. Correct. And, it needs to be clear what information is required, so that ex= pert reviewers etc know to look for it. > We put more of the info in the registry for convenience. > >In particular, it isn't practical to put the abnf for the value into the r= egistry. Nor the semantics for the attribute, beyond some basics like sessi= on/media/source level. Exactly - and I think that is the issue me and Adam are having, as bullet 3= seems to require the value ABNF to be put in the registry. For that reason= I suggest to remove bullet 3, and then in bullet 7 (or somewhere else) inf= orm that the value ABNF needs to be present in the document defining the at= tribute. The name of the attribute obviously need to be in the registry. Regards, Christer From nobody Sat Oct 25 10:39:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BD51A010F for ; Sat, 25 Oct 2014 10:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdR0tSN_TMEV for ; Sat, 25 Oct 2014 10:39:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DD91A00BF for ; Sat, 25 Oct 2014 10:39:33 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-7b-544be0533524 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CE.72.04387.350EB445; Sat, 25 Oct 2014 19:39:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 19:39:31 +0200 From: Christer Holmberg To: Colin Perkins Thread-Topic: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not Thread-Index: AQHP75nPDpkJoAL4VUWPX+qHl7cVqJw/ZJrQgAAFRoCAAH4RgP//uJeggABVgQD//6y0sIABE4MAgAAn96D//+NSgAAE0cNw///gnoD//7PsgA== Date: Sat, 25 Oct 2014 17:39:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C8476@ESESSMB209.ericsson.se> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8201@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C830D@ESESSMB209.ericsson.se> <833C4F60-7CBF-441B-965C-F87B64E74B94@csperkins.org> In-Reply-To: <833C4F60-7CBF-441B-965C-F87B64E74B94@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW7IA+8Qg40XmC2WvzzBaLF/8Xlm i6nLH7M4MHtMu3+fzWPJkp9MHm3P7rAHMEdx2aSk5mSWpRbp2yVwZbQ3ihVc8a2Yt/EBYwPj d7suRk4OCQETiZar51ghbDGJC/fWs3UxcnEICRxllLi46wcThLOEUeLpzAvsXYwcHGwCFhLd /7RBGkQEVCV2HP/HCGIzCzhJ/Nl5jwnEFhYIl5ix8A47RE2ERNut/1B2ncSq54fBbBag3jsH L4DZvAK+EuvOvoXa9Y9Voms+xEWcAo4S3/ZsBVvACHTd91NrmCCWiUvcejKfCeJqAYkle84z Q9iiEi8f/4P6Rkli0e3PUPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2z kLQsYGRZxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYUwe3/LbawXjwueMhRgEORiUeXgUW 7xAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4u2tPRP+v 703PqmVa9/aLrXh9+aLQbF6Z2zuvR0055b3pp+ThmTcXH/wkZ3CtesfGn1nTs3I/y1f73PqZ GfD2K3vxD5MagdlRNZe2llzQeKdv1BbraNj+oyi6pnfFx9crLHZ1qH1btWrOy8ZjfMJb2Dbt W/343osQ01Dl4g3Badwsy907PTkslFiKMxINtZiLihMBnpDtmIoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/wNIAQifwn0TvVMOIxLzl1wd8ky0 Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 25 Oct 2014 17:39:37 -0000 Hi, What about? "A given SSRC MUST, at any given time, only transmit RTP/RTCP packets assoc= iated with a single "m=3D" line. An SSRC can leave the session and re-join = under a different "m=3D" line. If the SSRC does that, after it has sent an = RTCP BYE packet [RFC3550], it MUST wait for a timeout interval of 5 times t= he RTCP reporting interval before it starts to transmit RTP/RTCP packets as= sociated with the new "m=3D" line. The RTCP BYE packet and the timeout inte= rval ensure that any remaining packets and state associated with the SSRC o= n the previous "m=3D" line will be considered invalid [RFC3550]." Regards, Christer -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: 25 October 2014 18:03 To: Christer Holmberg Cc: Jonathan Lennox; mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lin= es, or not Hi, You could say "...it has to first send an RTCP BYE following the rules in s= ection 6.3.7 of RFC3550, then it MUST wait for a timeout..."? Colin On 25 Oct 2014, at 15:56, Christer Holmberg wrote: > Hi Colin, >=20 > Your suggested text looks good. But, doesn't RFC 3550 specify the sending= of RTCP BYE for leaving a session? If so, I don't think we should use "MUS= T" in the BUNDLE draft. We should simply indicate that a RTCP BYE is sent. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: 25 October 2014 17:37 > To: Christer Holmberg > Cc: Jonathan Lennox; mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >=20 > Hi, >=20 > Possibly, although that suggests that an SSRC can switch m=3D lines, wher= eas what happens is that the SSRC leaves the session and re-joins as a diff= erent m=3D line. Perhaps: >=20 > A given SSRC MUST, at any given time, only transmit RTP/RTCP packets asso= ciated with a single "m=3D" line. An SSRC can leave the session and rejoin = under a different "m=3D" line, however to do so it MUST send an RTCP BYE pa= cket, then MUST wait for a timeout interval of 5 times the RTCP reporting i= nterval, before the SSRC starts to transmit RTP/RTCP packets associated wit= h the new "m=3D" line. The RTCP BYE and timeout interval ensure that any re= maining packets and state associated with the SSRC on the previous "m=3D" l= ine will be considered invalid [RFC3550]. >=20 > Colin >=20 >=20 >=20 > On 25 Oct 2014, at 15:28, Christer Holmberg wrote: >> Hi Colin, >>=20 >> Thanks for your input. >>=20 >> So, perhaps something like: >>=20 >> A given SSRC MUST, at any given time, only transmit RTP/RTCP packets ass= ociated with a single "m=3D" line. If the SSRC wants to switch "m=3D" line,= there MUST be a timeout interval of 5 times the RTCP reporting interval be= fore the SSRC starts to transmit RTP/RTCP packets associated with the new "= m=3D" line, as that will ensure that any remaining packets associated with = the previous "m=3D" line will be considered invalid [RFC3550]." >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org]=20 >> Sent: 25 October 2014 16:57 >> To: Christer Holmberg >> Cc: Jonathan Lennox; mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-= lines, or not >>=20 >> Hi, >>=20 >> I suggest that the timeout period be 5 times the RTCP reporting interval= . This is the SSRC timeout interval defined in RFC 3550 section 6.3.5, and = is how long a receiver will consider an SSRC valid if that SSRC stops sendi= ng and it's RTCP BYE is lost. >>=20 >> Colin >>=20 >>=20 >>=20 >> On 24 Oct 2014, at 20:36, Christer Holmberg wrote: >>> Hi, >>>=20 >>> What about: >>>=20 >>> "A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets as= sociated with different "m=3D" lines. There needs to be a time period, long= enough to make sure there are no packets associate with the previous "m=3D= " line in the network, before the SSRC starts to transmit RTP/RTCP packets = associated with a new "m=3D" line." >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >>> Sent: 24 October 2014 22:29 >>> To: Christer Holmberg >>> Cc: mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m= -lines, or not >>>=20 >>> My worry is that your text (as modified to include RTCP), interpreted l= iterally, would be too constraining for very-long-lived sessions, where you= might have used an SSRC on one m-line three weeks ago, and now you need to= remember it forever so you don't reuse that same value on a different one.= =20 >>>=20 >>> On Oct 24, 2014, at 3:24 PM, Christer Holmberg wrote: >>>=20 >>>> Hi, >>>>=20 >>>> So, is the text I suggested ok, or do you want to write something else= ? >>>>=20 >>>> If would be good if we could add the text to the bullet list in the RT= P Considerations section. But, if you think it requires more text, we'll pu= t it somewhere else. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> -----Original Message----- >>>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >>>> Sent: 24 October 2014 21:38 >>>> To: Christer Holmberg >>>> Cc: mmusic >>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled = m-lines, or not >>>>=20 >>>> Right. >>>>=20 >>>> The case my "twice the MSL" text is designed to handle is the case whe= re an SSRC leaves (sends RTCP bye), and then the sender spins up another SS= RC on a different mid, and happens to pick the same SSRC value. This shoul= dn't happen very often (1 in 2^32) if SSRC randomization is implemented pro= perly, but sometimes people use bad random number generators (or are, e.g.,= playing games with not renumbering at a source projecting mixer). This is= n't an SSRC collision, technically, since for the sender the old source is = gone, but if old packets with the old mid are still lingering in the networ= k, you'll get confused. Thus my recommendation to make sure you wait befor= e you reuse SSRC values. >>>>=20 >>>> On Oct 24, 2014, at 12:07 PM, Christer Holmberg wrote: >>>>=20 >>>>> ...and, obviously the SSRC would also always use the same MID in the = RTCP SDES MID item. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> -----Original Message----- >>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer H= olmberg >>>>> Sent: 24 October 2014 19:01 >>>>> To: Jonathan Lennox; mmusic >>>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled= m-lines, or not >>>>>=20 >>>>> Hi Jonathan, >>>>>=20 >>>>> In the RTP Considerations section, we currently have the following te= xt: >>>>>=20 >>>>> "A given SSRC MUST NOT transmit RTP packets using payload types that= =20 >>>>> originate from different bundled "m=3D" lines." >>>>>=20 >>>>> That doesn't cover what you are talking about, but perhaps we could a= dd a statement saying something like: >>>>>=20 >>>>> "A given SSCR MUST NOT transmit RTP packets associated with differen= t "m=3D" lines. When >>>>> the RTP MID header extension is used, the SSRC MUST use the same 'mi= d' value in every >>>>> RTP packet." >>>>>=20 >>>>> ...or something like that. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan L= ennox >>>>> Sent: 24 October 2014 17:50 >>>>> To: mmusic >>>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled= m-lines, or not >>>>>=20 >>>>> One issue which I've brought up a number of times in BUNDLE is whethe= r it's valid for an RTP stream to move between bundled m-lines, or be share= d between several bundled m-lines. >>>>>=20 >>>>> While (as I've described) there are a number of useful features that = this could enable, it sounded at the last IETF meeting that people weren't = interested in the complexity it introduces. (It's certainly something that= wouldn't be possible with unbundled m-lines.) As such, I think BUNDLE nee= ds to document that this isn't allowed. >>>>>=20 >>>>> As such, I suggest adding to the section on MID something like: >>>>>=20 >>>>> RTP streams MUST NOT be moved between media descriptions. If a MID i= s communicated for an RTP stream, that stream's SSRC MUST NOT be reused for= another RTP stream with a different MID value until at least twice the Max= imum Segment Lifetime (MSL) has elapsed since the last time a packet (RTP o= r RTCP) was sent for the old stream. >>>>>=20 >>>>> This makes sure that stuck packets in the network can't confuse a str= eam's MID association. >>>>>=20 >>>>> If people *do* want the ability to move streams between m-lines, we w= ill need some more complicated rules, which I could try to draft if people = are interested. >>>>> _______________________________________________ >>>>> 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 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Sun Oct 26 06:53:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23721A87AB for ; Sun, 26 Oct 2014 06:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_bS5PwO8jQA for ; Sun, 26 Oct 2014 06:53:29 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11A11A87A9 for ; Sun, 26 Oct 2014 06:53:28 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-40-544cfcd639d1 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C6.35.24955.6DCFC445; Sun, 26 Oct 2014 14:53:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Sun, 26 Oct 2014 14:53:26 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" , "Stach, Thomas" Thread-Topic: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits- "requested address" to "suggested address" Thread-Index: Ac/xJB2FCQGRlEDfTzS5mfV9gLK7Vg== Date: Sun, 26 Oct 2014 13:53:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C9B7B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje61Pz4hBv0dphZTlz9msVix4QCr xcmd25gdmD3+vv/A5LFkyU8mj+09j1kCmKO4bFJSczLLUov07RK4MtZO2cJSMEm34vinV0wN jG+Uuhg5OCQETCQWvdDtYuQEMsUkLtxbz9bFyMUhJHCEUeLXgxesEM4SRome47/ZQBrYBCwk uv9pgzSICFRKnF08nQWkRlhgMqPEvEPLmEAcEYEpjBITlq1ihKjSk9h78SITiM0ioCoxufE+ O4jNK+ArcfjVARYQmxFo9fdTa8BqmAXEJW49mc8EcZKAxJI955khbFGJl4//sULYShKLbn+G qteRWLD7ExuErS2xbOFrZoj5ghInZz5hmcAoPAvJ2FlIWmYhaZmFpGUBI8sqRtHi1OKk3HQj Y73Uoszk4uL8PL281JJNjMBoOLjlt+oOxstvHA8xCnAwKvHwGlzxCRFiTSwrrsw9xCjNwaIk zrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYy8W//d/t1y4J+iNtff0HVvTswUkw94 fZJJjN1xmevrF5yJ/jtteO3UpnmVhv3+lLLT3de4IcNw/bSg7xw7r25w0ll58NfOOR98bbco b1mwJ/nrLcbNP98sfPt6guyTgIrwqMmpOUHb21lfL53FM3WzzUz9t2krhfaW3nW6MM26y6z2 X5l47L1eJZbijERDLeai4kQAzW0nU2cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f8RqW_htSnNrHugl-EQU0ba4SWg Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits- "requested address" to "suggested address" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 13:53:33 -0000 Hi, I went through the document, and identified the following paragraphs/bullet= s that would be affected by talking about "suggesting a BUNDLE address" ins= tead of "requesting a BUNDLE address". Section 8.2.1: ------------------ OLD: o Indicate which unique address the offerer wants the answerer to select as the offerer BUNDLE address [Section 8.2.2]. NEW: o Indicate which unique address the offerer suggests=20 as the offerer BUNDLE address [Section 8.2.2]. Section 8.2.2: ------------------ OLD: In the offer, the address assigned to the "m=3D" line associated with the offerer suggested BUNDLE mid indicates the address that the offerer wants the answer to select as the offerer BUNDLE address [Section 8.3.2]. NEW: In the offer, the address assigned to the "m=3D" line associated with the offerer suggested BUNDLE mid indicates the address that the offerer suggests as the offerer BUNDLE address [Section 8.3.2]. Section 8.3.2: ------------------ OLD: In an offer, the address (unique or shared) assigned to the bundled "m=3D" line associated with the offerer suggested BUNDLE mid indicates the address that the offerer wants the answer to select as the offerer BUNDLE address [Section 8.2.2]. The answerer MUST check whether that "m=3D" line fulfills the following criteria: NEW: In an offer, the address (unique or shared) assigned to the bundled "m=3D" line associated with the offerer suggested BUNDLE mid indicates the address that the offerer suggests as the offerer BUNDLE address [Section 8.2.2]. The answerer MUST check whether that "m=3D" line fulfills the following criteria: Section 8.5.1: ------------------ OLD: o The offerer wants to request the answerer to select a new offerer BUNDLE address [Section 8.5.2]; NEW: o The offerer suggests a new offerer BUNDLE address [Section 8.5.2]; OLD: In addition, the offerer MUST select an offerer suggested BUNDLE mid [Section 8.2.2], even if the offerer does not want the answerer to select a new offerer BUNDLE address. NEW: In addition, the offerer MUST select an offerer suggested BUNDLE mid=20 [Section 8.2.2], even if the offerer does not suggest a new offerer BUNDLE= address. Section 8.5.2: ------------------ OLD: When an offerer generates an offer, in which it wants the answerer to select a new offerer BUNDLE address [Section 8.2.2], the offerer MUST: NEW: When an offerer generates an offer, in which it suggests a new offerer BUNDLE address [Section 8.2.2], the offerer MUST: OLD: o Assign a unique address, which the offerer wants the answerer to select as the offerer BUNDLE address, to a bundled "m=3D" line; and NEW: o Assign a unique address, which the offerer suggests as the=20 new offerer BUNDLE address, to a bundled "m=3D" line; and OLD: o Indicate that the offerer wants the answerer to select the unique address as the offerer BUNDLE address [Section 8.2.2] NEW: o Indicate that the offerer suggests the unique address as the=20 new offerer BUNDLE address [Section 8.2.2] OLD: NOTE: The offerer can assign a unique address to each bundled "m=3D" line in the offer, or it can assign the previously negotiated offerer BUNDLE address to each "m=3D" line (except the "m=3D" line to which it assigns the unique address that it wants the answerer to select as the new offerer BUNDLE address). =20 NEW: NOTE: The offerer can assign a unique address to each bundled "m=3D" line in the offer, or it can assign the previously negotiated offerer BUNDLE address to each "m=3D" line (except to the "m=3D" line to which it assigns the unique address that it suggests as the new offerer BUNDLE address). Section 8.5.3: ------------------ OLD: If the offerer wants the answerer to select the address associated with the added "m=3D" line as the new offerer BUNDLE address, the offerer suggested BUNDLE mid MUST represent the added "m=3D" line [Section 8.2.2]. NEW: If the offerer suggests the address associated with the added "m=3D"=20 line as the new offerer BUNDLE address, the offerer suggested=20 BUNDLE mid MUST represent the added "m=3D" line [Section 8.2.2]. So, as you can see, it's not just about changing a couple of words in a tit= le... Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 24 October 2014 19:16 To: mmusic@ietf.org Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotia= tion-12 - Editorial nits On 10/24/14 11:44 AM, Christer Holmberg wrote: > Hi, > >>>> Section 8.2.2. Request offerer BUNDLE address selection I can't=20 >>>> parse that caption. >>> >>> Based on Paul's review, I suggest to change that to "Request the=20 >>> offerer BUNDLE address". >> [TS] I think this caption does exactly reflect semantics of what's=20 >> going on in that paragraph. >> >> The offerer does not request a BUNDLE address, it is rather a suggestion= . >> What about "Suggesting the offerer BUNDLE address" > > We would have to go through the text and make sure it doesn't cause misal= igned terminology. > > In addition, there is a section named "Request a new offerer BUNDLE addre= ss", which we also would have to change. It seems that Thomas had the same problem with the title that I did, and ar= rived at the same proposed solution. So I'm in favor of making this change, and then touching up other text if n= ecessary. Thanks, Paul From nobody Sun Oct 26 09:11:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F171A0102 for ; Sun, 26 Oct 2014 09:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTmy-5X07kA6 for ; Sun, 26 Oct 2014 09:11:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C621A00C3 for ; Sun, 26 Oct 2014 09:11:04 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-26-544d1d16169b Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.5B.24955.61D1D445; Sun, 26 Oct 2014 17:11:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Sun, 26 Oct 2014 17:11:02 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Paul Kyzivat" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: Ac/uuCRoxa2wDi0XTrmXWBalhgDJLQAFclAAAAe3mAAAkmUGQA== Date: Sun, 26 Oct 2014 16:11:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C9DC9@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> 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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja6YrG+IwaxV1hZTlz9msVix4QCr RcPGK6wOzB6tz/ayevx9/4HJY8mSn0wBzFFcNimpOZllqUX6dglcGfN/nGAqOMNZcWvOW6YG xpvsXYycHBICJhJ9d34wQ9hiEhfurWfrYuTiEBI4wihxtfUlG0hCSGAJo8TJ/XZdjBwcbAIW Et3/tEFqRASmMEpsXXCFEaRGWMBB4ufUXWCDRAQcJeY0L2aFsJ0k1k9bBRZnEVCVeHbjGthi XgFfieNfj7JDLDvPKDH/cBcTyAJOgViJ12tlQGoYgQ76fmoNE4jNLCAucevJfCaIQwUkluw5 D3W0qMTLx/9YIWwlicYlT1gh6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaSlllI WmYhaVnAyLKKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzB2Dm75rbqD8fIbx0OMAhyMSjy8 Bld8QoRYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PziU/3 syPOJvwrn9H0I987mnHlDsWnSYG5fjtf+Ybnfdn6rrr1UI9T1fFczZPnrW5MZK1nzWPvT2XN TE9VuT7HSGntL/bIh1qfeJ+0soTtWq8StFhk9ebrF/tSd7nZff7GcuZ56IVwv+P+vbMPZOWr vSjcnOqzvkRu7TE9w2gzm0TD3mcmZkosxRmJhlrMRcWJAMD63kV+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/VFeFDuxCui-mu6Vvl4ghAOiJtR0 Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 16:11:08 -0000 Hi, >> * Section 5.1.1.1 >>=20 >> The following seems overly stringent: >>=20 >> The SDP answer shall include the exact same attribute line to >> indicate acceptance of the data channel instance. >>=20 >> This seems to require a byte-by-byte copy. That precludes=20 >> independently generating an equivalent attribute. ISTM it is=20 >> sufficient to require the attribute in the answer to meet the same=20 >> requirements as that in the offer, and to have the same channel=20 >> number. (And label???) > > > Correct. In theory a simple answer of "a=3Ddcamp:2" is sufficient (especi= ally since we are now going to=20 > make "subprotocol" as optional) to indicating acceptance of that particul= ar data channel. > However, to make it consistent with rest of the SDP style, we will change= the text to indicate subprotocol=20 > parameter MUST be included in answer with an optional label (matching or = non-matching). They may appear in any order. I am not sure whether you need to say anything about this. How to create the answer is a generic text, and there is already procedure = text in section 5.1.1 draft-ejzak-mmusic-data-channel-sdpneg-01 for this. Regards, Christer From nobody Sun Oct 26 10:27:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230DA1A0252 for ; Sun, 26 Oct 2014 10:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNpuXZp_EUnU for ; Sun, 26 Oct 2014 10:27:22 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD24E1A01AE for ; Sun, 26 Oct 2014 10:27:22 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id ED11667294E; Sun, 26 Oct 2014 17:27:16 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9QHRJ2g025445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Oct 2014 13:27:19 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 13:27:19 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: AQHP7t66dy5ZGL+nPEG/1c9gL4hdCZw+EJjQgATDl4D//8+KcA== Date: Sun, 26 Oct 2014 17:27:18 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B266CF1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54492D34.5030705@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C9DC9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C9DC9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/oplRwLvbarg-gpf-hkA6ygLq55w Subject: Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 17:27:24 -0000 Hi Christer, > > > > Correct. In theory a simple answer of "a=3Ddcamp:2" is sufficient > (especially since we are now going to > > make "subprotocol" as optional) to indicating acceptance of that > particular data channel. > > However, to make it consistent with rest of the SDP style, we will chan= ge > the text to indicate subprotocol > > parameter MUST be included in answer with an optional label (matching o= r > non-matching). They may appear in any order. >=20 > I am not sure whether you need to say anything about this. >=20 > How to create the answer is a generic text, and there is already procedur= e > text in section 5.1.1 draft-ejzak-mmusic-data-channel-sdpneg-01 for this. I agree that the procedural text belongs to draft-ejzak-mmusic-data-channel= -sdpneg. However, some clarifications are missing there as well. So, we will add it = to that draft. Thanks Raju From nobody Sun Oct 26 12:48:25 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96611A1A6B for ; Sun, 26 Oct 2014 12:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUWdsg5zhVvM for ; Sun, 26 Oct 2014 12:48:22 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6E91A1A65 for ; Sun, 26 Oct 2014 12:48:21 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x13so567319wgg.32 for ; Sun, 26 Oct 2014 12:48:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=JUIf0OgtCD/7nq+BwkicaoyvIyjP1+evz73xuLIi/oM=; b=Rq0ZxcOGwz0tnQRDCMDoVPvzGSCR48N3VUK+/Kb4xJYMxr0AZKeRd2oNy5h3H4QGCW P+YAA0/4+lzeXUvUkURBFZj2puBxMRnMo7bUEFhSHuyLzaNFi+Ijfcwc4uwUjfCcKhne hrRPcp62OccEwi4FVT5ABLpw6nEYawILQ1VDRbAMApDmaAxfLienHyW8dy+UU5+ckY3m on+PVYaQI8pHP91pjdvvY521dUEDVzPe7i8W2vhIs9UBcwuQjx8hwTDRlU5i40BM1Grq ATNbSVqljDK6EY6e3EAD0vPv0pPQ9W9Bt8ku9DN5ya3MPU8mzTn3Jpew6y0da9GgiskE CIsw== X-Gm-Message-State: ALoCoQmK3qm+AuJ63TJBAp/jA2iBRVULI9CNGDyHTawuv6GxycZ82gMDyW+//zqfnMhTT6WQUn5I X-Received: by 10.180.219.106 with SMTP id pn10mr16966092wic.63.1414352900144; Sun, 26 Oct 2014 12:48:20 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com. [74.125.82.43]) by mx.google.com with ESMTPSA id lm9sm13065982wjc.45.2014.10.26.12.48.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 12:48:18 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id n12so4288422wgh.14 for ; Sun, 26 Oct 2014 12:48:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.20.19 with SMTP id j19mr16399939wie.43.1414352898547; Sun, 26 Oct 2014 12:48:18 -0700 (PDT) Received: by 10.216.176.65 with HTTP; Sun, 26 Oct 2014 12:48:18 -0700 (PDT) Date: Sun, 26 Oct 2014 15:48:18 -0400 Message-ID: From: Roman Shpount To: Christer Holmberg , "Hutton, Andrew" , "Ari Ker?nen" , Eric Rescorla , Jonathan Lennox , lemming Andreasen Content-Type: multipart/alternative; boundary=bcaec53d55eb1ae71a050658b2cb Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xgAViD6EBWyS8pvy04b5JbTtQNA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Revisit consensus ? [Re: ICE updated offer - Back to the initial question] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 19:48:24 -0000 --bcaec53d55eb1ae71a050658b2cb Content-Type: text/plain; charset=UTF-8 I believe that whether a new offer needs to be sent after ICE negotiation completes should be indicated in both offer and answer. New offer is sent by the controlling ICE agent and it can be on either side of offer/answer exchange. I would suggest that not sending an additional offer should be indicated in SIP options in Supported/Require headers and negotiated by both sides of offer/answer exchange. _____________ Roman Shpount --bcaec53d55eb1ae71a050658b2cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe that whether a new offer needs to be sent after = ICE negotiation completes should be indicated in both offer and answer. New= offer is sent by the controlling ICE agent and it can be on either side of= offer/answer exchange. I would suggest that not sending an additional offe= r should be indicated in SIP options in Supported/Require headers and negot= iated by both sides of offer/answer exchange.

_____________
Roman Shpount

--bcaec53d55eb1ae71a050658b2cb-- From nobody Sun Oct 26 13:33:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EC61A1A95; Sun, 26 Oct 2014 13:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIb368pveHG3; Sun, 26 Oct 2014 13:33:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EF91A1A85; Sun, 26 Oct 2014 13:33:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026203300.23513.7424.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 13:33:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/F2SYxA-LAcmzyNbgMiYdW4heWos Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 20:33:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Authors : Ari Keranen Jonathan Rosenberg Filename : draft-ietf-mmusic-rfc5245bis-03.txt Pages : 89 Date : 2014-10-26 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc5245bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 26 13:53:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9821A1A03C7 for ; Sun, 26 Oct 2014 13:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUKBUsQjHcpL for ; Sun, 26 Oct 2014 13:53:28 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E491A02F1 for ; Sun, 26 Oct 2014 13:53:26 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-a8-544d5bbe285e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 71.36.21334.EBB5D445; Sun, 26 Oct 2014 21:38:22 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.174.1; Sun, 26 Oct 2014 21:38:21 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 47BD01102AA for ; Sun, 26 Oct 2014 22:38:22 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 83E9A4E941 for ; Sun, 26 Oct 2014 22:40:43 +0200 (EET) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 347E34E695 for ; Sun, 26 Oct 2014 22:40:43 +0200 (EET) Message-ID: <544D5BBC.1090409@ericsson.com> Date: Sun, 26 Oct 2014 22:38:20 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: References: <20141026203300.23513.7424.idtracker@ietfa.amsl.com> In-Reply-To: <20141026203300.23513.7424.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+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvje6+aN8QgxPHjSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK9rJzEVvBGqmLi7k7WB8TpfFyMnh4SAicTalfuYIGwxiQv3 1rN1MXJxCAkcYZRYMOclI4SzgVFi/uffLBDOJUaJhjtN7CAtQgKHGSVmfMqHSOxllFixdgpY gldAW2JVw0cwm0VAVeLzi32sIDabgL3EzQnXweKiAskSa7ZOgqoXlDg58wkLiC0iICrx6OIi sHphAVeJbZ8XsEIsc5DomXqHGcTmFHCU+Lv6ESOIzSxgK3FhznUWCFteYvvbOcwQ/6hJXD23 iRmiV1Xi6r9XjBMYRWYhWTcLSfssJO0LGJlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgQG +sEtv3V3MK5+7XiIUYCDUYmH1+CKT4gQa2JZcWXuIUZpDhYlcd5F5+YFCwmkJ5akZqemFqQW xReV5qQWH2Jk4uCUamDkzi2+2ntq7yvRwBxBvchTWk+Nl+0xizryVDrRXFShf7OUzdwr4TOM 4zR+fxDgPrDOwZTHZ8tpf2/eIDHZH6d1LJ4uWCX+O+SaZ8r6T7Jmp2/1zf3QXrqiS+yV1cwl 8r9fKS52/CXz7N0pceH0ohvaea+zI+ZtS4jW7KzYmvRkduBMg1D2AzeUWIozEg21mIuKEwG2 xveuVQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/SYLf7UMuNto0okxnvYIy-eqxLwI Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 20:53:29 -0000 Hi all, FYI; this version has the following updates discussed at and after the previous meeting: * Clarified in terminology about ICE offer/answer that RFC3264 o/a is just one way to do it * Recommending for non-RTP sessions that Component IDs start with one and increase by 1 from there * Restored recommendations about ICE restarts (must change uname/password, etc.) * Small editorial fixes Cheers, Ari On 10/26/14 10:33 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 : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols > Authors : Ari Keranen > Jonathan Rosenberg > Filename : draft-ietf-mmusic-rfc5245bis-03.txt > Pages : 89 > Date : 2014-10-26 > > Abstract: > This document describes a protocol for Network Address Translator > (NAT) traversal for UDP-based multimedia sessions established with > the offer/answer model. This protocol is called Interactive > Connectivity Establishment (ICE). ICE makes use of the Session > Traversal Utilities for NAT (STUN) protocol and its extension, > Traversal Using Relay NAT (TURN). ICE can be used by any protocol > utilizing the offer/answer model, such as the Session Initiation > Protocol (SIP). > > This document obsoletes RFC 5245. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc5245bis-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 nobody Sun Oct 26 16:37:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0181A1B26 for ; Sun, 26 Oct 2014 16:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeGA_hG_INzN for ; Sun, 26 Oct 2014 16:36:56 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DBF1A1B13 for ; Sun, 26 Oct 2014 16:36:56 -0700 (PDT) Received: from [81.187.2.149] (port=35316 helo=[192.168.0.24]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XiXMj-0004LH-5i; Sun, 26 Oct 2014 23:36:54 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Colin Perkins X-Mailer: iPad Mail (12B410) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C8476@ESESSMB209.ericsson.se> Date: Sun, 26 Oct 2014 23:36:49 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <50DC916E-314A-4203-AF44-A38058EE039B@csperkins.org> References: <5436E6F2.2010202@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D4C6383@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C63E9@ESESSMB209.ericsson.se> <430DF63F-0868-4EC8-8E21-5F0CB318B73D@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C6746@ESESSMB209.ericsson.se> <1E190BB3-BB89-423A-AD2A-DC5AAD7CA1F3@vidyo.com> <7594FB04B1934943A5C02806D1A2204B1D4C67AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8201@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C830D@ESESSMB209.ericsson.se> <833C4F60-7CBF-441B-965C-F87B64E74B94@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1D4C8476@ESESSMB209.ericsson.se> To: Christer Holmberg X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/haB4ZurHhAKsSsWTRwsofFHTGfQ Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-lines, or not X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2014 23:36:59 -0000 Sure, that looks okay. --=20 Colin Perkins http://csperkins.org/ > On 25 Oct 2014, at 18:39, Christer Holmberg wrote: >=20 > Hi, >=20 > What about? >=20 > "A given SSRC MUST, at any given time, only transmit RTP/RTCP packets asso= ciated with a single "m=3D" line. An SSRC can leave the session and re-join u= nder a different "m=3D" line. If the SSRC does that, after it has sent an RT= CP BYE packet [RFC3550], it MUST wait for a timeout interval of 5 times the R= TCP reporting interval before it starts to transmit RTP/RTCP packets associa= ted with the new "m=3D" line. The RTCP BYE packet and the timeout interval e= nsure that any remaining packets and state associated with the SSRC on the p= revious "m=3D" line will be considered invalid [RFC3550]." >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: 25 October 2014 18:03 > To: Christer Holmberg > Cc: Jonathan Lennox; mmusic > Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-li= nes, or not >=20 > Hi, >=20 > You could say "...it has to first send an RTCP BYE following the rules in s= ection 6.3.7 of RFC3550, then it MUST wait for a timeout..."? >=20 > Colin >=20 >> On 25 Oct 2014, at 15:56, Christer Holmberg wrote: >> Hi Colin, >>=20 >> Your suggested text looks good. But, doesn't RFC 3550 specify the sending= of RTCP BYE for leaving a session? If so, I don't think we should use "MUST= " in the BUNDLE draft. We should simply indicate that a RTCP BYE is sent. >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org]=20 >> Sent: 25 October 2014 17:37 >> To: Christer Holmberg >> Cc: Jonathan Lennox; mmusic >> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-l= ines, or not >>=20 >> Hi, >>=20 >> Possibly, although that suggests that an SSRC can switch m=3D lines, wher= eas what happens is that the SSRC leaves the session and re-joins as a diffe= rent m=3D line. Perhaps: >>=20 >> A given SSRC MUST, at any given time, only transmit RTP/RTCP packets asso= ciated with a single "m=3D" line. An SSRC can leave the session and rejoin u= nder a different "m=3D" line, however to do so it MUST send an RTCP BYE pack= et, then MUST wait for a timeout interval of 5 times the RTCP reporting inte= rval, before the SSRC starts to transmit RTP/RTCP packets associated with th= e new "m=3D" line. The RTCP BYE and timeout interval ensure that any remaini= ng packets and state associated with the SSRC on the previous "m=3D" line wi= ll be considered invalid [RFC3550]. >>=20 >> Colin >>=20 >>=20 >>=20 >>> On 25 Oct 2014, at 15:28, Christer Holmberg wrote: >>> Hi Colin, >>>=20 >>> Thanks for your input. >>>=20 >>> So, perhaps something like: >>>=20 >>> A given SSRC MUST, at any given time, only transmit RTP/RTCP packets ass= ociated with a single "m=3D" line. If the SSRC wants to switch "m=3D" line, t= here MUST be a timeout interval of 5 times the RTCP reporting interval befor= e the SSRC starts to transmit RTP/RTCP packets associated with the new "m=3D= " line, as that will ensure that any remaining packets associated with the p= revious "m=3D" line will be considered invalid [RFC3550]." >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> -----Original Message----- >>> From: Colin Perkins [mailto:csp@csperkins.org]=20 >>> Sent: 25 October 2014 16:57 >>> To: Christer Holmberg >>> Cc: Jonathan Lennox; mmusic >>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m-= lines, or not >>>=20 >>> Hi, >>>=20 >>> I suggest that the timeout period be 5 times the RTCP reporting interval= . This is the SSRC timeout interval defined in RFC 3550 section 6.3.5, and i= s how long a receiver will consider an SSRC valid if that SSRC stops sending= and it's RTCP BYE is lost. >>>=20 >>> Colin >>>=20 >>>=20 >>>=20 >>>> On 24 Oct 2014, at 20:36, Christer Holmberg wrote: >>>> Hi, >>>>=20 >>>> What about: >>>>=20 >>>> "A given SSCR MUST NOT, at any given time, transmit RTP/RTCP packets as= sociated with different "m=3D" lines. There needs to be a time period, long e= nough to make sure there are no packets associate with the previous "m=3D" l= ine in the network, before the SSRC starts to transmit RTP/RTCP packets asso= ciated with a new "m=3D" line." >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> -----Original Message----- >>>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >>>> Sent: 24 October 2014 22:29 >>>> To: Christer Holmberg >>>> Cc: mmusic >>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m= -lines, or not >>>>=20 >>>> My worry is that your text (as modified to include RTCP), interpreted l= iterally, would be too constraining for very-long-lived sessions, where you m= ight have used an SSRC on one m-line three weeks ago, and now you need to re= member it forever so you don't reuse that same value on a different one.=20 >>>>=20 >>>>> On Oct 24, 2014, at 3:24 PM, Christer Holmberg wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> So, is the text I suggested ok, or do you want to write something else= ? >>>>>=20 >>>>> If would be good if we could add the text to the bullet list in the RT= P Considerations section. But, if you think it requires more text, we'll put= it somewhere else. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> -----Original Message----- >>>>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]=20 >>>>> Sent: 24 October 2014 21:38 >>>>> To: Christer Holmberg >>>>> Cc: mmusic >>>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled m= -lines, or not >>>>>=20 >>>>> Right. >>>>>=20 >>>>> The case my "twice the MSL" text is designed to handle is the case whe= re an SSRC leaves (sends RTCP bye), and then the sender spins up another SSR= C on a different mid, and happens to pick the same SSRC value. This shouldn= 't happen very often (1 in 2^32) if SSRC randomization is implemented proper= ly, but sometimes people use bad random number generators (or are, e.g., pla= ying games with not renumbering at a source projecting mixer). This isn't a= n SSRC collision, technically, since for the sender the old source is gone, b= ut if old packets with the old mid are still lingering in the network, you'l= l get confused. Thus my recommendation to make sure you wait before you reu= se SSRC values. >>>>>=20 >>>>>> On Oct 24, 2014, at 12:07 PM, Christer Holmberg wrote: >>>>>>=20 >>>>>> ...and, obviously the SSRC would also always use the same MID in the R= TCP SDES MID item. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer H= olmberg >>>>>> Sent: 24 October 2014 19:01 >>>>>> To: Jonathan Lennox; mmusic >>>>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled= m-lines, or not >>>>>>=20 >>>>>> Hi Jonathan, >>>>>>=20 >>>>>> In the RTP Considerations section, we currently have the following te= xt: >>>>>>=20 >>>>>> "A given SSRC MUST NOT transmit RTP packets using payload types th= at=20 >>>>>> originate from different bundled "m=3D" lines." >>>>>>=20 >>>>>> That doesn't cover what you are talking about, but perhaps we could a= dd a statement saying something like: >>>>>>=20 >>>>>> "A given SSCR MUST NOT transmit RTP packets associated with differ= ent "m=3D" lines. When >>>>>> the RTP MID header extension is used, the SSRC MUST use the same '= mid' value in every >>>>>> RTP packet." >>>>>>=20 >>>>>> ...or something like that. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan L= ennox >>>>>> Sent: 24 October 2014 17:50 >>>>>> To: mmusic >>>>>> Subject: Re: [MMUSIC] WGLC for bundle: Moving sources between bundled= m-lines, or not >>>>>>=20 >>>>>> One issue which I've brought up a number of times in BUNDLE is whethe= r it's valid for an RTP stream to move between bundled m-lines, or be shared= between several bundled m-lines. >>>>>>=20 >>>>>> While (as I've described) there are a number of useful features that t= his could enable, it sounded at the last IETF meeting that people weren't in= terested in the complexity it introduces. (It's certainly something that wo= uldn't be possible with unbundled m-lines.) As such, I think BUNDLE needs t= o document that this isn't allowed. >>>>>>=20 >>>>>> As such, I suggest adding to the section on MID something like: >>>>>>=20 >>>>>> RTP streams MUST NOT be moved between media descriptions. If a MID i= s communicated for an RTP stream, that stream's SSRC MUST NOT be reused for a= nother RTP stream with a different MID value until at least twice the Maximu= m Segment Lifetime (MSL) has elapsed since the last time a packet (RTP or RT= CP) was sent for the old stream. >>>>>>=20 >>>>>> This makes sure that stuck packets in the network can't confuse a str= eam's MID association. >>>>>>=20 >>>>>> If people *do* want the ability to move streams between m-lines, we w= ill need some more complicated rules, which I could try to draft if people a= re interested. >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>>=20 >>>=20 >>> --=20 >>> Colin Perkins >>> https://csperkins.org/ >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 From nobody Mon Oct 27 03:25:46 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E581A9045; Mon, 27 Oct 2014 03:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLDQpcZInswP; Mon, 27 Oct 2014 03:25:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A80551A8F4D; Mon, 27 Oct 2014 03:25:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027102537.824.26699.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 03:25:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/H7dcm1XPpfqZhPfC9ynJltoJIUY Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:25:39 -0000 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 : Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Filename : draft-ietf-mmusic-ice-sip-sdp-04.txt Pages : 41 Date : 2014-10-27 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 04:44:05 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7521A8A0C for ; Mon, 27 Oct 2014 04:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9ReUgxC9dP3 for ; Mon, 27 Oct 2014 04:44:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0408D1A1B11 for ; Mon, 27 Oct 2014 04:43:59 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-19-544e2ffd7ffd Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 75.18.04387.DFF2E445; Mon, 27 Oct 2014 12:43:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 12:43:56 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE WGLC: Default candidate for bundle-only m- line with zero port value? Thread-Index: Ac/x2ZqcVHhXpFAJTrS4t9o7Pnz+rg== Date: Mon, 27 Oct 2014 11:43:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CCBC1@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4CCBC1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje4/fb8Qg5Yl7BZTlz9msTi5cxuz A5PHkiU/mTy29zxmCWCK4rJJSc3JLEst0rdL4Mq413aZqeCvacWbO9+ZGxin6ncxcnJICJhI HJ88kQXCFpO4cG89WxcjF4eQwBFGia9/ZjJBOEsYJQ68P8rexcjBwSZgIdH9TxukQURAXeLr 3h5mEJtZQEdi0cdNYLawQLjEpz3XmCFqYiT2z3vBDmHrSTxfs4kNZAyLgKrE7v05IGFeAV+J a+3rwG5gBLrh+6k1TBAjxSVuPZnPBHGbgMSSPeeZIWxRiZeP/7FC2IoS7U8bGCHq8yUmrTnE DDFTUOLkzCcsExiFZyEZNQtJ2SwkZbOgPliw+xMbhK0tsWzha2YY+8yBx0zI4gsY2Vcxihan FhfnphsZ6aUWZSYXF+fn6eWllmxiBEbPwS2/rXYwHnzueIhRgINRiYf3Q41viBBrYllxZe4h RmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNzgxCXRtP6Fn7a1G//Pxxx/ PlznubXBhF9BTObrVhPTOQdeFfOzCts/nuqd2FKpvijEKPNglePmP4msmzhY1nNPb/+zSFXs G5OcFo+xq2jXAm6tohrRPzM61wkvsjv66Vyx0JHbfJerJof1CW0tKRKMa9/bxnTDf1lqatZa IZat21Uc+x/yK7EUZyQaajEXFScCAF/gzSN/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4QitKAj_kPwoQJm_yCcGnslNXpQ Subject: [MMUSIC] BUNDLE WGLC: Default candidate for bundle-only m- line with zero port value? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 11:44:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4CCBC1ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One question that has been raised by Thomas Stach during the BUNDLE WGLC, i= s regarding ICE candidates and bundle-only m- lines with a zero port value. The current text says that identical ICE candidate values are assigned to b= undle-only m- lines. Now, in the case where a zero port value is assigned to a bundle-only m- li= nes, it means that a candidate with a zero port value is also needed (in or= der to fulfil the ICE rules for default candidates). IF we want to avoid that, a couple of alternatives have been presented: 1) Do not assign ICE candidates to bundle-only m- lines with port zero= . The problem is that the answerer, even if it supports BUNDLE/bundle-only,= doesn't know whether the offerer wants to use ICE for those m- lines; or 2) Relax the 5245 rules, so that there doesn't need to be a candidate = matching the m- line port value. Comments? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4CCBC1ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One question that has been raised by Thomas Stach du= ring the BUNDLE WGLC, is regarding ICE candidates and bundle-only m- lines = with a zero port value.

 

The current text says that identical ICE candidate v= alues are assigned to bundle-only m- lines.

 

Now, in the case where a zero port value is assigned= to a bundle-only m- lines, it means that a candidate with a zero port valu= e is also needed (in order to fulfil the ICE rules for default candidates).=

 

IF we want to avoid that, a couple of alternatives h= ave been presented:

 

1)      Do not assign ICE candidates to bundle-only m- line= s with port zero. The problem is that the answerer, even if it supports BUN= DLE/bundle-only, doesn’t know whether the offerer wants to use ICE fo= r those m- lines; or

2)      Relax the 5245 rules, so that there doesn’t n= eed to be a candidate matching the m- line port value.

 

Comments?

 

Regards,

 

Christer

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D4CCBC1ESESSMB209erics_-- From nobody Mon Oct 27 07:39:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3171A87DE for ; Mon, 27 Oct 2014 07:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1k00R3BFqX4 for ; Mon, 27 Oct 2014 07:39:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984B61A87D7 for ; Mon, 27 Oct 2014 07:39:22 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 5C185E2715EB0 for ; Mon, 27 Oct 2014 14:39:18 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s9REdGZv027102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Oct 2014 15:39:20 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 15:39:18 +0100 From: "DRAGE, Keith (Keith)" To: "mmusic@ietf.org" Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: Ac/x88lK6mpn4HE9TuemRholN7+6tQ== Date: Mon, 27 Oct 2014 14:39:18 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/XATOmIu5OQ9x3IluSzKV5c_MMyw Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 14:39:25 -0000 Based on the discussion on list over the last few days, I have submitted re= vised versions of the two SDP negotiation over data channel drafts as follo= ws: A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Name: draft-ejzak-mmusic-data-channel-sdpneg Revision: 02 Title: SDP-based "SCTP over DTLS" data channel negotiation Document date: 2014-10-27 Group: Individual Submission Pages: 22 URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data= -channel-sdpneg-02.txt Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-ch= annel-sdpneg/ Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-= sdpneg-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-= channel-sdpneg-02 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP, where each data channel might be used to transport other protocols, called sub-protocols. Data channel setup can be done using either the internal in-band band (also referred to as 'internal' for the rest of the document) WebRTC Data Channel Establishment Protocol or some external out-of-band simply referred to as 'external negotiation' in the rest of the document . This document specifies how the SDP offer/answer exchange can be used to achieve such an external negotiation. Even though data channels are designed for RTCWeb use initially they may be used by other protocols like, but not limited to, the CLUE protocol. This document is intended to be used wherever data channels are used. A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Name: draft-ejzak-mmusic-msrp-usage-data-channel Revision: 01 Title: MSRP over SCTP/DTLS data channels Document date: 2014-10-27 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp= -usage-data-channel-01.txt Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-us= age-data-channel/ Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-da= ta-channel-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-msrp-= usage-data-channel-01 Abstract: This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the the SDP offer/answer exchange-based external negotiation defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations are documented: a WebRTC end-to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint).= From nobody Mon Oct 27 08:00:49 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE28C1A8852 for ; Mon, 27 Oct 2014 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pKgvH31xUqr for ; Mon, 27 Oct 2014 08:00:01 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 146ED1A878B for ; Mon, 27 Oct 2014 08:00:01 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id CF96323F0430; Mon, 27 Oct 2014 15:59:59 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 15:59:59 +0100 From: "Stach, Thomas" To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits- "requested address" to "suggested address" Thread-Index: Ac/xJB2FCQGRlEDfTzS5mfV9gLK7VgAovFEw Date: Mon, 27 Oct 2014 14:59:59 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C9B7B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C9B7B@ESESSMB209.ericsson.se> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2HMpH-1N2Z-_olsQwMk_LTfqQ_k Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits- "requested address" to "suggested address" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 15:00:05 -0000 Christer, as it's more concise, I like the new text better. Thanks for your effort of going through the complete document. Regards=09 Thomas ... well, of course, I still don't like the term "BUNDLE mid", but that's t= he topic of the other thread > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sonntag, 26. Oktober 2014 14:53 > To: Paul Kyzivat; mmusic@ietf.org; Stach, Thomas > Subject: RE: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle- > negotiation-12 - Editorial nits- "requested address" to "suggested addres= s" >=20 > Hi, >=20 > I went through the document, and identified the following paragraphs/bull= ets > that would be affected by talking about "suggesting a BUNDLE address" ins= tead > of "requesting a BUNDLE address". >=20 > Section 8.2.1: > ------------------ >=20 > OLD: >=20 > o Indicate which unique address the offerer wants the answerer to > select as the offerer BUNDLE address [Section 8.2.2]. >=20 > NEW: >=20 > o Indicate which unique address the offerer suggests > as the offerer BUNDLE address [Section 8.2.2]. >=20 >=20 > Section 8.2.2: > ------------------ >=20 > OLD: >=20 > In the offer, the address assigned to the "m=3D" line associated with > the offerer suggested BUNDLE mid indicates the address that the > offerer wants the answer to select as the offerer BUNDLE address > [Section 8.3.2]. >=20 > NEW: >=20 > In the offer, the address assigned to the > "m=3D" line associated with the offerer suggested BUNDLE mid indicate= s > the address that the offerer suggests as the > offerer BUNDLE address [Section 8.3.2]. >=20 >=20 > Section 8.3.2: > ------------------ >=20 > OLD: >=20 > In an offer, the address (unique or shared) assigned to the bundled > "m=3D" line associated with the offerer suggested BUNDLE mid indicate= s > the address that the offerer wants the answer to select as the > offerer BUNDLE address [Section 8.2.2]. The answerer MUST check > whether that "m=3D" line fulfills the following criteria: >=20 > NEW: >=20 > In an offer, the address (unique or shared) assigned to the bundled "m= =3D" > line associated with the offerer suggested BUNDLE mid indicates the > address that the offerer suggests as the > offerer BUNDLE address [Section 8.2.2]. The answerer MUST check > whether that "m=3D" line fulfills the following criteria: >=20 >=20 > Section 8.5.1: > ------------------ >=20 > OLD: >=20 > o The offerer wants to request the answerer to select a new offerer > BUNDLE address [Section 8.5.2]; >=20 > NEW: >=20 > o The offerer suggests a new offerer BUNDLE address [Section 8.5.2]; >=20 >=20 > OLD: >=20 > In addition, the offerer MUST select an offerer suggested BUNDLE mid > [Section 8.2.2], even if the offerer does not want the answerer to > select a new offerer BUNDLE address. >=20 > NEW: >=20 > In addition, the offerer MUST select an offerer suggested BUNDLE mid > [Section 8.2.2], even if the offerer does not suggest a new offerer > BUNDLE address. >=20 >=20 > Section 8.5.2: > ------------------ >=20 > OLD: >=20 > When an offerer generates an offer, in which it wants the answerer to > select a new offerer BUNDLE address [Section 8.2.2], the offerer > MUST: >=20 > NEW: >=20 > When an offerer generates an offer, in which it suggests > a new offerer BUNDLE address [Section 8.2.2], the offerer MUST: >=20 >=20 > OLD: >=20 > o Assign a unique address, which the offerer wants the answerer to > select as the offerer BUNDLE address, to a bundled "m=3D" line; an= d >=20 > NEW: >=20 > o Assign a unique address, which the offerer suggests as the > new offerer BUNDLE address, to a bundled "m=3D" line; and >=20 >=20 > OLD: >=20 > o Indicate that the offerer wants the answerer to select the unique > address as the offerer BUNDLE address [Section 8.2.2] >=20 > NEW: >=20 > o Indicate that the offerer suggests the unique address as the > new offerer BUNDLE address [Section 8.2.2] >=20 >=20 > OLD: >=20 > NOTE: The offerer can assign a unique address to each bundled "m=3D" > line in the offer, or it can assign the previously negotiated offerer > BUNDLE address to each "m=3D" line (except the "m=3D" line to which i= t > assigns the unique address that it wants the answerer to select as > the new offerer BUNDLE address). >=20 > NEW: >=20 > NOTE: The offerer can assign > a unique address to each bundled "m=3D" line in the offer, or it can > assign the previously negotiated offerer BUNDLE address to each "m=3D= " > line (except to the "m=3D" line to which it assigns the unique addres= s > that it suggests as the new offerer BUNDLE address). >=20 >=20 > Section 8.5.3: > ------------------ >=20 > OLD: >=20 > If the offerer wants the answerer to select the address associated > with the added "m=3D" line as the new offerer BUNDLE address, the > offerer suggested BUNDLE mid MUST represent the added "m=3D" line > [Section 8.2.2]. >=20 > NEW: >=20 > If the offerer suggests the address associated with the added "m=3D" > line as the new offerer BUNDLE address, the offerer suggested > BUNDLE mid MUST represent the added "m=3D" line [Section 8.2.2]. >=20 >=20 > So, as you can see, it's not just about changing a couple of words in a > title... >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24 October 2014 19:16 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle- > negotiation-12 - Editorial nits >=20 > On 10/24/14 11:44 AM, Christer Holmberg wrote: > > Hi, > > > >>>> Section 8.2.2. Request offerer BUNDLE address selection I can't > >>>> parse that caption. > >>> > >>> Based on Paul's review, I suggest to change that to "Request the > >>> offerer BUNDLE address". > >> [TS] I think this caption does exactly reflect semantics of what's > >> going on in that paragraph. > >> > >> The offerer does not request a BUNDLE address, it is rather a suggesti= on. > >> What about "Suggesting the offerer BUNDLE address" > > > > We would have to go through the text and make sure it doesn't cause > misaligned terminology. > > > > In addition, there is a section named "Request a new offerer BUNDLE > address", which we also would have to change. >=20 > It seems that Thomas had the same problem with the title that I did, and > arrived at the same proposed solution. >=20 > So I'm in favor of making this change, and then touching up other text if > necessary. >=20 > Thanks, > Paul From nobody Mon Oct 27 11:32:45 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1381ACE35 for ; Mon, 27 Oct 2014 11:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjKUJh9S4V-X for ; Mon, 27 Oct 2014 11:32:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EB11ACEB2 for ; Mon, 27 Oct 2014 11:30:09 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-ea-544e8f2fa88d Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 36.36.24955.F2F8E445; Mon, 27 Oct 2014 19:30:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 19:30:07 +0100 From: Christer Holmberg To: "Stach, Thomas" , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits- "requested address" to "suggested address" Thread-Index: Ac/xJB2FCQGRlEDfTzS5mfV9gLK7VgAovFEwABMm0NA= Date: Mon, 27 Oct 2014 18:30:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CE9A1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4C9B7B@ESESSMB209.ericsson.se> 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.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja5+v1+IQddsA4upyx+zWKzYcIDV 4uTObcwOzB5/339g8liy5CeTx/aexywBzFFcNimpOZllqUX6dglcGW1LWtkLpplVPHh1hKmB 8aNmFyMnh4SAicSm7ctZIGwxiQv31rOB2EICRxglbj7y6GLkArKXMEo823OAtYuRg4NNwEKi +582SI2IQKVE95v1jCA1wgKTGSXmHVrGBOKICExhlJiwbBUjRJWVxOr1+9lAmlkEVCX+rrUE CfMK+Ep8n76GFWLBJEaJrr617CAJTgF/iV/Hu8CuYAS66PupNUwgNrOAuMStJ/OZIC4VkFiy 5zwzhC0q8fLxP1YIW0li0e3PUPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScss JC2zkLQsYGRZxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYPQe3/FbdwXj5jeMhRgEORiUe 3g81viFCrIllxZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxPf2O 7Bk7q9fdeqr3OxZ8ZKv7/IjfuXeixodSt9WTuTo/cgllbtvzdrvN4evKJQ9rZC5Zr9m1bXOp Y25mUVuYmkuq6fPyn9+uhc06cPj8c+0dTSuyPj9nksqYZ99bxcWrvHVmSyRXrN5fJidPHfP/ go+qjPWa5OwNtFgbZ6UWvTv55G3kqsVKLMUZiYZazEXFiQDBZalXfwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Jh82TMC1uYo8Vx2LEBiLuf5XcJ8 Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Editorial nits- "requested address" to "suggested address" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 18:32:23 -0000 Hi, >as it's more concise, I like the new text better. >Thanks for your effort of going through the complete document. So, does anyone have a problem with this change? Once implemented, I will n= ot change it again... Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Sonntag, 26. Oktober 2014 14:53 > To: Paul Kyzivat; mmusic@ietf.org; Stach, Thomas > Subject: RE: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle- > negotiation-12 - Editorial nits- "requested address" to "suggested addres= s" >=20 > Hi, >=20 > I went through the document, and identified the following=20 > paragraphs/bullets that would be affected by talking about "suggesting=20 > a BUNDLE address" instead of "requesting a BUNDLE address". >=20 > Section 8.2.1: > ------------------ >=20 > OLD: >=20 > o Indicate which unique address the offerer wants the answerer to > select as the offerer BUNDLE address [Section 8.2.2]. >=20 > NEW: >=20 > o Indicate which unique address the offerer suggests > as the offerer BUNDLE address [Section 8.2.2]. >=20 >=20 > Section 8.2.2: > ------------------ >=20 > OLD: >=20 > In the offer, the address assigned to the "m=3D" line associated with > the offerer suggested BUNDLE mid indicates the address that the > offerer wants the answer to select as the offerer BUNDLE address > [Section 8.3.2]. >=20 > NEW: >=20 > In the offer, the address assigned to the > "m=3D" line associated with the offerer suggested BUNDLE mid indicate= s > the address that the offerer suggests as the > offerer BUNDLE address [Section 8.3.2]. >=20 >=20 > Section 8.3.2: > ------------------ >=20 > OLD: >=20 > In an offer, the address (unique or shared) assigned to the bundled > "m=3D" line associated with the offerer suggested BUNDLE mid indicate= s > the address that the offerer wants the answer to select as the > offerer BUNDLE address [Section 8.2.2]. The answerer MUST check > whether that "m=3D" line fulfills the following criteria: >=20 > NEW: >=20 > In an offer, the address (unique or shared) assigned to the bundled "m= =3D" > line associated with the offerer suggested BUNDLE mid indicates the > address that the offerer suggests as the > offerer BUNDLE address [Section 8.2.2]. The answerer MUST check > whether that "m=3D" line fulfills the following criteria: >=20 >=20 > Section 8.5.1: > ------------------ >=20 > OLD: >=20 > o The offerer wants to request the answerer to select a new offerer > BUNDLE address [Section 8.5.2]; >=20 > NEW: >=20 > o The offerer suggests a new offerer BUNDLE address [Section 8.5.2]; >=20 >=20 > OLD: >=20 > In addition, the offerer MUST select an offerer suggested BUNDLE mid > [Section 8.2.2], even if the offerer does not want the answerer to > select a new offerer BUNDLE address. >=20 > NEW: >=20 > In addition, the offerer MUST select an offerer suggested BUNDLE mid > [Section 8.2.2], even if the offerer does not suggest a new offerer=20 > BUNDLE address. >=20 >=20 > Section 8.5.2: > ------------------ >=20 > OLD: >=20 > When an offerer generates an offer, in which it wants the answerer to > select a new offerer BUNDLE address [Section 8.2.2], the offerer > MUST: >=20 > NEW: >=20 > When an offerer generates an offer, in which it suggests > a new offerer BUNDLE address [Section 8.2.2], the offerer MUST: >=20 >=20 > OLD: >=20 > o Assign a unique address, which the offerer wants the answerer to > select as the offerer BUNDLE address, to a bundled "m=3D" line;=20 > and >=20 > NEW: >=20 > o Assign a unique address, which the offerer suggests as the > new offerer BUNDLE address, to a bundled "m=3D" line; and >=20 >=20 > OLD: >=20 > o Indicate that the offerer wants the answerer to select the unique > address as the offerer BUNDLE address [Section 8.2.2] >=20 > NEW: >=20 > o Indicate that the offerer suggests the unique address as the > new offerer BUNDLE address [Section 8.2.2] >=20 >=20 > OLD: >=20 > NOTE: The offerer can assign a unique address to each bundled "m=3D" > line in the offer, or it can assign the previously negotiated offerer > BUNDLE address to each "m=3D" line (except the "m=3D" line to which i= t > assigns the unique address that it wants the answerer to select as > the new offerer BUNDLE address). >=20 > NEW: >=20 > NOTE: The offerer can assign > a unique address to each bundled "m=3D" line in the offer, or it can > assign the previously negotiated offerer BUNDLE address to each "m=3D= " > line (except to the "m=3D" line to which it assigns the unique addres= s > that it suggests as the new offerer BUNDLE address). >=20 >=20 > Section 8.5.3: > ------------------ >=20 > OLD: >=20 > If the offerer wants the answerer to select the address associated > with the added "m=3D" line as the new offerer BUNDLE address, the > offerer suggested BUNDLE mid MUST represent the added "m=3D" line > [Section 8.2.2]. >=20 > NEW: >=20 > If the offerer suggests the address associated with the added "m=3D" > line as the new offerer BUNDLE address, the offerer suggested > BUNDLE mid MUST represent the added "m=3D" line [Section 8.2.2]. >=20 >=20 > So, as you can see, it's not just about changing a couple of words in=20 > a title... >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul=20 > Kyzivat > Sent: 24 October 2014 19:16 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle- > negotiation-12 - Editorial nits >=20 > On 10/24/14 11:44 AM, Christer Holmberg wrote: > > Hi, > > > >>>> Section 8.2.2. Request offerer BUNDLE address selection I can't=20 > >>>> parse that caption. > >>> > >>> Based on Paul's review, I suggest to change that to "Request the=20 > >>> offerer BUNDLE address". > >> [TS] I think this caption does exactly reflect semantics of what's=20 > >> going on in that paragraph. > >> > >> The offerer does not request a BUNDLE address, it is rather a suggesti= on. > >> What about "Suggesting the offerer BUNDLE address" > > > > We would have to go through the text and make sure it doesn't cause > misaligned terminology. > > > > In addition, there is a section named "Request a new offerer BUNDLE > address", which we also would have to change. >=20 > It seems that Thomas had the same problem with the title that I did,=20 > and arrived at the same proposed solution. >=20 > So I'm in favor of making this change, and then touching up other text=20 > if necessary. >=20 > Thanks, > Paul From nobody Mon Oct 27 13:33:23 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AC71A1A3D; Mon, 27 Oct 2014 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML9fC6Fbwcza; Mon, 27 Oct 2014 13:32:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7CB1AD477; Mon, 27 Oct 2014 13:32:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027203253.4164.82954.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 13:32:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/B8O0GRtsUld5L2wKpgUQIMnAgLo Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:32:56 -0000 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 Framework for SDP Attributes when Multiplexing Author : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-04.txt Pages : 88 Date : 2014-10-27 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Media Streams multiplexed over a single underlying transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. This specification also categorizes the existing SDP attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 13:51:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B501AD495 for ; Mon, 27 Oct 2014 13:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtZgs9UJ3Z_Q for ; Mon, 27 Oct 2014 13:51:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCA41AD48E for ; Mon, 27 Oct 2014 13:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=248; q=dns/txt; s=iport; t=1414443073; x=1415652673; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=5yuY96RQNwGICEElvF/P0/xShhHeu/4HnF9NNHRXw48=; b=ePC0if0rYb47NIYR2wf1KSgyaFYb6x24Q8ubEVlPABJrBZhpwwRH8K4I wIxyoFWL8TFLcFW956Sz9hl+3dZNa2/t4BoHVtEVN5OdTbwMPBP2yR7D/ DPLQH8iqzHzD2+11DECiieUJ34kFEXQWaJxIPovhggR+6Y5hiEcKiUcMV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQMAB6vTlStJV2d/2dsb2JhbABcgw5UWbk/EgUBdJJ2h02BHxYBfYRBQAE8FhgDAgECAUsNAQcBAQWIOA3LZwEBAQEGAQEBAR6GNIpUhFIBBJ1hgTGDSYJyjkKEFCGCegEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406592000"; d="scan'208";a="366904557" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 27 Oct 2014 20:51:12 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9RKpBwN004035; Mon, 27 Oct 2014 20:51:12 GMT Message-ID: <544EB03F.6020008@cisco.com> Date: Mon, 27 Oct 2014 16:51:11 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/WsuySjYaJeSvzxETmvXlQ3m-Uq8 Cc: Ari Keranen Subject: [MMUSIC] MMUSIC Draft Agenda for IETF 91 (Honolulu) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 20:51:28 -0000 Greetings We have uploaded the MMUSIC draft agenda for IETF 91: http://www.ietf.org/proceedings/91/agenda/agenda-91-mmusic Please let us know if you have any questions or comments. Thanks Ari & Flemming (MMUSIC co-chairs) From nobody Mon Oct 27 15:54:32 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2391A06E9 for ; Mon, 27 Oct 2014 15:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.533 X-Spam-Level: * X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=2.511, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_m4pxtCsewZ for ; Mon, 27 Oct 2014 15:54:24 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58441A1B19 for ; Mon, 27 Oct 2014 15:54:02 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id eu11so6399260pac.30 for ; Mon, 27 Oct 2014 15:54: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:cc :content-type; bh=4Xi+1piBA5EIk6ZZ67ZlnCnKhxcaCA+VAQW5AAF0yfk=; b=HrnLM4iCjAmi5PDidH938odRP3ituBckTRO3iATXBu3UlCBvVuXlWE/WTAblEl4ob9 OsLJ1nWUsxTD2PRuCY9lmfStZ2jnNRtBvtyTluVPJmcKNP/fHtUJ4/d0AqlYA00onsdo 5rhvuuideymZ9nEBEX+UYsc9cDJTGKPseSpu53U4Ha3WcmXLP+dMX6K1UxnmaQGeGGcH LvRqb/E1Rtd+yP3M40HIK2Ldjl7ebNr5hg4aEIgG/RRGV92iP3Q4kRQySUNGR3QDp+tz 5e3w+IXTsEvcnlSWm4I6K9pcvHycgHiFTc99Ussk6EYeYdMG5t2cZMl1Ah4XNMN97adL 5Hxg== MIME-Version: 1.0 X-Received: by 10.68.101.131 with SMTP id fg3mr7264629pbb.130.1414450442307; Mon, 27 Oct 2014 15:54:02 -0700 (PDT) Received: by 10.70.83.131 with HTTP; Mon, 27 Oct 2014 15:54:02 -0700 (PDT) In-Reply-To: <20141027203253.4164.82954.idtracker@ietfa.amsl.com> References: <20141027203253.4164.82954.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:54:02 -0700 Message-ID: From: Suhas Nandakumar Cc: mmusic WG Content-Type: multipart/alternative; boundary=047d7b86f6f02a8d3b05066f686c Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/LGbTMRsCTA2ozMJF35D3L-sgMzU Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 27 Oct 2014 22:54:26 -0000 --047d7b86f6f02a8d3b05066f686c Content-Type: text/plain; charset=UTF-8 Hello All Here is the snapshot of major changes that went into the (03 and -04) versions - Section 15: IANA Section for registering MUX Categories and updating SDP attributes with their Mux category - Following sections were added to analyze newly registered SDP attributes: + Section 5.18 - RFC7197 (Duplication Delay Attribute in SDP) + Section 5.19 - RFC7226 ( RTCP XR Blocks for MOS Metric Reporting) + Section 5.42 - RFC7195 (SDP Extension for Circuit Switched Bearers in PSTN) + Section 5.43 - RFC7272 (IDMS Using the RTCP) - Section 14: Encapsulating attributes under multiplexing has been updated with inputs from Flemming - Overall cleanups to get ready for the WG Last Call Please let me know your thoughts Thanks Suhas On Mon, Oct 27, 2014 at 1:32 PM, 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 Framework for SDP Attributes when Multiplexing > Author : Suhas Nandakumar > Filename : draft-ietf-mmusic-sdp-mux-attributes-04.txt > Pages : 88 > Date : 2014-10-27 > > Abstract: > The Session Description Protocol (SDP) provides mechanisms to > describe attributes of multimedia sessions and of individual media > streams (e.g., Real-time Transport Protocol (RTP) sessions) within a > multimedia session. In the RTCWeb WG, there is a need to use a > single 5-tuple for sending and receiving media associated with > multiple media descriptions ("m=" lines). Such a requirement has > raised concerns over the semantic implications of the SDP attributes > associated with the RTP Media Streams multiplexed over a single > underlying transport layer flow. > > The scope of this specification is to provide a framework for > analyzing the multiplexing characteristics of SDP attributes. This > specification also categorizes the existing SDP attributes based on > the framework described herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-mux-attributes-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 > --047d7b86f6f02a8d3b05066f686c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

Here is the snapshot of major= changes that went into the (03 and -04) versions

= =C2=A0 =C2=A0- Section 15: IANA Section for registering MUX Categories and = updating SDP attributes with their Mux category

= =C2=A0 =C2=A0- Following sections were added to analyze newly registered SD= P attributes:
=C2=A0 =C2=A0 =C2=A0 =C2=A0+ Section 5.18 - RFC7197= (Duplication Delay Attribut= e in SDP)=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0+ Section 5.19 = - RFC7226 ( RTCP XR Blocks f= or MOS Metric Reporting)
=C2=A0 =C2=A0 =C2=A0 =C2=A0+ Section 5.42 - RFC7195 (<= span style=3D"color:rgb(0,0,0);font-size:1em">SDP Extension for Circuit Swi= tched Bearers in PSTN)
=C2=A0 =C2=A0 =C2=A0 =C2=A0+ Section 5.43 - RFC7272 (IDMS Using= the RTCP)

=C2=A0 =C2=A0- Section 14: Encap= sulating attributes under multiplexing has been updated with inputs from Fl= emming

=C2=A0 =C2=A0- Overall cleanups to get = ready for the WG Last Call

=C2=A0Please let me kno= w your thoughts

Thanks
Suhas
=

On Mon, Oct 27, 2= 014 at 1:32 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Multiparty Multimedia Session Contro= l Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Framework for SDP Attributes when Multiplexing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-sdp-mux-attributes-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 88
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-10-27

Abstract:
=C2=A0 =C2=A0The Session Description Protocol (SDP) provides mechanisms to<= br> =C2=A0 =C2=A0describe attributes of multimedia sessions and of individual m= edia
=C2=A0 =C2=A0streams (e.g., Real-time Transport Protocol (RTP) sessions) wi= thin a
=C2=A0 =C2=A0multimedia session.=C2=A0 In the RTCWeb WG, there is a need to= use a
=C2=A0 =C2=A0single 5-tuple for sending and receiving media associated with=
=C2=A0 =C2=A0multiple media descriptions ("m=3D" lines).=C2=A0 Su= ch a requirement has
=C2=A0 =C2=A0raised concerns over the semantic implications of the SDP attr= ibutes
=C2=A0 =C2=A0associated with the RTP Media Streams multiplexed over a singl= e
=C2=A0 =C2=A0underlying transport layer flow.

=C2=A0 =C2=A0The scope of this specification is to provide a framework for<= br> =C2=A0 =C2=A0analyzing the multiplexing characteristics of SDP attributes.= =C2=A0 This
=C2=A0 =C2=A0specification also categorizes the existing SDP attributes bas= ed on
=C2=A0 =C2=A0the framework described herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusi= c-sdp-mux-attributes/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-= attributes-04

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

--047d7b86f6f02a8d3b05066f686c-- From nobody Wed Oct 29 00:34:40 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432E31A1B73 for ; Wed, 29 Oct 2014 00:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMGVuBYPjmpJ for ; Wed, 29 Oct 2014 00:34:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCD41A00FE for ; Wed, 29 Oct 2014 00:34:37 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-d1-5450988b8043 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.92.04231.B8890545; Wed, 29 Oct 2014 08:34:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 08:34:35 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: SCTP-SDP: Definition of protocol identifiers Thread-Index: Ac/zSpCqqx5jfrv8QIySo33b7/ijxQ== Date: Wed, 29 Oct 2014 07:34:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D282E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4D282EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW73jIAQgwdrjC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN8dE9kLNkhVtH9Yz9zAuEW8i5GTQ0LAROL1ptfsELaYxIV7 69m6GLk4hASOMErMm32BHcJZwigxeco6IIeDg03AQqL7nzZIg4iAusTXvT3MILawgKnErXt3 mCHiVhInOvpZIWw9icvH1oDFWQRUJc7NmMIEYvMK+EpMvbYPLM4ItPj7qTVgcWYBcYlbT+Yz QRwkILFkz3lmCFtU4uXjf6wgJ0gIKEos75cDMZkF8iWapoRATBSUODnzCcsERqFZSAbNQqia haQKokRHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+nl5da sokRGA0Ht/zW3cG4+rXjIUYBDkYlHt6CCQEhQqyJZcWVuYcYpTlYlMR5F52bFywkkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qB0V6+UPvFg7Rlodt9xbJqnU5PZL4rPe2HjfrPWx+ij+jnbTr4 kE1sxrOXQY/YNrILdvj+X9wgMvla1KPLohOPHjvZP/9aefpx75Bl27I/CHz+Ysj/c06j5P11 MgF39inWuNrfr902b0tvl/u5uKjQz+HWobYbKkSPrlq8vc3s0MTzJ5hyZHZ58SixFGckGmox FxUnAgCR5POMZwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vLGlBnWaOpucnM8-1WbGGj6jnEI Subject: [MMUSIC] SCTP-SDP: Definition of protocol identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 07:34:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4D282EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the open issues in draft-ietf-mmusic-sctp-sdp is regarding the new p= rotocol identifier values. It has been suggested to, instead of "DTLS/SCTP", define the following prot= ocol identifiers: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". As we need to reference where the transports are defined, could someone pro= vide me where TCP over DTLS is defined? Thanks! Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4D282EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One of the open issues in draft-ietf-mmusic-sctp-sdp= is regarding the new protocol identifier values.

 

It has been suggested to, instead of “DTLS/SCT= P”, define the following protocol identifiers: "UDP/DTLS/SCTP&qu= ot; and "TCP/DTLS/SCTP".

 

As we need to reference where the transports are def= ined, could someone provide me where TCP  over DTLS is defined?

 

Thanks!

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4D282EESESSMB209erics_-- From nobody Wed Oct 29 00:41:27 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6351A1B6F for ; Wed, 29 Oct 2014 00:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_fGFDIa4m-M for ; Wed, 29 Oct 2014 00:41:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EC81A0271 for ; Wed, 29 Oct 2014 00:41:22 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-f4-54509a216dc3 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.93.04231.12A90545; Wed, 29 Oct 2014 08:41:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 08:41:20 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: SCTP-SDP: Definition of protocol identifiers Thread-Index: Ac/zSpCqqx5jfrv8QIySo33b7/ijxQAAG33Q Date: Wed, 29 Oct 2014 07:41:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D2883@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4D282E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D282E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4D2883ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvja7irIAQg1UvRCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFUv9jIXXFWvWLWmgaWBca5yFyMnh4SAicSCD1OZIWwxiQv3 1rN1MXJxCAkcYZS48WsiM4SzhFFi3v39TF2MHBxsAhYS3f+0QRpEBNQlvu7tAWsWFrCUmLX3 HDtE3EriREc/K4RtJNH4aSEjiM0ioCqxd2oLG4jNK+Ar0bJyJliNEJC9vOsvC4jNKeAncaj3 PdhMRqCDvp9awwRiMwuIS9x6Mp8J4lABiSV7zkMdLSrx8vE/VpDTJAQUJZb3y0GU50vcWPWU FWKVoMTJmU9YJjCKzEIyaRaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRtHi 1OLi3HQjY73Uoszk4uL8PL281JJNjMAIOrjlt+4OxtWvHQ8xCnAwKvHwFkwICBFiTSwrrsw9 xCjNwaIkzrvo3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwdWtsnPGc0iOvee2dhgcpf R+V8e4ukA9MyeLZstF0i4Mbv7iKSdFeAq7rXZX0q2wLP3Me3fOet33/q/+OVj6vunuu2jti+ 7ZBbb9m5/sXb12i+sthie8LmtqP62cV1uQFnZ3+Milp0XLTHISJYx+SP9f7km+etZDRvnF1U 6JbyXIptfZHMkgNKLMUZiYZazEXFiQBNxrsWgQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tQk7fuxJ7DRly4_1KCSByNYdOV0 Subject: Re: [MMUSIC] SCTP-SDP: Definition of protocol identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 07:41:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4D2883ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correction: We need a reference to where DTLS over TCP is defined. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 29. lokakuuta 2014 9:35 To: mmusic@ietf.org Subject: [MMUSIC] SCTP-SDP: Definition of protocol identifiers Hi, One of the open issues in draft-ietf-mmusic-sctp-sdp is regarding the new p= rotocol identifier values. It has been suggested to, instead of "DTLS/SCTP", define the following prot= ocol identifiers: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". As we need to reference where the transports are defined, could someone pro= vide me where TCP over DTLS is defined? Thanks! Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4D2883ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correction: We need a = reference to where DTLS over TCP is defined.

 

Regards,

 

Christer

 

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 29. lokakuuta 2014 9:35
To: mmusic@ietf.org
Subject: [MMUSIC] SCTP-SDP: Definition of protocol identifiers<= /o:p>

 

Hi,

 

One of the open issues in draft-ietf-mmusic-sctp-sdp= is regarding the new protocol identifier values.

 

It has been suggested to, instead of “DTLS/SCT= P”, define the following protocol identifiers: "UDP/DTLS/SCTP&qu= ot; and "TCP/DTLS/SCTP".

 

As we need to reference where the transports are def= ined, could someone provide me where TCP  over DTLS is defined?

 

Thanks!

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4D2883ESESSMB209erics_-- From nobody Wed Oct 29 03:45:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EAC1A86EF for ; Wed, 29 Oct 2014 03:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8TIcpn8oXPM for ; Wed, 29 Oct 2014 03:45:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DED81A86FF for ; Wed, 29 Oct 2014 03:45:39 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B2C28F71F06F5; Wed, 29 Oct 2014 10:45:35 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9TAjbUL017084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 11:45:37 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 11:45:37 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: SCTP-SDP: Definition of protocol identifiers Thread-Index: Ac/zSpCqqx5jfrv8QIySo33b7/ijxQAAG33QAAZX0lA= Date: Wed, 29 Oct 2014 10:45:36 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC34EE9C@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D4D282E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4D2883@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D2883@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC34EE9CFR711WXCHMBA03zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4r7YxYIBu1tum_Bx83VhgjA7hIM Subject: Re: [MMUSIC] SCTP-SDP: Definition of protocol identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 10:45:53 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC34EE9CFR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would be also interested to get that doc which desribes DTLS usage over TCP= (as opposed to the native approch of TLS over TCP). Because there would be actually DTLS*/TCP vs DTLS/UDP, i.e., DTLS* represen= ts a specific configuration of the DTLS protocol (by e.g. disabling mechani= sm wrt unreliable L4 protocols). I guess that there will be finally a reference to RFC 6544 / RFC 4571, i.e.= an indirect reference. If RFC 4571 would be that reference, then there would/should be two protoco= l identifiers: a) DTLS/Shim/TCP (RFC 4571 Shim header) and b) DTLS/TCP in my understanding. Side note: draft-ietf-rtcweb-transports should provide more detailed inform= ation for the option of TCP-based WebRTC traffic transport. Regards, Albrecht From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Mittwoch, 29. Oktober 2014 08:41 To: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP-SDP: Definition of protocol identifiers Correction: We need a reference to where DTLS over TCP is defined. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 29. lokakuuta 2014 9:35 To: mmusic@ietf.org Subject: [MMUSIC] SCTP-SDP: Definition of protocol identifiers Hi, One of the open issues in draft-ietf-mmusic-sctp-sdp is regarding the new p= rotocol identifier values. It has been suggested to, instead of "DTLS/SCTP", define the following prot= ocol identifiers: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". As we need to reference where the transports are defined, could someone pro= vide me where TCP over DTLS is defined? Thanks! Regards, Christer --_000_786615F3A85DF44AA2A76164A71FE1AC34EE9CFR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

W= ould be also interested to get that doc which desribes DTLS usage over TCP = (as opposed to the native approch of TLS over TCP).

B= ecause there would be actually DTLS*/TCP vs DTLS/UDP, i.e., DTLS* represent= s a specific configuration of the DTLS protocol (by e.g. disabling mechanis= m wrt unreliable L4 protocols).

<= o:p> 

I= guess that there will be finally a reference to RFC 6544 / RFC 4571, i.e. = an indirect reference.

I= f RFC 4571 would be that reference, then there would/should be two protocol= identifiers:

a= ) DTLS/Shim/TCP (RFC 4571 Shim header) and

b= ) DTLS/TCP

<= o:p> 

i= n my understanding.

<= o:p> 

S= ide note: draft-ietf-rtcweb-transports should provide more detailed informa= tion for the option of TCP-based WebRTC traffic transport.

<= o:p> 

R= egards,

A= lbrecht

<= o:p> 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Mittwoch, 29. Oktober 2014 08:41
To: mmusic@ietf.org
Subject: Re: [MMUSIC] SCTP-SDP: Definition of protocol identifiers

 

Correct= ion: We need a reference to where DTLS over TCP is defined.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

From: mmusic [ma= ilto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 29. lokakuuta 2014 9:35
To: mmusic@ietf.org
Subject: [MMUSIC] SCTP-SDP: Definition of protocol identifiers<= /o:p>

 

Hi,

 

One of the open issues in draft= -ietf-mmusic-sctp-sdp is regarding the new protocol identifier values.=

 

It has been suggested to, inste= ad of “DTLS/SCTP”, define the following protocol identifiers: &= quot;UDP/DTLS/SCTP" and "TCP/DTLS/SCTP".

 

As we need to reference where t= he transports are defined, could someone provide me where TCP  over DT= LS is defined?

 

Thanks!

 

Regards,

 

Christer

--_000_786615F3A85DF44AA2A76164A71FE1AC34EE9CFR711WXCHMBA03zeu_-- From nobody Wed Oct 29 06:58:01 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9A21A0102 for ; Wed, 29 Oct 2014 06:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNmmrC7tI1gJ for ; Wed, 29 Oct 2014 06:57:53 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCD91A0107 for ; Wed, 29 Oct 2014 06:57:52 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 77D3923F0527; Wed, 29 Oct 2014 14:57:51 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 14:57:51 +0100 From: "Stach, Thomas" To: =?iso-8859-1?Q?=27Ari_Ker=E4nen=27?= , "mmusic@ietf.org" Thread-Topic: ICE updated offer summary Thread-Index: AQHP7weKDmlP+3T9ZEG5U+X7wN7OoJxHFbXA Date: Wed, 29 Oct 2014 13:57:50 +0000 Message-ID: References: <8C422F01-91C4-433E-862B-67E1B42890D5@ericsson.com> In-Reply-To: <8C422F01-91C4-433E-862B-67E1B42890D5@ericsson.com> Accept-Language: de-AT, en-US Content-Language: en-US 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 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/yKGFsWr8uVpVdcKS_lnoKjVdcg8 Subject: Re: [MMUSIC] ICE updated offer summary X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 13:57:55 -0000 Ari, just to elaborate a bit further the pros/cons ... inline > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: Donnerstag, 23. Oktober 2014 23:23 > To: mmusic@ietf.org > Subject: [MMUSIC] ICE updated offer summary >=20 > All, >=20 > To make sure we're on the same page, here's my summary on the ICE updated > offer discussion from and since the Toronto meeting, listing arguments fo= r and > against doing the updated offer. Please chime in if there are major error= s or > some relevant point is missing. >=20 > There are also couple of open questions (see below) for which more input = would > be good. >=20 >=20 > Cheers, > Ari >=20 >=20 > For doing updated offer > ----------------------- >=20 > * SDP aware intermediaries may need to enforce policies and/or perform > configuration for the media path (latching, SDN, etc.): > https://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9sdM > https://mailarchive.ietf.org/arch/msg/mmusic/IdZykrtyeTBfIt0Hac3uN5nn5DA > https://mailarchive.ietf.org/arch/msg/mmusic/nKPIit139XRwOhC6yl-WhcChYLU > https://mailarchive.ietf.org/arch/msg/mmusic/mYbRdoeBN35ESVEeZaCCWnYpa_Q > and [1] >=20 > - Information from SDP ICE candidates and STUN messages is not sufficien= t > (can't be sure which candidate was selected e.g., with aggressive nominat= ion) >=20 > * Could also help with releasing TURN candidates without need to wait for > timeout [1] >=20 > * Helps with error case debugging and diagnostics [1] >=20 > * OK if answerer can communicate need for updated offer > https://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9sdM >=20 > * With WebRTC, updated offer could be done with the JS application (no ne= ed > for API changes) > - However, is selected candidate information available for JS apps? > https://mailarchive.ietf.org/arch/msg/mmusic/_3DO5QkBbWgMIV_2uJE9wvhxC1M= ) >=20 >=20 > For not doing updated offer > --------------------------- >=20 > * Some 3PCC scenarios break with updated offer: > https://mailarchive.ietf.org/arch/msg/mmusic/mMyN9hzyrGOqIVdCpp1N1OllNSg > http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#secti= on- > 3.1 * The above draft also provides some details on another issue with the ICE = updated offer. Fax calls tend to start an offer/answer renegotiation once fax tones are de= tected at the called side in order to renegotiate for a suitable codec/tran= sport.=20 This renegotiation might collide with the ICE updated offer and lead to del= ay. * There is yet another issue with call distribution systems, e.g. call cent= ers, key-sets, pick-up groups, using B2BUAs together with SRTP. Considering that SDP Security Description is used, the offerer's key materi= al is likely to be distributed to various callees. In order to ensure privacy of the eventually established dialog, the involv= ed B2BUA would use an offerless INVITE to trigger another offer/answer exch= ange with unique keying material. Again this SDP offer/answer exchange is l= ikely to collide with the ICE updated offer. Regards Thomas >=20 > * Not needed in scenarios without SDP aware intermediaries >=20 > * Complicates call flows and implementations [1] >=20 > * Currently updated offer is not implemented for Chrome and Firefox; not = clear > if needed in practice [1] >=20 > * Could we do instead offerless INVITE where updated offer is needed?=20 > Is PRACK nowadays supported? You can still not assume that PRACK is supported universally.=20 Because of this, Trickle ICE again needed some technique that=20 > https://mailarchive.ietf.org/arch/msg/mmusic/lORWBcHNqXPlZqdvE2SDbVdAwc4 > https://mailarchive.ietf.org/arch/msg/mmusic/s95L-4VagjrTluojSQyFBkM6Zn0 >=20 >=20 > [1] http://www.ietf.org/proceedings/90/minutes/minutes-90- > mmusic#h.1yc63e74pbhi > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Oct 30 12:28:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEE41A1BB1 for ; Thu, 30 Oct 2014 12:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E01gPihpn7P for ; Thu, 30 Oct 2014 12:28:54 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31AB1A1B9A for ; Thu, 30 Oct 2014 12:28:53 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-db-545291735e16 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7F.1E.24955.37192545; Thu, 30 Oct 2014 20:28:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 20:28:51 +0100 From: Christer Holmberg To: "Stach, Thomas" , =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" Thread-Topic: ICE updated offer summary Thread-Index: AQHP7weKDmlP+3T9ZEG5U+X7wN7OoJxHFbXAgAH5aZA= Date: Thu, 30 Oct 2014 19:28:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D7D4C@ESESSMB209.ericsson.se> References: <8C422F01-91C4-433E-862B-67E1B42890D5@ericsson.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.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW7JxKAQg9MvmCymLn/MYnFy5zZm ByaPJUt+Mnls73nMEsAUxWWTkpqTWZZapG+XwJXRv62BuWCFWsW0u+tYGxh/y3cxcnJICJhI PH99jRXCFpO4cG89WxcjF4eQwBFGibfPpoAlhASWMErceuTSxcjBwSZgIdH9TxukRkSgj1Hi avtGNpAaYQE1iVlLn7KA2CIC6hLPn3xnhbCtJFYeu8EIYrMIqEr8fNnHBjKHV8BXYt4nQ4jx LYwSR/skQMKcAv4SX85Vg4QZgc75fmoNE4jNLCAucevJfCaIMwUkluw5zwxhi0q8fPwP6nwl ibWHt7NA1OtJ3Jg6hQ3C1pZYtvA1WD2vgKDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0 OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwRg5u+a26g/HyG8dDjAIcjEo8vB8eBoYIsSaWFVfm HmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGo9RJmSaBy14xKUZphFnk NKbWeGhKfo4Sabb/u9tZO/Ti5Bi9q7YshRH3hGZ1/3JqlzHd3eDQ8fuU9tRDT2PvSYcZ7s/k brkrc+L2m1/fFqyVPuC+WOu96aMNs68tviCu8CstrMPNt4lHkf1X0Zqu45Wr1s2Py6yTnzev M9762wIR4wvfd+5WYinOSDTUYi4qTgQAIzOTDXICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/WlZ294IaM4WrZc9UJo7LKef9nPI Subject: Re: [MMUSIC] ICE updated offer summary X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2014 19:28:57 -0000 Hi, There are standardized procedures on how to deal with offer collisions - an= d you have to implement those procedures no matter what. In addition, there are mechanisms for delaying the alterting of the remote = endpoint (e.g. your fax machine) before certain preconditions have been met= - and in certain network scenarios you may have to implement those anyway. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Stach, Thomas Sent: 29 October 2014 15:58 To: Ari Ker=E4nen; mmusic@ietf.org Subject: Re: [MMUSIC] ICE updated offer summary Ari, just to elaborate a bit further the pros/cons ... inline > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ari Ker=E4nen > Sent: Donnerstag, 23. Oktober 2014 23:23 > To: mmusic@ietf.org > Subject: [MMUSIC] ICE updated offer summary >=20 > All, >=20 > To make sure we're on the same page, here's my summary on the ICE=20 > updated offer discussion from and since the Toronto meeting, listing=20 > arguments for and against doing the updated offer. Please chime in if=20 > there are major errors or some relevant point is missing. >=20 > There are also couple of open questions (see below) for which more=20 > input would be good. >=20 >=20 > Cheers, > Ari >=20 >=20 > For doing updated offer > ----------------------- >=20 > * SDP aware intermediaries may need to enforce policies and/or perform=20 > configuration for the media path (latching, SDN, etc.): > https://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9s > dM=20 > https://mailarchive.ietf.org/arch/msg/mmusic/IdZykrtyeTBfIt0Hac3uN5nn5 > DA=20 > https://mailarchive.ietf.org/arch/msg/mmusic/nKPIit139XRwOhC6yl-WhcChY > LU=20 > https://mailarchive.ietf.org/arch/msg/mmusic/mYbRdoeBN35ESVEeZaCCWnYpa > _Q > and [1] >=20 > - Information from SDP ICE candidates and STUN messages is not=20 > sufficient (can't be sure which candidate was selected e.g., with=20 > aggressive nomination) >=20 > * Could also help with releasing TURN candidates without need to wait=20 > for timeout [1] >=20 > * Helps with error case debugging and diagnostics [1] >=20 > * OK if answerer can communicate need for updated offer=20 > https://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9s > dM >=20 > * With WebRTC, updated offer could be done with the JS application (no=20 > need for API changes) > - However, is selected candidate information available for JS apps? > =20 > https://mailarchive.ietf.org/arch/msg/mmusic/_3DO5QkBbWgMIV_2uJE9wvhxC > 1M) >=20 >=20 > For not doing updated offer > --------------------------- >=20 > * Some 3PCC scenarios break with updated offer: > https://mailarchive.ietf.org/arch/msg/mmusic/mMyN9hzyrGOqIVdCpp1N1OllN > Sg > http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#se > ction- > 3.1 * The above draft also provides some details on another issue with the ICE = updated offer. Fax calls tend to start an offer/answer renegotiation once fax tones are de= tected at the called side in order to renegotiate for a suitable codec/tran= sport.=20 This renegotiation might collide with the ICE updated offer and lead to del= ay. * There is yet another issue with call distribution systems, e.g. call cent= ers, key-sets, pick-up groups, using B2BUAs together with SRTP. Considering that SDP Security Description is used, the offerer's key materi= al is likely to be distributed to various callees. In order to ensure privacy of the eventually established dialog, the involv= ed B2BUA would use an offerless INVITE to trigger another offer/answer exch= ange with unique keying material. Again this SDP offer/answer exchange is l= ikely to collide with the ICE updated offer. Regards Thomas >=20 > * Not needed in scenarios without SDP aware intermediaries >=20 > * Complicates call flows and implementations [1] >=20 > * Currently updated offer is not implemented for Chrome and Firefox;=20 > not clear if needed in practice [1] >=20 > * Could we do instead offerless INVITE where updated offer is needed?=20 > Is PRACK nowadays supported? You can still not assume that PRACK is supported universally.=20 Because of this, Trickle ICE again needed some technique that=20 > https://mailarchive.ietf.org/arch/msg/mmusic/lORWBcHNqXPlZqdvE2SDbVdAw > c4 > https://mailarchive.ietf.org/arch/msg/mmusic/s95L-4VagjrTluojSQyFBkM6Z > n0 >=20 >=20 > [1] http://www.ietf.org/proceedings/90/minutes/minutes-90- > mmusic#h.1yc63e74pbhi > _______________________________________________ > 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 nobody Fri Oct 31 11:30:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A9F1A19E9 for ; Fri, 31 Oct 2014 11:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apBMRaBHyKeC for ; Fri, 31 Oct 2014 11:30:39 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CDE1A19EB for ; Fri, 31 Oct 2014 11:30:38 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-01v.sys.comcast.net with comcast id 9uVp1p0055BUCh401uWeh4; Fri, 31 Oct 2014 18:30:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id 9uWb1p00E3Ge9ey01uWbqA; Fri, 31 Oct 2014 18:30:36 +0000 Message-ID: <5453D54B.3020209@alum.mit.edu> Date: Fri, 31 Oct 2014 14:30:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "Stach, Thomas" References: <7594FB04B1934943A5C02806D1A2204B1D4C429D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4C8236@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C8236@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414780238; bh=IbnuOcRvV5IG0LSiKwgMVdno9WBk+MiHnwgIo1wV69o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WtrexmWKGYL5+IIVkSISc8BWLzetrCyWcgH1G3NfZSmv8LYFxlzrYLsl6THiaZOD6 PraMKiUhwqGhVgWeTAVbr6iOs7fjXkHxXRB0y1eRLTtiF9CJOagFSB+lfLxCQ2seP3 kB6yXPebKQr+rCEhSNHhspZzbbxJEbbhk71Uo+qZC71lTShQ1c6C1XC1SPsgVZhTe7 NYAj3Rkc1AhjZ5zSHYtm+0ruvtw51bp/qQPheRX4v/n2YAiYEaV774Y2MchHsvd9jd jnEmIzYqflVluqoqNele+liLqP1L0bI2cwDtgG3OMeVsFbYlGe9LPFGFNdZwVJWscm h24QWDZT/uKag== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/iFM2Nz2F2ZwvlZT_R6PSoFsam_8 Cc: 'mmusic' Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 31 Oct 2014 18:30:40 -0000 On 10/25/14 10:31 AM, Christer Holmberg wrote: > Hi, > > I’d like to hear Paul’s opinions on this, because he is the one who > suggested the current terminology. Sorry to be so slow responding. I've looked back at the thread, and I am not entirely clear what the proposal is. In part it is replacing "BUNDLE mid" with "BUNDLE-tag". Looking at where "BUNDLE mid" is used, it is mostly in constructs like: In the offer, the address assigned to the "m=" line associated with the offerer suggested BUNDLE mid indicates the address that the Given the definition that Thomas proposed, that would still work with the change, but ISTM the linkage from "mid" to "m=" line is a little more obvious than from "tag" to "m=" line. I don't know if Thomas was intending that there would still be definitions for "Offerer suggested BUNDLE-tag" and "Answerer selected BUNDLE-tag". I think we would still need those. As an alternative, perhaps a definition of "BUNDLE mid" could be added, that has much of the text from Thomas' definition of "BUNDLE-tag". Thanks, Paul > Regards, > > Christer > > *From:*Stach, Thomas [mailto:thomas.stach@unify.com] > *Sent:* 24 October 2014 16:45 > *To:* Christer Holmberg > *Cc:* 'mmusic' > *Subject:* RE: WGLC comments on > draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology > > Hi, > > There has been many long discussions in order to come up with the > terminology. > > */[TS] I know that much effort was already put into that. /* > > *//* > > Also, > > considering the number of editorial re-structures that have already > taken place, and the impact this would have on the document, I would > suggest to NOT do the change. > > */[TS] I understand that there is not much appetite for putting more > editorial work into the document./* > > */Nevertheless, I still think that understanding the text is still > unnecessarily cumbersome, /* > > */which in turn could lead to unnecessary misinterpretations during > implementation./* > > */But maybe it is just me, who has this problem, in which case I > probably just have to improve my reading skills. ;-) /* > > But, if you think the existing definitions can be clarified, we can > discuss that. > > */[TS] Well, considering reuse of the RFC5888 terminology might be still > worthwhile./* > > */That would e.g. include replacing “mid attribute value” with > “identification-tag”, etc./* > > *//* > > Regards, > > Christer > > *From:*Stach, Thomas [mailto:thomas.stach@unify.com] > *Sent:* 23 October 2014 18:34 > *To:* Christer Holmberg > *Cc:* 'mmusic' > *Subject:* WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 > - Terminology > > All > > Terminology > > Offerer suggested BUNDLE mid: The first mid value in a given SDP > > 'group:BUNDLE' attribute mid list in an offer. > > and > > Answerer selected BUNDLE mid: The first mid value in a given SDP > > 'group:BUNDLE' attribute mid list in an answer. > > These terms are not very intuitive and make the reading the related text > quite cumbersome. > > Since you are talking about the identification-tags from RFC5888 > > group-attribute = "a=group:" semantics *(SP identification-tag) > > mid-attribute = "a=mid:" identification-tag > > may I suggest re-using that terminology and propose using a single, more > pregnant term for both > > together with additional explanation? > > E.g. > > BUNDLE-tag: The first element in the list of identification-tags of > > a 'group:' attribute [RFC5888] with BUNDLE semantics. > > This tag has special significance in that it identifies > > the m-line that carries the suggested or selected BUNDLE > address. > > The corresponding m-line will carry the same tag in a 'mid' > attribute. > > The offerer suggests a BUNDLE tag. The answerer preferably > accepts > > the suggested BUNDLE-tag, but could select a different > > BUNDLE-tag, if necessary. > > Example: > > If we have e.g. 'a=group:BUNDLE foo bar', then 'foo' would > be the > > BUNDLE-tag and 'a=mid:foo' the m-line with the BUNDLE address. > > If there is appetite for changing that terminology, I understand that it > would cause quite a few > > other editorial changes in the remainder of the document. > > In order to not delay progress of the draft, I can only offer to help in > any editorial effort and would be happy to propose changed text. > > Regards > > Thomas >