From palmarti@cisco.com Thu Aug 1 01:21:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB2621F99A9 for ; Thu, 1 Aug 2013 01:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvfCPRkNPtwX for ; Thu, 1 Aug 2013 01:21:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9393D21F9E47 for ; Thu, 1 Aug 2013 01:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1225; q=dns/txt; s=iport; t=1375345188; x=1376554788; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wot7OLQA+MN5pY3V1lOn2dx32+h+GNRbUv9gcekCHrI=; b=MGExSfbpOLW8X6lfzQrpuoWFsNEiY+9HXwgCReQ2lLrPzN3hPG6RXQbq fRw+GpohPO5PU3o0PjTG88C7TIKYZjD4wRjTa5F19qvYIjo2V1SJQYYgI kvBllClPX9rDFK8Na/1B3iJ785DbXU/XdmIwuCHkcsISAlm50ingN45+m I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFMZ+lGtJXHA/2dsb2JhbABbgwY1UL5dgR4WdIIkAQEBAwEBAQFrCwULAgEIGAokIQYLJQIEDgUIh3YDCQYMsDMNiFoEjRaCPgIxB4MYcwOIco0Ejg+FJ4MUgio X-IronPort-AV: E=Sophos;i="4.89,792,1367971200"; d="scan'208";a="242127215" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2013 08:19:48 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r718Jl5P024579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 08:19:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.244]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 03:19:47 -0500 From: "Pal Martinsen (palmarti)" To: Martin Thomson Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: AQHOjglaLPlGrnqGrkKYKhaPOYMy0ZmAV4IA Date: Thu, 1 Aug 2013 08:19:47 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB1144E3A4@xmb-rcd-x06.cisco.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> <51F933A8.2060504@ericsson.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.195.244] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <90DCD4582BBC02419E2A8E04A5D4DBF7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Lennox , =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:21:21 -0000 Hi, I want to revisit a discussion from an earlier version of the draft.=20 An earlier version of the draft suggested to do IPv4 and IPv6 checks in par= allel. I like that idea because: 1. It really speeds up the connectivity check phase 2. Should have no impact on the NAT port allocation problem. (Or is there a= way for an IPv6 conn check to have a negative impact on the IPv4 NAT?) 3. Easy to implement. I would just change the way I traverse the the ordere= d checklist. Send first available IPv6 test, then search the list for the f= irst available IPv4 check. To avoid timing issues a ice-option might be use= d to say that the checklist is done in parallel if it contains different ad= dress types. (Do we want to support IPv7.. :-) ) .-. P=E5l-Erik On Jul 31, 2013, at 18:16 PM, Martin Thomson wrote: > On 31 July 2013 17:56, Ari Ker=E4nen wrote: >> overly complex >=20 > Yes. Given that this is a very small part of a spec that already fits > that description, we need to be careful. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ietf@meetecho.com Thu Aug 1 02:07:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E4F21F9F85 for ; Thu, 1 Aug 2013 02:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cf8YNLytd0K for ; Thu, 1 Aug 2013 02:07:24 -0700 (PDT) Received: from smtpdg6.aruba.it (smtpdg224.aruba.it [62.149.158.224]) by ietfa.amsl.com (Postfix) with ESMTP id A348221F9D53 for ; Thu, 1 Aug 2013 02:06:45 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6k1m00s0EaGCq01M6lGR; Thu, 01 Aug 2013 11:06:45 +0200 Date: Thu, 1 Aug 2013 11:06:42 +0200 (CEST) From: Meetecho Team To: mmusic@ietf.org Message-ID: <2074847436.27.1375348002875.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_26_2123841289.1375348002873" Subject: [MMUSIC] MMUSIC session recording available X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:07:29 -0000 ------=_Part_26_2123841289.1375348002873 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the MMUSIC WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#MMUSIC For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_26_2123841289.1375348002873-- From martin.thomson@gmail.com Thu Aug 1 04:27:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E580D21F9F44 for ; Thu, 1 Aug 2013 04:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0lrKYwlk4Fe for ; Thu, 1 Aug 2013 04:27:24 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id CA84221F8EFE for ; Thu, 1 Aug 2013 04:26:31 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id j17so1700898wiw.17 for ; Thu, 01 Aug 2013 04:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fipmfVFlhMPBd+mPIOc+uNQJVWjQq/WAYx64HRxjWGY=; b=S4xlLVXsGPFUVGKSO68lcuaDWyfg1t73BH1WNZUW24JP8xfqe/Jz3Lvx9zuik4ZY/Y ERR+TgtTPiVAzWNLZhuysFxZQ0QdksAzmYbN91eidZuGeff9OMnsZTULhLZvfev2J2f+ +JPm+sPuoDwTdZjyB7+0LYv+ss7saDqCM4V3YzSK40vvCl1eYxS7ISRg7ZiiXb8RnweI s7PTy5yvoUmhWq0ILtgeArkqjNHSLKBoLNJ8IlTgnf8a3cCbnnI+rfzHqWnDOj81UOAP 18mBVrX3rwU/lHLJr2ELbFufQJUe7PAlhA10NYV3dB+Z7e9tHo8b3882xcOZ6NaQN4xv sCUA== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr7478263wik.14.1375356389735; Thu, 01 Aug 2013 04:26:29 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 1 Aug 2013 04:26:29 -0700 (PDT) In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB1144E3A4@xmb-rcd-x06.cisco.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> <51F933A8.2060504@ericsson.com> <1373AC9C23D80E44856F5CF6F883ACAB1144E3A4@xmb-rcd-x06.cisco.com> Date: Thu, 1 Aug 2013 13:26:29 +0200 Message-ID: From: Martin Thomson To: "Pal Martinsen (palmarti)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:27:25 -0000 On 1 August 2013 10:19, Pal Martinsen (palmarti) wrote= : > > An earlier version of the draft suggested to do IPv4 and IPv6 checks in p= arallel. I like that idea because: I don't think that that is necessary. > 1. It really speeds up the connectivity check phase > 2. Should have no impact on the NAT port allocation problem. (Or is there= a way for an IPv6 conn check to have a negative impact on the IPv4 NAT?) I can think of a way that this would be bad, but I'm only speculating about NAT implementation in doing so. > 3. Easy to implement. I would just change the way I traverse the the orde= red checklist. Send first available IPv6 test, then search the list for the= first available IPv4 check. To avoid timing issues a ice-option might be u= sed to say that the checklist is done in parallel if it contains different = address types. (Do we want to support IPv7.. :-) ) I don't believe that this is any easier to implement. In fact, the easiest thing to implement is a change to the priority calculation. Besides, a priority change will actually cause the checklist ordering to be the same without new signaling, anything else won't. From bernard_aboba@hotmail.com Thu Aug 1 04:41:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E49D21E80CA for ; Thu, 1 Aug 2013 04:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND812DHURLGF for ; Thu, 1 Aug 2013 04:40:58 -0700 (PDT) Received: from blu0-omc4-s20.blu0.hotmail.com (blu0-omc4-s20.blu0.hotmail.com [65.55.111.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3458A21E80C6 for ; Thu, 1 Aug 2013 04:40:58 -0700 (PDT) Received: from BLU169-W139 ([65.55.111.135]) by blu0-omc4-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Aug 2013 04:40:57 -0700 X-TMN: [zAcjC1G4mipv/E1RV0ecSRUxAYTMk0l5] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_cfab53b9-8cdd-499a-be35-23c83ae11fa7_" From: Bernard Aboba To: "Pal Martinsen (palmarti)" Date: Thu, 1 Aug 2013 04:40:56 -0700 Importance: Normal In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB1144E3A4@xmb-rcd-x06.cisco.com> References: , , <51F8D6B6.6080109@ericsson.com>, <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com>, <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com>, <51F933A8.2060504@ericsson.com>, , <1373AC9C23D80E44856F5CF6F883ACAB1144E3A4@xmb-rcd-x06.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 01 Aug 2013 11:40:57.0345 (UTC) FILETIME=[FCE08F10:01CE8EAB] Cc: "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:41:04 -0000 --_cfab53b9-8cdd-499a-be35-23c83ae11fa7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > An earlier version of the draft suggested to do IPv4 and IPv6 checks in p= arallel. I like that idea because: >=20 > 1. It really speeds up the connectivity check phase [BA] Not if the constraints on sending of connectivity checks are still ope= rative.=20 > 2. Should have no impact on the NAT port allocation problem. (Or is there= a way for an IPv6 conn check to have a negative impact on the IPv4 NAT?) [BA] There are (pathological) cases where a host with an IPv6 address may f= ind that it has an IPv4 reflexive address (NAT64).=20 > 3. Easy to implement.=20 [BA] Given that there are now tens of millions of deployed hosts running IC= E based on RFC 5245=2C "ease of implementation" of non-backward compatible = extensions should not be a criteria. A more relevant question is "can this= problem be solved in a backward compatible way?" In this case=2C I believ= e that the answer is Yes. Given that=2C there is neither a need nor a com= pelling case for breaking backward compatibility. = --_cfab53b9-8cdd-499a-be35-23c83ae11fa7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B An earlier version of the draft suggested to do IPv4 and IPv6 c= hecks in parallel. I like that idea because:
>=3B
>= =3B 1. It really speeds up the connectivity check phase

[BA] =3BNot if the constraints= on sending of connectivity checks are still operative. =3B

>=3B 2. Should have no impact on the NAT port allocation proble= m. (Or is there a way for an IPv6 conn check to have a negative impact on t= he IPv4 NAT?)

[BA] There are (pathological) cases = where a host with an IPv6 address may find that it has an IPv4 reflexive ad= dress (NAT64). =3B

>=3B 3. Easy to implement. =3B

[BA] Given that there are now tens of millions of d= eployed hosts running ICE based on RFC 5245=2C "ease of implementation" of = non-backward compatible extensions should not be a criteria.  =3BA more= relevant question is "can this problem be solved in a backward compatible = way?"  =3BIn this case=2C I believe that the answer is Yes.  =3B Gi= ven that=2C there is neither a need nor a compelling case for breaking back= ward compatibility. =3B
= --_cfab53b9-8cdd-499a-be35-23c83ae11fa7_-- From jonathan@vidyo.com Thu Aug 1 04:50:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC86321E80C6 for ; Thu, 1 Aug 2013 04:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TXxYikJtSE5 for ; Thu, 1 Aug 2013 04:50:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id C977321E80A3 for ; Thu, 1 Aug 2013 04:50:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DC36F4168D2; Thu, 1 Aug 2013 07:50:31 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6FA30416858; Thu, 1 Aug 2013 07:50:31 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Thu, 1 Aug 2013 07:48:29 -0400 From: Jonathan Lennox To: Martin Thomson Date: Thu, 1 Aug 2013 07:50:35 -0400 Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: Ac6OrTUhlgy3mZqzS1eBL3qOcRpI5g== Message-ID: <11D60C32-DE17-46DB-A4D7-B5F27077440F@vidyo.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> <51F933A8.2060504@ericsson.com> <1373AC9C23D80E44856F5CF6F883ACAB1144E3A4@xmb-rcd-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:50:46 -0000 On Aug 1, 2013, at 1:26 PM, Martin Thomson wrote= : > On 1 August 2013 10:19, Pal Martinsen (palmarti) wro= te: >> 1. It really speeds up the connectivity check phase >> 2. Should have no impact on the NAT port allocation problem. (Or is ther= e a way for an IPv6 conn check to have a negative impact on the IPv4 NAT?) >=20 > I can think of a way that this would be bad, but I'm only speculating > about NAT implementation in doing so. Presumably a check on a Teredo candidate impacts your IPv4 NAT. -- Jonathan Lennox jonathan@vidyo.com From tireddy@cisco.com Fri Aug 2 08:11:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7D311E80C5 for ; Fri, 2 Aug 2013 08:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, OBSCURED_EMAIL=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLE3+p6dFA9y for ; Fri, 2 Aug 2013 08:11:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3FC11E80F4 for ; Fri, 2 Aug 2013 08:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3556; q=dns/txt; s=iport; t=1375456277; x=1376665877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iGxm0/SuD5Qp3Ayh5dFo4rBrtXecIS6h8GnwCvuMOVM=; b=IVmhrDD2nRpSGfkn37r68rc4QHENeTvaQadCkU/lS/TTi8UyGK2aBNG+ 4h4L0oN/ly0hHhiPPUkCbMzV5CpBmygALoSs4YKgwR771MSLEZo87WlIy /kdWpEPVLk5ebiOBzjEN9p/kcbAnQAbRd0LAUFgMFEuZ/2VFg3jpx2sg1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAO/K+1GtJXHA/2dsb2JhbABagwY1UL5WgR0WdIIkAQEBBHkMBAIBCBEEAQEBCh0HMhQJCAIEAQ0FCIgIDLlVj2cxBwaDE3QDiHKQF5AkgxeCKg X-IronPort-AV: E=Sophos;i="4.89,802,1367971200"; d="scan'208";a="242866421" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2013 15:11:17 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r72FBGDf024558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 15:11:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 2 Aug 2013 10:11:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , Jonathan Lennox Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: AQHOjc8e11SEQQIfXUy0NUn1kHVbfZl+uC4wgAB5HwCAABPqAIAAwV2Q Date: Fri, 2 Aug 2013 15:11:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1900AB72@xmb-rcd-x10.cisco.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> <51F933A8.2060504@ericsson.com> In-Reply-To: <51F933A8.2060504@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.227] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 15:11:23 -0000 > -----Original Message----- > From: Ari Ker=E4nen [mailto:ari.keranen@ericsson.com] > Sent: Wednesday, July 31, 2013 9:26 PM > To: Jonathan Lennox > Cc: Tirumaleswar Reddy (tireddy); mmusic@ietf.org; Martin Thomson > Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and IC= E bis >=20 > On 7/31/13 4:45 PM, Jonathan Lennox wrote: > > > > On Jul 31, 2013, at 4:13 PM, "Tirumaleswar Reddy (tireddy)" > wrote: > >> > >> Using the formula in RFC 5245 > >> > >> priority =3D (2^24)*(type preference) + > >> (2^8)*(local preference) + > >> (2^0)*(256 - component ID) > >> > >> Type preference of > >> Host candidates > Server-reflexive candidates > Relayed candidates > >> > >> (For example host candidate is 126, server-reflexive 105) > >> > >> that causes the problem that when candidate pair priority is calculate= d > (priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)) > >> The candidate pair IPv4 (host, server-reflexive) will only be tested o= nly > after all IPv6 host candidate-pairs, IPv4 host candidate pairs. > >> > >> Even if policy table RFC 6724 is changed so that IPv4 addresses have h= igher > precedence that does not solve the problem, It will still result in IPv4 > (host, server-reflexive) to be tested only after all IPv4 host candidate > pairs, IPv6 host candidate-pairs. > >> > >> Hence during the WG session, I had explained that by tweaking the cand= idate > priority will not solve the problem, but the candidate pair priority has = to be > adjusted after offer/exchange such that after NNN number of preferred IPv= 6 > candidate pairs the highest-priority IPv4 candidate-pair is tested and th= e > above adjustment continued until all candidate pairs of the preferred add= ress > family are exhausted. > > > > The first formula you quote is the one that RFC 5245 defines as recomme= nded, > not mandatory. What we're suggesting be changed is not the "local prefer= ence" > field, but actually the calculated 32-bit "priority" field for the candid= ate. > You can set your priorities such that some server-reflexive candidates ha= ve > higher priority than some host candidates, and the calculation of the pai= r's > 64-bit priority will still work. > > > > We need to be pretty careful when defining a new formula for how these > priorities are set, though. >=20 > If it's only about updating that formula, this indeed looks like a good > way forward. >=20 > Just need to think how to get all we want to express (and what do we > actually want to express) in a priority formula that isn't overly > complex. Expressing things like "some IPv4 host-srvrflx should be > prioritized over (some) IPv6 host-host but v4 host-host below (some) v6 > host-host" etc may get a bit messy. How about using the existing recommended formula in RFC 5245 and after the = local candidates are prioritized do the following additional steps : =20 a. If the first 'N' candidates are of the same IP address family, then the= highest-priority candidate of the other address family is promoted to posi= tion 'N' in the list. b. Step b is repeated for rest of candidates. This is continued until all = candidates with the preferred address family are exhausted. This would work even when policy table is modified such that IPv4 addresses= have higher precedence than IPv6 using DHCP http://tools.ietf.org/html/dra= ft-ietf-6man-addr-select-opt-10.=20 --Tiru. >=20 >=20 > Cheers, > Ari From martin.thomson@gmail.com Fri Aug 2 23:48:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC58F11E80F6 for ; Fri, 2 Aug 2013 23:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxDHamcL7A6p for ; Fri, 2 Aug 2013 23:48:03 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1411E80F7 for ; Fri, 2 Aug 2013 23:47:59 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so108992wib.17 for ; Fri, 02 Aug 2013 23:47:57 -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=oPsXUWSev4srctp8ntCy8vpEHPudO3MIy5gd4clocgc=; b=SYsMobOookVL/sggmNtNlFbb26fSifXNfRtUuqXVU8JMkkAKhQ1sHfCpGge64hCzyI xOO9FNChqkYnfTZoN2gx/Bc4xmHK7HP+o7nkSWEk+eTZLKrsLNq0Wx3yuoWQZbfdEZCf iZYsLoXhePSwnnsIHHl38MiFK+tGN2G2QCiGfaOopPVbB4MxvMNg7Ite0DM4xzXW/ZcN MJ9bLvATQG9+r2IK+aAtTmMcW2f/leB21my34TV1SpVYHiPyN/haFksHRHzS/vSX3fzO Eexjh54OTvrIk2kpFQkKjViNFEh22Db0BcVmljoiG/3cHXANStFY+y5/g97GKkEVFBnP K+lg== MIME-Version: 1.0 X-Received: by 10.180.39.236 with SMTP id s12mr1047175wik.14.1375512476601; Fri, 02 Aug 2013 23:47:56 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Fri, 2 Aug 2013 23:47:56 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A1900AB72@xmb-rcd-x10.cisco.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> <51F933A8.2060504@ericsson.com> <913383AAA69FF945B8F946018B75898A1900AB72@xmb-rcd-x10.cisco.com> Date: Sat, 3 Aug 2013 08:47:56 +0200 Message-ID: From: Martin Thomson To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Cc: Jonathan Lennox , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 06:48:03 -0000 On 2 August 2013 17:11, Tirumaleswar Reddy (tireddy) wrote: > a. If the first 'N' candidates are of the same IP address family, then the highest-priority candidate of the other address family is promoted to position 'N' in the list. > > b. Step b is repeated for rest of candidates. This is continued until all candidates with the preferred address family are exhausted. > > This would work even when policy table is modified such that IPv4 addresses have higher precedence than IPv6 using DHCP http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-10. I'm not sure that your specific formulation of the algorithm makes sense (reread step b), but I think that the general principle you use in the draft (as you explained in the WG meeting) is certainly a viable option. From tireddy@cisco.com Sat Aug 3 12:56:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF0321F9E51 for ; Sat, 3 Aug 2013 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhHO4rzP6ip3 for ; Sat, 3 Aug 2013 12:56:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CCE0621F9E88 for ; Sat, 3 Aug 2013 12:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1812; q=dns/txt; s=iport; t=1375559783; x=1376769383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1GcuLigNqOWs8US1sb5a2xKNbVeeNgshBdzdNlXrwhA=; b=DQj1Av3vRJ79nNrme+2FEfDREyk3PQI/uEJIh8ufHDK4BTKnZtaeg+gB coKBqJt+Wo7sbgeRH6WjRTtL7WX79ADSVTyABtGbCwQ83lTl5fOsM+AzJ ZfUIhBkJql4CpM8HrztffST27K9eg2nFA1VmCUA/ySSRhFBadkYfONMA0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFADRf/VGtJXHB/2dsb2JhbABagwY1UIMQvAQXgQYWdIIkAQEBAQIBIxFFBQcEAgEIEQQBAQECAgYdAwICAh8RFAEICAIEDgUIh3YDCQalWYd8DYhegSiLf4JBFhsHBoJgM3QDlXeDE4p+hSeDF4Iq X-IronPort-AV: E=Sophos;i="4.89,808,1367971200"; d="scan'208";a="243143166" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 03 Aug 2013 19:56:18 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r73JuIVV028699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Aug 2013 19:56:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sat, 3 Aug 2013 14:56:18 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Martin Thomson Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: AQHOjc8e11SEQQIfXUy0NUn1kHVbfZl+uC4wgAB5HwCAABPqAIAAwV2QgANcZACAACe2sA== Date: Sat, 3 Aug 2013 19:56:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1900B793@xmb-rcd-x10.cisco.com> References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> <51F933A8.2060504@ericsson.com> <913383AAA69FF945B8F946018B75898A1900AB72@xmb-rcd-x10.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.65.58.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Jonathan Lennox , =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 19:56:28 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NCj4gU2VudDogU2F0dXJkYXksIEF1Z3VzdCAw MywgMjAxMyAxMjoxOCBQTQ0KPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiBD YzogQXJpIEtlcsOkbmVuOyBKb25hdGhhbiBMZW5ub3g7IG1tdXNpY0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW01NVVNJQ10gUkZDIDUyNDUgU2VjdGlvbiA0LjEuMi4xLCBpY2UtaGFwcHktZXll YmFsbHMgYW5kIElDRSBiaXMNCj4gDQo+IE9uIDIgQXVndXN0IDIwMTMgMTc6MTEsIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPg0KPiB3cm90ZToNCj4gPiBh LiAgSWYgdGhlIGZpcnN0ICdOJyBjYW5kaWRhdGVzIGFyZSBvZiB0aGUgc2FtZSBJUCBhZGRyZXNz IGZhbWlseSwgdGhlbiB0aGUNCj4gaGlnaGVzdC1wcmlvcml0eSBjYW5kaWRhdGUgb2YgdGhlIG90 aGVyIGFkZHJlc3MgZmFtaWx5IGlzIHByb21vdGVkIHRvIHBvc2l0aW9uDQo+ICdOJyBpbiB0aGUg bGlzdC4NCj4gPg0KPiA+IGIuICBTdGVwIGIgaXMgcmVwZWF0ZWQgZm9yIHJlc3Qgb2YgY2FuZGlk YXRlcy4gVGhpcyBpcyBjb250aW51ZWQgdW50aWwgYWxsDQo+IGNhbmRpZGF0ZXMgd2l0aCB0aGUg cHJlZmVycmVkIGFkZHJlc3MgZmFtaWx5IGFyZSBleGhhdXN0ZWQuDQo+ID4NCj4gPiBUaGlzIHdv dWxkIHdvcmsgZXZlbiB3aGVuIHBvbGljeSB0YWJsZSBpcyBtb2RpZmllZCBzdWNoIHRoYXQgSVB2 NCBhZGRyZXNzZXMNCj4gaGF2ZSBoaWdoZXIgcHJlY2VkZW5jZSB0aGFuIElQdjYgdXNpbmcgREhD UCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC0NCj4gaWV0Zi02bWFuLWFkZHItc2Vs ZWN0LW9wdC0xMC4NCj4gDQo+IEknbSBub3Qgc3VyZSB0aGF0IHlvdXIgc3BlY2lmaWMgZm9ybXVs YXRpb24gb2YgdGhlIGFsZ29yaXRobSBtYWtlcw0KPiBzZW5zZSAocmVyZWFkIHN0ZXAgYiksIA0K DQpUeXBvOyB3aGF0IEkgbWVhbnQgd2FzDQoNCmIuIFN0ZXAgYSBpcyByZXBlYXRlZCBmb3IgcmVz dCBvZiB0aGUgY2FuZGlkYXRlcyB1bnRpbCBhbGwgY2FuZGlkYXRlcyBvZiB0aGUgcHJlZmVycmVk IGFkZHJlc3MgZmFtaWx5IGFyZSBleGhhdXN0ZWQuDQoNCj4gYnV0IEkgdGhpbmsgdGhhdCB0aGUg Z2VuZXJhbCBwcmluY2lwbGUgeW91IHVzZQ0KPiBpbiB0aGUgZHJhZnQgKGFzIHlvdSBleHBsYWlu ZWQgaW4gdGhlIFdHIG1lZXRpbmcpIGlzIGNlcnRhaW5seSBhDQo+IHZpYWJsZSBvcHRpb24uDQoN Ci0tVGlydS4NCg== From christer.holmberg@ericsson.com Mon Aug 5 07:06:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055B521F9DF6 for ; Mon, 5 Aug 2013 07:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.765 X-Spam-Level: X-Spam-Status: No, score=-5.765 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BhfoV9KUNDs for ; Mon, 5 Aug 2013 07:06:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A48021F9B53 for ; Mon, 5 Aug 2013 07:06:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-f0-51ffb1736d19 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AD.9C.00725.371BFF15; Mon, 5 Aug 2013 16:06:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 16:06:43 +0200 From: Christer Holmberg To: mmusic Thread-Topic: BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) Thread-Index: Ac6R5QNzX6rIT4ISR+aNUyxTJPkKjw== Date: Mon, 5 Aug 2013 14:06:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41D191ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+JvrW7Jxv+BBnfa+CymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujM0LjzEWnJKveLX1JWMD40+pLkZODgkBE4m7y9+yQNhiEhfu rWcDsYUEDjNKtByJ6mLkArIXM0pc+biKsYuRg4NNwEKi+582SI2IgIzE3k2bmUFsYYFkifnv nrBAxDMk9j9uh7L1JO7N7GcGaWURUJG4PzseJMwr4CuxdupcdhCbEWjt91NrmEBsZgFxiVtP 5jNBnCMgsWTPeWYIW1Ti5eN/rBA1+RItjxayQMwRlDg58wnLBEbBWUjaZyEpm4WkDCKuJ3Fj 6hQ2CFtbYtnC18wQtq7EjH+HWJDFFzCyr2Jkz03MzEkvN9zECAztg1t+6+5gPHVO5BCjNAeL kjjvJr0zgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYTUIDfPJ84/S2c/6e7dpp8GiyR17c zR8aEgFLj/RdllMv4mVZmOlbmL/b65/VY9mDx6q8v25Pdjyob6PMzL4v6e+f4LRH79sbG666 OYj3mar72L1rki0706jn8CrvikTjvJazkVq3RDVnzkvYf7N7l92Njwm73p17e9Hezb4zvmi6 NNvzvvtKLMUZiYZazEXFiQBO5uaEOwIAAA== Subject: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:06:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41D191ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Within SDP Offers and Answers, BUNDLE (-04) does currently not allow usage = of port zero in bundled m- lines. However, due to the Berlin agreement to move forward with the UP (unified p= lan), we need to change that for SDP Offers, as port zero is used in bundle= d "bundle-only" m- lines. Now, as the agreed context for the UP was WEBRTC only, we need to determine= whether similar restrictions are needed in the generic BUNDLE spec. We als= o need to decide whether port zero is allowed for "bundle-only" m- lines on= ly, or for any bundled m- line. So, a couple of questions: Q10: Assuming we define the SDP bundle-only attribute in the BUNDLE spec, d= o we need to limit the scope to WEBRTC (or whatever the scope also in the B= UNDLE spec? Q11: Do we, in SDP Offers, allow port zero ONLY in "bundle-only" m- lines, = or in ANY bundled m- line (obviously, the semantics will vary)? Note that the UP does NOT require bundled port zero m- lines in SDP Answers= , and I am NOT suggesting a change to that. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) --_000_7594FB04B1934943A5C02806D1A2204B1C41D191ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Within SDP Offers and Answers, BUNDLE (-04)&nbs= p;does currently not allow usage of port zero in bundled m- lines.
 
However, due to the Berlin agreement = to move forward with the UP (unified plan), we need to change that for SDP = Offers, as port zero is used in bundled "bundle-only" m= - lines.
 
Now, as the agreed context for the UP was WEBRT= C only, we need to determine whether similar restrictions are needed in the= generic BUNDLE spec. We also need to decide whether port zero is allo= wed for "bundle-only" m- lines only, or for any bundled m- line.
 
So, a couple of questions:
 
Q10: Assuming we define the SDP bundle-only att= ribute in the BUNDLE spec, do we need to limit the scope to WEBRTC (or what= ever the scope also in the BUNDLE spec?
 
Q11: Do we, in SDP Offers, allow port zero ONLY= in "bundle-only" m- lines, or in ANY bundled m- line (obviously,= the semantics will vary)?
 
Note that the UP does NOT require bundled port = zero m- lines in SDP Answers, and I am NOT suggesting a change to that.
 
Regards,
 
Christer
 
 


Sent from Windows using TouchDown (www.nitrodesk.com)
--_000_7594FB04B1934943A5C02806D1A2204B1C41D191ESESSMB209erics_-- From hadriel.kaplan@oracle.com Mon Aug 5 07:51:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1AA21F9EA2 for ; Mon, 5 Aug 2013 07:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[AWL=-2.415, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, LONGWORDS=1.803, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8, SARE_BAYES_7x8=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IUXVqOltARD for ; Mon, 5 Aug 2013 07:51:25 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DBCC721F9ED1 for ; Mon, 5 Aug 2013 07:51:14 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75EpDvP032502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 14:51:13 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75EpCPx021625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 14:51:12 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75EpB73012474; Mon, 5 Aug 2013 14:51:11 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 07:51:11 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51F93E68.20705@alum.mit.edu> Date: Mon, 5 Aug 2013 10:51:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> References: <51F93E68.20705@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:51:33 -0000 On Jul 31, 2013, at 12:42 PM, Paul Kyzivat = wrote: > I don't understand how sendonly and recvonly reduce glare. > If I offer a sendonly m-line, it still must be answered. And = subsequently an offer for that m-line can come from either side, = possibly producing glare. >=20 > ISTM that you should offer a sendrecv m-line iff you intend a = bidirectional flow, where the two sides are related, will have common = properties and lifetimes. >=20 > There is still a problem if both sides want a bidirectional flow, but = aren't agreed on who should initiate it. In that case they both might = offer and glare. And there there remains the question of whether they = recognize this as glare, rather than thinking they need both flows. My understanding is the concept isn't such that there isn't an offer = going in both directions - there is an offer going in both directions. = But if the two offers don't "collide" in the things they change, then = it's not a glare, and instead they can just accept the offer they each = receive as an answer. So in the direction attribute case, if you send a=3Dsendonly and the = other side sent a=3Drecvonly, there is no collision - each side can just = treat the offer as an answer. Likewise if you both send "a=3Dsendrecv", = or both send "a=3Dinactive". We can even define rock-paper-scissor rules, as was done for when a = stream is removed and changed at the same time (in that case removal = trumps changing). For example, we can make it so that an "a=3Dinactive" = trumps all other directions; so regardless of what direction attribute = you sent, if you receive an "a=3Dinactive", that's the new state. We could even define a lookup table for it, like this: Sent Offer Rcvd Offer Local state -------------------------------------- sendrecv sendrecv sendrecv sendrecv sendonly recvonly sendrecv recvonly sendonly sendrecv inactive inactive sendonly sendrecv sendonly sendonly sendonly inactive sendonly recvonly sendonly sendonly inactive inactive recvonly sendrecv recvonly recvonly sendonly recvonly recvonly recvonly inactive recvonly inactive inactive inactive sendrecv inactive inactive sendonly inactive inactive recvonly inactive inactive inactive inactive -hadriel From christer.holmberg@ericsson.com Mon Aug 5 08:01:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D921F9FC3 for ; Mon, 5 Aug 2013 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=-2.027, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, LONGWORDS=1.803, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8, SARE_BAYES_7x8=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzYQTzCDN08n for ; Mon, 5 Aug 2013 08:01:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BA0AA21F9FD6 for ; Mon, 5 Aug 2013 08:01:37 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-ec-51ffbe50f637 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 62.C2.19388.05EBFF15; Mon, 5 Aug 2013 17:01:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 17:01:36 +0200 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [MMUSIC] unified plan glareless atomicity improvement Thread-Index: AQHOjefTpSIHc3SbG0aBA3v1ZtE4opl+3H0AgAe8nYCAACRyqg== Date: Mon, 5 Aug 2013 15:01:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41D869@ESESSMB209.ericsson.se> References: <51F93E68.20705@alum.mit.edu>, <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> In-Reply-To: <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41D869ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvrW7Avv+BBt1NchafNn1itpi6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj49Pb7EEMEdx2aSk5mSWpRbp2yVwZfyc/4ipYKZ7RdeRX6wN jP+tuxg5OCQETCQ+3bDpYuQEMsUkLtxbz9bFyMUhJHCYUeLCpRlMEM5iRom5C0+wgzSwCVhI dP/TBmkQEQiT+DdpGSuIzSygKvF66ncwW1jASWL/3O1sIOUiAs4Sc167QpQ7ScyfeZcFxGYR UJHY8LofzOYV8JWY/fEnM8SqRYwSb2d9ZwdJcArYSZzc2w9mMwId9/3UGiaIXeISt57MZ4I4 WkBiyZ7zzBC2qMTLx/+g7smXOHmijQligaDEyZlPWCYwisxC0j4LSdksJGUQcR2JBbs/sUHY 2hLLFr5mhrHPHHjMhCy+gJF9FSN7bmJmTnq5+SZGYDQd3PLbYAfjpvtihxilOViUxHk3650J FBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBoeWpVTQOPa8hy99JZd/pun5oZOr/l7pzfb/em Zx26IbDB/XzlbOFfiyfJ5kXoHkrnmtTYdj/CRTWePdnl2TEGgWsvmPK+ZUlKdZ1bP9dj27I0 xdZeb83qBrU98+TO1K5xSBNUtpS5/Hztz+wXf+N11iz9+tms4XuqbJZJolDL6evSMk5a30qU WIozEg21mIuKEwFs1zfOdAIAAA== Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:01:44 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41D869ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, you are basically saying that both endpoints can send partial offers fo= r the SAME m- line, WITHOUT "triggering" glare, if there is no "state colli= sion"??? My understanding of the UP (unified plan) was that you would still get glar= e if both endpoints simultaneously send a partial offer for the same m- lin= e. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hadriel Kaplan [hadriel.kaplan@oracle.com] To: Paul Kyzivat [pkyzivat@alum.mit.edu] CC: mmusic@ietf.org [mmusic@ietf.org] Subject: Re: [MMUSIC] unified plan glareless atomicity improvement On Jul 31, 2013, at 12:42 PM, Paul Kyzivat wrote: > I don't understand how sendonly and recvonly reduce glare. > If I offer a sendonly m-line, it still must be answered. And subsequently= an offer for that m-line can come from either side, possibly producing gla= re. > > ISTM that you should offer a sendrecv m-line iff you intend a bidirection= al flow, where the two sides are related, will have common properties and l= ifetimes. > > There is still a problem if both sides want a bidirectional flow, but are= n't agreed on who should initiate it. In that case they both might offer an= d glare. And there there remains the question of whether they recognize thi= s as glare, rather than thinking they need both flows. My understanding is the concept isn't such that there isn't an offer going = in both directions - there is an offer going in both directions. But if th= e two offers don't "collide" in the things they change, then it's not a gla= re, and instead they can just accept the offer they each receive as an answ= er. So in the direction attribute case, if you send a=3Dsendonly and the other = side sent a=3Drecvonly, there is no collision - each side can just treat th= e offer as an answer. Likewise if you both send "a=3Dsendrecv", or both se= nd "a=3Dinactive". We can even define rock-paper-scissor rules, as was done for when a stream = is removed and changed at the same time (in that case removal trumps changi= ng). For example, we can make it so that an "a=3Dinactive" trumps all othe= r directions; so regardless of what direction attribute you sent, if you re= ceive an "a=3Dinactive", that's the new state. We could even define a lookup table for it, like this: Sent Offer Rcvd Offer Local state -------------------------------------- sendrecv sendrecv sendrecv sendrecv sendonly recvonly sendrecv recvonly sendonly sendrecv inactive inactive sendonly sendrecv sendonly sendonly sendonly inactive sendonly recvonly sendonly sendonly inactive inactive recvonly sendrecv recvonly recvonly sendonly recvonly recvonly recvonly inactive recvonly inactive inactive inactive sendrecv inactive inactive sendonly inactive inactive recvonly inactive inactive inactive inactive -hadriel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C41D869ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
So, you are basically saying that both endpoint= s can send partial offers for the SAME m- line, WITHOUT "triggeri= ng" glare, if there is no "state collision"???
 
My understanding of the UP (unified plan) was t= hat you would still get glare if both endpoints simultaneously send a parti= al offer for the same m- line.
 
Regards,
 
Christer


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Paul Kyzivat [pkyzivat@alum.mit.edu]
CC: mmusic@ietf.org [mmusic@ietf.org]
Subject: Re: [MMUSIC] unified plan glareless atomicity improvement

On Jul 31, 2013, at 12:42 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wr= ote:

> I don't understand how sendonly and recvonly reduce glare.
> If I offer a sendonly m-line, it still must be answered. And subsequen= tly an offer for that m-line can come from either side, possibly producing = glare.
>
> ISTM that you should offer a sendrecv m-line iff you intend a bidirect= ional flow, where the two sides are related, will have common properties an= d lifetimes.
>
> There is still a problem if both sides want a bidirectional flow, but = aren't agreed on who should initiate it. In that case they both might offer= and glare. And there there remains the question of whether they recognize = this as glare, rather than thinking they need both flows.

My understanding is the concept isn't such that there isn't an offer going = in both directions - there is an offer going in both directions.  But = if the two offers don't "collide" in the things they change, then= it's not a glare, and instead they can just accept the offer they each receive as an answer.

So in the direction attribute case, if you send a=3Dsendonly and the other = side sent a=3Drecvonly, there is no collision - each side can just treat th= e offer as an answer.  Likewise if you both send "a=3Dsendrecv&qu= ot;, or both send "a=3Dinactive".

We can even define rock-paper-scissor rules, as was done for when a stream = is removed and changed at the same time (in that case removal trumps changi= ng).  For example, we can make it so that an "a=3Dinactive" = trumps all other directions; so regardless of what direction attribute you sent, if you receive an "a=3Dinactive", = that's the new state.

We could even define a lookup table for it, like this:

Sent Offer  Rcvd Offer      Local state
--------------------------------------
sendrecv    sendrecv      &nbs= p; sendrecv
sendrecv    sendonly      &nbs= p; recvonly
sendrecv    recvonly      &nbs= p; sendonly
sendrecv    inactive      &nbs= p; inactive
sendonly    sendrecv      &nbs= p; sendonly
sendonly    sendonly      &nbs= p; inactive
sendonly    recvonly      &nbs= p; sendonly
sendonly    inactive      &nbs= p; inactive
recvonly    sendrecv      &nbs= p; recvonly
recvonly    sendonly      &nbs= p; recvonly
recvonly    recvonly      &nbs= p; inactive
recvonly    inactive      &nbs= p; inactive
inactive    sendrecv      &nbs= p; inactive
inactive    sendonly      &nbs= p; inactive
inactive    recvonly      &nbs= p; inactive
inactive    inactive      &nbs= p; inactive

-hadriel

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C41D869ESESSMB209erics_-- From christer.holmberg@ericsson.com Mon Aug 5 08:10:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BF721F9EEB for ; Mon, 5 Aug 2013 08:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.736 X-Spam-Level: X-Spam-Status: No, score=-5.736 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crBXzKLVCvxV for ; Mon, 5 Aug 2013 08:10:44 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E24F621F99C3 for ; Mon, 5 Aug 2013 08:10:43 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-cd-51ffc072770c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2B.D1.00725.270CFF15; Mon, 5 Aug 2013 17:10:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 17:10:42 +0200 From: Christer Holmberg To: mmusic Thread-Topic: Can a partial offer be a full offer? Thread-Index: Ac6R7fOQodBfkqyrS32cTsmtr3W24Q== Date: Mon, 5 Aug 2013 15:10:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41D8F9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvrW7xgf+BBp2bGS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDk7prIWvBKu6H68nb2B8ahAFyMnh4SAicS262dYIGwxiQv3 1rN1MXJxCAkcZpS49GoVK4SzmFHiy7JlzF2MHBxsAhYS3f+0QRpEBGQk9m7azAxiCwsYSqzY 948ZIm4k8Wr9dCYIW0/i8pbbYDaLgIrE3YsLwJbxCvhKrNi2ASzOCLT4+6k1YDazgLjErSfz mSAOEpBYsuc8M4QtKvHy8T9WiJp8ia8nXrFBzBGUODnzCcsERsFZSNpnISmbhaQMIq4ncWPq FDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKvYmTPTczMSS833MQIDO+DW37r7mA8dU7kEKM0B4uS OO8mvTOBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhg5PWvunfsUtfDznvYdKzN2r/50UTL3 Z9Kt3/Ot4v+uvuXeeaKQi1fN8tmcaq3vTfpJE8MtF256E73kUcK/mPebOzaJV91ZfjTh2bd6 789hwYZbn/hPrT13fK7+685JclszXy0/td9WN8VM9Nj/JK7oue2vXa81XWM6wNhQuHre6gyu nUzbVnkUKrEUZyQaajEXFScCANlvSDI9AgAA Subject: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:10:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41D8F9ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I realize we are still far from having a working partial O/A solution, and = MMUSIC may not even be the place to discuss it, but I think we need to warm= up our brains a little, so I'll throw out a ball related to the semantics = :) When reading the UP draft, I can't find any restrictions on how many m- lin= es a partial offer can contain. So, I assume that means I can send a partial offer which contains ALL m- li= nes of my session SDP, i.e. it would look like a vanilla 3264 offer? Now, WHY would I do that? Well, if we are going to use something more "ligh= tweight" than re-INVITE/UPDATE to send partial offers, that may be a good r= eason. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) --_000_7594FB04B1934943A5C02806D1A2204B1C41D8F9ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
 
I realize we are still far from having a working partial O/A solution,= and MMUSIC may not even be the place to discuss it, but I think we need to= warm up our brains a little, so I'll throw out a ball related to the seman= tics :)
 
When reading the UP draft, I can't find any restrictions on how many m= - lines a partial offer can contain.
 
So, I assume that means I can send a partial offer which contains ALL = m- lines of my session SDP, i.e. it would look like a vanilla 3264 offer?
 
Now, WHY would I do that? Well, if we are going to use something = more "lightweight" than re-INVITE/UPDATE to send partial offers, = that may be a good reason.
 
Regards,
 
Christer
 

Sent from Windows using TouchDown (www.nitrodesk.com)
--_000_7594FB04B1934943A5C02806D1A2204B1C41D8F9ESESSMB209erics_-- From christer.holmberg@ericsson.com Mon Aug 5 08:17:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5083A21F9FE9 for ; Mon, 5 Aug 2013 08:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.745 X-Spam-Level: X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgtrfDFUoHXn for ; Mon, 5 Aug 2013 08:17:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF8921F940D for ; Mon, 5 Aug 2013 08:17:45 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-f0-51ffc218ba2f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 30.18.05990.812CFF15; Mon, 5 Aug 2013 17:17:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 17:17:44 +0200 From: Christer Holmberg To: mmusic Thread-Topic: [MMUSIC] UP: Can a partial offer be a full offer? Thread-Index: AQHOke7vCbCwhSX1mkyx6wsRumrcBQ== Date: Mon, 5 Aug 2013 15:17:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41D9A9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvra7Eof+BBsv3GVpMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGbsvrGcr2KZQ0bRnL2MD42LpLkYODgkBE4nr18S6GDmBTDGJ C/fWs4HYQgKHGSUePjLvYuQCshczStw5NJMNpJ5NwEKi+582SI2IgIzE3k2bmUFsYQE7iaXX T7NBxO0ldrW2M0HYehIXzrSwgNgsAioSD7YtYQWxeQV8Jf7dh7CFgOyZr/6DzeEU8JOY+KcH bA4j0D3fT60Bm8MsIC5x68l8Jog7BSSW7DnPDGGLSrx8/I8VoiZfYsWtZiaI+YISJ2c+YZnA KDwLSfssJGWzkJRBxPUkbkydwgZha0ssW/iaGcLWlZjx7xALsvgCRvZVjOy5iZk56eVGmxiB sXBwy2/VHYx3zokcYpTmYFES592sdyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+M0/d78 mfaiW1UeFHKu9jyz+OVR/Rtmu1i3G7u7V3jyrbI9/nqic8STqxyHJRPzz0W431PcoZ+8M+NS YDDD4Wq5jdH8Whx8k+9lv2BdOHe5yzT+r8kdxiaRz76prjkQO1ngyuEfz0O5IubPP/yjryfo yXP2Tz82WRyZuMmDKZ1x1eriXUI7T8spsRRnJBpqMRcVJwIA9630EVMCAAA= Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:17:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41D9A9ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Note that my re-INVITE/UPDATE example is based on the assumption that one c= an use partial offers/answers with SIP, on the wire. Not sure if that was p= art of the agreed scope for the UP. But, even without that, I think the question on including all m- lines on a= partial offer still applies :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Christer Holmberg [christer.holmberg@ericsson.com] To: mmusic [mmusic@ietf.org] Subject: [MMUSIC] UP: Can a partial offer be a full offer? Hi, I realize we are still far from having a working partial O/A solution, and = MMUSIC may not even be the place to discuss it, but I think we need to warm= up our brains a little, so I'll throw out a ball related to the semantics = :) When reading the UP draft, I can't find any restrictions on how many m- lin= es a partial offer can contain. So, I assume that means I can send a partial offer which contains ALL m- li= nes of my session SDP, i.e. it would look like a vanilla 3264 offer? Now, WHY would I do that? Well, if we are going to use something more "ligh= tweight" than re-INVITE/UPDATE to send partial offers, that may be a good r= eason. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) --_000_7594FB04B1934943A5C02806D1A2204B1C41D9A9ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Note that my re-INVITE/UPDATE example is based on the= assumption that one can use partial offers/answers with SIP, on the wire. = Not sure if that was part of the agreed scope for the UP.
 
But, even without that, I think the question on including all m- lines= on a partial offer still applies :)
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Christer Holmberg [christer.holmberg@ericsson.com]
To: mmusic [mmusic@ietf.org]
Subject: [MMUSIC] UP: Can a partial offer be a full offer?

Hi,
 
I realize we are still far from having a working partial O/A solution,= and MMUSIC may not even be the place to discuss it, but I think we need to= warm up our brains a little, so I'll throw out a ball related to the seman= tics :)
 
When reading the UP draft, I can't find any restrictions on how many m= - lines a partial offer can contain.
 
So, I assume that means I can send a partial offer which contains ALL = m- lines of my session SDP, i.e. it would look like a vanilla 3264 offer?
 
Now, WHY would I do that? Well, if we are going to use something = more "lightweight" than re-INVITE/UPDATE to send partial offers, = that may be a good reason.
 
Regards,
 
Christer
 

Sent from Windows using TouchDown= (www.nitrodesk.com)
--_000_7594FB04B1934943A5C02806D1A2204B1C41D9A9ESESSMB209erics_-- From adam@nostrum.com Mon Aug 5 08:21:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5623021E80C1 for ; Mon, 5 Aug 2013 08:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E33GoPXu4c0r for ; Mon, 5 Aug 2013 08:21:10 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5BA21F9E3B for ; Mon, 5 Aug 2013 08:20:32 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r75FKSRb076575 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 10:20:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51FFC2B5.4010508@nostrum.com> Date: Mon, 05 Aug 2013 10:20:21 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------050202080801060805020102" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:21:12 -0000 This is a multi-part message in MIME format. --------------050202080801060805020102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/5/13 10:17, Christer Holmberg wrote: > Note that my re-INVITE/UPDATE example is based on the assumption that > one can use partial offers/answers with SIP, on the wire. Not sure if > that was part of the agreed scope for the UP. From the phrasing the chairs used when asking the question, my understanding is that it's not. That doesn't mean that SIPCORE won't decide to come along and do it at some point in the future, but it's a different question for a different time. > But, even without that, I think the question on including all m- lines > on a partial offer still applies :) Yeah, I'm pondering this. I'll try to respond when I have my thoughts gathered. /a --------------050202080801060805020102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/5/13 10:17, Christer Holmberg wrote:
Note that my re-INVITE/UPDATE example is based on the assumption that one can use partial offers/answers with SIP, on the wire. Not sure if that was part of the agreed scope for the UP.

From the phrasing the chairs used when asking the question, my understanding is that it's not. That doesn't mean that SIPCORE won't decide to come along and do it at some point in the future, but it's a different question for a different time.

But, even without that, I think the question on including all m- lines on a partial offer still applies :)

Yeah, I'm pondering this. I'll try to respond when I have my thoughts gathered.

/a
--------------050202080801060805020102-- From hadriel.kaplan@oracle.com Mon Aug 5 08:21:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC0D21F9E04 for ; Mon, 5 Aug 2013 08:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbkfQxpE8QZD for ; Mon, 5 Aug 2013 08:21:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id D73BF21E80C1 for ; Mon, 5 Aug 2013 08:21:22 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75FLJeG026958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 15:21:20 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75FLIbM024861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 15:21:19 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75FLIue006478; Mon, 5 Aug 2013 15:21:18 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 08:21:18 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> Date: Mon, 5 Aug 2013 11:21:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:21:33 -0000 On Aug 5, 2013, at 10:06 AM, Christer Holmberg = wrote: > Within SDP Offers and Answers, BUNDLE (-04) does currently not allow = usage of port zero in bundled m- lines. > However, due to the Berlin agreement to move forward with the UP = (unified plan), we need to change that for SDP Offers, as port zero is = used in bundled "bundle-only" m- lines. > =20 > Now, as the agreed context for the UP was WEBRTC only, we need to = determine whether similar restrictions are needed in the generic BUNDLE = spec. My understanding of the consensus call was that the UP as a single, = collective whole was scoped for WebRTC for now. That doesn't mean = individual parts can't be generically applicable, nor that we can't = decide all the parts could be generically applicable in the end. > We also need to decide whether port zero is allowed for "bundle-only" = m- lines only, or for any bundled m- line. > So, a couple of questions: > =20 > Q10: Assuming we define the SDP bundle-only attribute in the BUNDLE = spec, do we need to limit the scope to WEBRTC (or whatever the scope = also in the BUNDLE spec? If the mechanism is backwards-compatible with not only existing RFCs, = but also existing deployed systems, I can't see a reason not to make the = mechanism generically applicable. It was my understanding that the = bundle-only port-0 concept requires and will always perform a second = offer/answer round, with real port numbers. Yes or no? > =20 > Q11: Do we, in SDP Offers, allow port zero ONLY in "bundle-only" m- = lines, or in ANY bundled m- line (obviously, the semantics will vary)? If I understand it correctly, a "bundle-only" m-line is one that you = only want to use if and only if the other end supports BUNDLE; a = "bundled" m-line is one you want to use regardless of whether the = far-end supports BUNDLE, but would want to bundle together if the = far-end does support BUDNLE. Correct? If so, then let's call the = "bundled" one a "bundle-up" for now, for "bundle upgrade". If the above is correct, then ISTM the goal of a "bundle-up" m-line is = (1) backwards compatibility, and (2) to successfully use the media = stream regardless of the far-end's BUNDLE support. For (1) I think it's = safer not to use a port of 0. For (2) I don't see a purpose in setting = an m-line to port 0. So why do it for bundle-up? -hadriel From adam@nostrum.com Mon Aug 5 08:31:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA0321F9ED4 for ; Mon, 5 Aug 2013 08:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szoXiq0tgcpj for ; Mon, 5 Aug 2013 08:31:39 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5693021F9C7B for ; Mon, 5 Aug 2013 08:31:23 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r75FVJQW077832 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 10:31:19 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51FFC541.1060406@nostrum.com> Date: Mon, 05 Aug 2013 10:31:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> In-Reply-To: <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:31:39 -0000 On 8/5/13 10:21, Hadriel Kaplan wrote: > It was my understanding that the bundle-only port-0 concept requires and will always perform a second offer/answer round, with real port numbers. Yes or no? The port-0 concept does *not* require a second exchange. There are a lot of circumstances in which a second exchange is likely to take place (cf. "Handshaking"), but none of these are influenced one way or another by the use of zero-ports on bundle-only initial offers. I presume you're concerned that the far end won't know which port to use? There's really not an issue here. These lines are interpreted by a bundle-aware implementation as having the same port number as the non-bundle-only lines that they're bundled together with. To be clear: you can't have a bundle that consists exclusively of bundle-only lines. At least one of them has to be non-bundle-only and have a real port number associated with it. /a From hadriel.kaplan@oracle.com Mon Aug 5 08:34:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEF321E804B for ; Mon, 5 Aug 2013 08:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec3EUTv8cwHP for ; Mon, 5 Aug 2013 08:34:27 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AF89921F9EF4 for ; Mon, 5 Aug 2013 08:34:27 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75FYOF1010140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 15:34:24 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75FYN1l009302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 15:34:24 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75FYNxB017098; Mon, 5 Aug 2013 15:34:23 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 08:34:23 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se> Date: Mon, 5 Aug 2013 11:34:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:34:34 -0000 On Aug 5, 2013, at 11:17 AM, Christer Holmberg = wrote: > Note that my re-INVITE/UPDATE example is based on the assumption that = one can use partial offers/answers with SIP, on the wire. Not sure if = that was part of the agreed scope for the UP. Definitely NOT agreed on. Doesn't mean it won't happen in the future, = but the scope of UP was limited to WebRTC for now. We can debate which = parts of UP are generically applicable, and which not. For SIP, this = isn't the right WG for that debate. > But, even without that, I think the question on including all m- lines = on a partial offer still applies :) I don't see why WebRTC would restrict itself in any way regarding the = number of m-lines in a partial offer/answer. Nothing "breaks" if all = m-lines are in it, does it? The real question is if it can be greater = than *one* m-line. If it can, and I think it can, then I can't see how = the exact quantity of them matters. The only downside is you increase = the chance of glare, I assume. Afaik, the 'mid' attribute is there to identity which m-lines in the = partial offer correspond to which m-lines in the full ordered set. (the = 'mid' could have even been an index number, except it's also used to = avoid glare when adding m-lines, which a numeric index wouldn't have = done) So what's the issue with one or multiple m-lines? -hadriel From hadriel.kaplan@oracle.com Mon Aug 5 08:40:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417C121F95A6 for ; Mon, 5 Aug 2013 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt++wDKM1jnB for ; Mon, 5 Aug 2013 08:39:53 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B1F5F21F90AC for ; Mon, 5 Aug 2013 08:39:53 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75FdpSH023081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 15:39:53 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75Fdola021736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 15:39:51 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75Fdo2s017931; Mon, 5 Aug 2013 15:39:50 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 08:39:50 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51FFC541.1060406@nostrum.com> Date: Mon, 5 Aug 2013 11:39:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:40:10 -0000 On Aug 5, 2013, at 11:31 AM, Adam Roach wrote: > On 8/5/13 10:21, Hadriel Kaplan wrote: >> It was my understanding that the bundle-only port-0 concept requires = and will always perform a second offer/answer round, with real port = numbers. Yes or no? >=20 > The port-0 concept does *not* require a second exchange. > There are a lot of circumstances in which a second exchange is likely = to take place (cf. "Handshaking"), but none of these are influenced one = way or another by the use of zero-ports on bundle-only initial offers. >=20 > I presume you're concerned that the far end won't know which port to = use? There's really not an issue here. These lines are interpreted by a = bundle-aware implementation as having the same port number as the = non-bundle-only lines that they're bundled together with. To be clear: = you can't have a bundle that consists exclusively of bundle-only lines. = At least one of them has to be non-bundle-only and have a real port = number associated with it. No, I'm concerned with usages other than WebRTC. The question was on = whether the bundle-only port-0 thing should be generically applicable, = or scoped to WebRTC. So I'm thinking of what its impact is on SIP usage = in the real world, including on things that go bump in the night. All = kinds of crap happens in the middle these days in SIP networks. (and no, = not only with SBCs) -hadriel From adam@nostrum.com Mon Aug 5 08:59:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9AA21F8C20 for ; Mon, 5 Aug 2013 08:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9KyFtkbXPmY for ; Mon, 5 Aug 2013 08:59:52 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DD00321F8CDD for ; Mon, 5 Aug 2013 08:59:44 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r75FxgnR081021 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 10:59:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51FFCBE8.9030601@nostrum.com> Date: Mon, 05 Aug 2013 10:59:36 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> In-Reply-To: <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:59:53 -0000 On 8/5/13 10:39, Hadriel Kaplan wrote: > No, I'm concerned with usages other than WebRTC. The question was on > whether the bundle-only port-0 thing should be generically applicable, > or scoped to WebRTC. So I'm thinking of what its impact is on SIP > usage in the real world, including on things that go bump in the > night. All kinds of crap happens in the middle these days in SIP > networks. (and no, not only with SBCs) I don't think I'd expect bundle-only lines to work through extra-specification bumps in the wire. If the bumps are upgraded to work with bundle, great, but I know that this won't happen overnight (and, for many corners of the network, ever). But given that these bumps in some sense serve as the "other end" of the connection, a failure to get bundle-only lines through them is merely the design working per its requirements. Remember, we're designing these lines to be fragile on purpose. That's the whole point of using a zero port: if we don't have end-to-end understanding of bundle-only, we need them to break. /a From christer.holmberg@ericsson.com Mon Aug 5 09:35:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3336821F8E2D for ; Mon, 5 Aug 2013 09:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.754 X-Spam-Level: X-Spam-Status: No, score=-5.754 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZHREDpo9e7D for ; Mon, 5 Aug 2013 09:35:23 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5821F9D0A for ; Mon, 5 Aug 2013 09:35:13 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-88-51ffd440a5e1 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7C.C8.19388.044DFF15; Mon, 5 Aug 2013 18:35:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 18:35:12 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] UP: Can a partial offer be a full offer? Thread-Index: AQHOke7vCbCwhSX1mkyx6wsRumrcBZmGnR2AgAAyiAo= Date: Mon, 5 Aug 2013 16:35:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> In-Reply-To: <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41DA7AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra7jlf+BBj2PGC0+bfrEbDF1+WMW ByaPJUt+Mnl8fHqLJYApissmJTUnsyy1SN8ugSvj6/E9bAUztSo+Nr5hbGBcpNzFyMkhIWAi 8ejcDVYIW0ziwr31bF2MXBxCAocZJY4+bGaBcBYzSkw5c4Kxi5GDg03AQqL7nzaIKSKgJ3H0 HidIL7OAjMSMs41MIGFhATuJvS+DQMIiAvYSu1rbmSBsK4kfk/aC2SwCKhJ3W3uAbHYOXgFf iYkmcEvf9W5kASnhBJrS+/cHI4jNCHTZ91NrmCA2iUvcejKfCeJiAYkle84zQ9iiEi8f/2OF qMmXaO/pAOvlFRCUODnzCcsERpFZSNpnISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dY kMUXMLKvYmTPTczMSS8338QIjJqDW34b7GDcdF/sEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhgLJ7+6aSxRxXmcm1d5d9gldjUzmw1Wj/ZEH+O3OxIrYiFfPbVWYidD 748bbslnqoLSFjcmbF/BWx2zKifqhaGh9f9Jb8tezquK0fBrkRD8wzv5bJTExFVK8z1TJbTf Bh2Z7SPDEcGUWe55kClarnGn4NO4EOm7rT+F7t6a6yC64bZVfO/fOiWW4oxEQy3mouJEAEEi 9IpoAgAA Cc: mmusic Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:35:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41DA7AESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I see no issue with multiple m- lines - just wanted to verify that it would= be allowed :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hadriel Kaplan [hadriel.kaplan@oracle.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: mmusic [mmusic@ietf.org] Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? On Aug 5, 2013, at 11:17 AM, Christer Holmberg wrote: > Note that my re-INVITE/UPDATE example is based on the assumption that one= can use partial offers/answers with SIP, on the wire. Not sure if that was= part of the agreed scope for the UP. Definitely NOT agreed on. Doesn't mean it won't happen in the future, but = the scope of UP was limited to WebRTC for now. We can debate which parts o= f UP are generically applicable, and which not. For SIP, this isn't the ri= ght WG for that debate. > But, even without that, I think the question on including all m- lines on= a partial offer still applies :) I don't see why WebRTC would restrict itself in any way regarding the numbe= r of m-lines in a partial offer/answer. Nothing "breaks" if all m-lines ar= e in it, does it? The real question is if it can be greater than *one* m-l= ine. If it can, and I think it can, then I can't see how the exact quantit= y of them matters. The only downside is you increase the chance of glare, = I assume. Afaik, the 'mid' attribute is there to identity which m-lines in the partia= l offer correspond to which m-lines in the full ordered set. (the 'mid' cou= ld have even been an index number, except it's also used to avoid glare whe= n adding m-lines, which a numeric index wouldn't have done) So what's the = issue with one or multiple m-lines? -hadriel --_000_7594FB04B1934943A5C02806D1A2204B1C41DA7AESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I see no issue with multiple m- lines - just wa= nted to verify that it would be allowed :)
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: mmusic [mmusic@ietf.org]
Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer?

On Aug 5, 2013, at 11:17 AM, Christer Holmberg <christer.holmberg@ericss= on.com> wrote:

> Note that my re-INVITE/UPDATE example is based on the assumption that = one can use partial offers/answers with SIP, on the wire. Not sure if that = was part of the agreed scope for the UP.

Definitely NOT agreed on.  Doesn't mean it won't happen in the future,= but the scope of UP was limited to WebRTC for now.  We can debate whi= ch parts of UP are generically applicable, and which not.  For SIP, th= is isn't the right WG for that debate.


> But, even without that, I think the question on including all m- lines= on a partial offer still applies :)

I don't see why WebRTC would restrict itself in any way regarding the numbe= r of m-lines in a partial offer/answer.  Nothing "breaks" if= all m-lines are in it, does it?  The real question is if it can be gr= eater than *one* m-line.  If it can, and I think it can, then I can't see how the exact quantity of them matters.  The on= ly downside is you increase the chance of glare, I assume.

Afaik, the 'mid' attribute is there to identity which m-lines in the partia= l offer correspond to which m-lines in the full ordered set. (the 'mid' cou= ld have even been an index number, except it's also used to avoid glare whe= n adding m-lines, which a numeric index wouldn't have done)  So what's the issue with one or multiple m= -lines?

-hadriel

 --_000_7594FB04B1934943A5C02806D1A2204B1C41DA7AESESSMB209erics_-- From christer.holmberg@ericsson.com Mon Aug 5 09:48:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42BC21F9FE1 for ; Mon, 5 Aug 2013 09:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.763 X-Spam-Level: X-Spam-Status: No, score=-5.763 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J20ep+KgYkMF for ; Mon, 5 Aug 2013 09:48:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B745921F9C34 for ; Mon, 5 Aug 2013 09:48:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-80-51ffd754da1a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F1.B7.00725.457DFF15; Mon, 5 Aug 2013 18:48:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 18:48:20 +0200 From: Christer Holmberg To: Adam Roach , Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) Thread-Index: Ac6R5QNzX6rIT4ISR+aNUyxTJPkKj///80wAgAACyICAADcTag== Date: Mon, 5 Aug 2013 16:48:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41DADF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com>, <51FFC541.1060406@nostrum.com> In-Reply-To: <51FFC541.1060406@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41DADFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrW7I9f+BBsfOm1vs+buI3eLTpk/M FlOXP2ZxYPZYsuQnk8esnU9YPD4+vcUSwBzFZZOSmpNZllqkb5fAlTFrx27Ggl6tisUTP7I2 MD5V7mLk5JAQMJG4cvcOC4QtJnHh3nq2LkYuDiGBw4wSzzr2M4IkhAQWM0rsPljexcjBwSZg IdH9TxskLCLgK3Hx4kxmEJtZQEZixtlGJhBbWKBA4sDl5awQNYUSl+//ZgVpFRFwkpg+sQDE ZBFQkZi6VwekghdoyvqrN1khti5glHj0v4EdpIZTQFviRG8ESA0j0GXfT61hgtgkLnHryXwm iIsFJJbsOc8MYYtKvHz8jxWiJl/i4rwjTBDzBSVOznzCMoFRZBaS9llIymYhKYOI60ncmDqF DcLWlli28DUzhK0rMePfIRZk8QWM7KsY2XMTM3PSyw03MQIj6eCW37o7GE+dEznEKM3BoiTO u0nvTKCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxvTSUMMEB6u3e55K//RXt598adqqbM5l gs7Hez+rMZ3MstiqzL+0y+f4urKLK67yXc1Pai1n9lqaqlm69Ejqgc03gl6lc9vc2V6aosZf yXcga49br1zK7Z0myeHTha51eDPJl9stXmd3n1HFaduCivPr3ktUXPDJXlUz2VOc7bu+0bEE 5kP5SizFGYmGWsxFxYkAFv8/q3ICAAA= Cc: mmusic Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:48:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41DADFESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As Adam indicated, the need to send a second offer isn't introduced by port= zero. Currently the second offer is always sent after the initial offer (s= ome comments were raised regarding that, but it is a separate discussion). Having said that, if a second offer IS sent (for whatever reason), I assume= that the actual bundle port value would be assigned also to the bundle-onl= y m- lines (assuming the answerer supports bundle-only, that is)? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Adam Roach [adam@nostrum.com] To: Hadriel Kaplan [hadriel.kaplan@oracle.com] CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmusic@ietf= .org] Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in= bundled m- lines (SDP Offers only) On 8/5/13 10:21, Hadriel Kaplan wrote: > It was my understanding that the bundle-only port-0 concept requires and = will always perform a second offer/answer round, with real port numbers. Y= es or no? The port-0 concept does *not* require a second exchange. There are a lot of circumstances in which a second exchange is likely to take place (cf. "Handshaking"), but none of these are influenced one way or another by the use of zero-ports on bundle-only initial offers. I presume you're concerned that the far end won't know which port to use? There's really not an issue here. These lines are interpreted by a bundle-aware implementation as having the same port number as the non-bundle-only lines that they're bundled together with. To be clear: you can't have a bundle that consists exclusively of bundle-only lines. At least one of them has to be non-bundle-only and have a real port number associated with it. /a --_000_7594FB04B1934943A5C02806D1A2204B1C41DADFESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
As Adam indicated, the need to send a seco= nd offer isn't introduced by port zero. Currently the second offer is alway= s sent after the initial offer (some comments were raised regarding that, b= ut it is a separate discussion).
 
Having said that, if a second offer IS sent (fo= r whatever reason), I assume that the actual bundle port value would be ass= igned also to the bundle-only m- lines (assuming the answerer supports bund= le-only, that is)?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Adam Roach [adam@nostrum.com]
To: Hadriel Kaplan [hadriel.kaplan@oracle.com]
CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmus= ic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero u= sage in bundled m- lines (SDP Offers only)
On 8/5/13 10:21, Hadriel Kaplan wrote:
> It was my understanding that the bundle-only port-0 concept requires a= nd will always perform a second offer/answer round, with real port numbers.=   Yes or no?

The port-0 concept does *not* require a second exchange.

There are a lot of circumstances in which a second exchange is likely to take place (cf. "Handshaking"), but none of these are influenced = one way
or another by the use of zero-ports on bundle-only initial offers.

I presume you're concerned that the far end won't know which port to
use? There's really not an issue here. These lines are interpreted by a bundle-aware implementation as having the same port number as the
non-bundle-only lines that they're bundled together with. To be clear:
you can't have a bundle that consists exclusively of bundle-only lines. At least one of them has to be non-bundle-only and have a real port
number associated with it.

/a
 --_000_7594FB04B1934943A5C02806D1A2204B1C41DADFESESSMB209erics_-- From hadriel.kaplan@oracle.com Mon Aug 5 09:48:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10F321F9FC3 for ; Mon, 5 Aug 2013 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz0KBvZjYU9w for ; Mon, 5 Aug 2013 09:48:51 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 60EC821F9EB6 for ; Mon, 5 Aug 2013 09:48:46 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75GmhVq030124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 16:48:44 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75Gmhts011958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 16:48:43 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75Gmgvb011230; Mon, 5 Aug 2013 16:48:42 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 09:48:42 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <51FFCBE8.9030601@nostrum.com> Date: Mon, 5 Aug 2013 12:48:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <51FFCBE8.9030601@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:49:00 -0000 On Aug 5, 2013, at 11:59 AM, Adam Roach wrote: > On 8/5/13 10:39, Hadriel Kaplan wrote: >> No, I'm concerned with usages other than WebRTC. The question was on = whether the bundle-only port-0 thing should be generically applicable, = or scoped to WebRTC. So I'm thinking of what its impact is on SIP usage = in the real world, including on things that go bump in the night. All = kinds of crap happens in the middle these days in SIP networks. (and no, = not only with SBCs) >=20 > I don't think I'd expect bundle-only lines to work through = extra-specification bumps in the wire. If the bumps are upgraded to work = with bundle, great, but I know that this won't happen overnight (and, = for many corners of the network, ever). But given that these bumps in = some sense serve as the "other end" of the connection, a failure to get = bundle-only lines through them is merely the design working per its = requirements. >=20 > Remember, we're designing these lines to be fragile on purpose. That's = the whole point of using a zero port: if we don't have end-to-end = understanding of bundle-only, we need them to break. Sure, but the problem I'm worried about is when they break in weird ways = - like they fail in the answer phase rather than offer phase; or they = appear to succeed in SDP, but there's no media; or not enough bandwidth = is allocated in controlled pipes; or the call gets torn down some time = later by those bumps-in-the-wire. -hadriel From christer.holmberg@ericsson.com Mon Aug 5 09:59:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD441F0D52 for ; Mon, 5 Aug 2013 09:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.772 X-Spam-Level: X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvzz3qF9GhGl for ; Mon, 5 Aug 2013 09:59:17 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5FD421F9F3D for ; Mon, 5 Aug 2013 09:59:16 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-ff-51ffd9e3e096 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D6.28.00725.3E9DFF15; Mon, 5 Aug 2013 18:59:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 18:59:15 +0200 From: Christer Holmberg To: mmusic Thread-Topic: Meaning of "scope is WEBRTC" Thread-Index: Ac6R/R3kheGg3J0cRN604x+uNsUCKA== Date: Mon, 5 Aug 2013 16:59:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41DB40ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+Jvre7jm/8DDZadsLCYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mn5OXc1asF+4omHtL+YGxjsCXYycHBICJhJfO1+xQthiEhfu rWfrYuTiEBI4zChx59dVKGcxo8TsK1eZuhg5ONgELCS6/2mDNIgIyEjs3bSZGcQWFtCU2LV1 KRNEXEvi/c79LBC2nsSNzSvAbBYBFYneL/tYQMbwCvhKdHQGgIQZgfZ+P7UGrJVZQFzi1pP5 TBD3CEgs2XOeGcIWlXj5+B8rRE2+xOlXP9lBbF4BQYmTM5+wTGAUnIWkfRaSsllIyiDiQBdN ncIGYWtLLFv4mhnC1pWY8e8QC7L4Akb2VYzsuYmZOenlhpsYgcF9cMtv3R2Mp86JHGKU5mBR EufdpHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjipPOv+m/XjT3ibldK6mcHZP65Eb9 a9P94jYqM+foyP4y6UrVPLlH/4bP9dMJs1yF9m3uLDgbP9/m8u4SzvDALV/fzL4dLTGBPyDT J8HKT/HZ2r2qPprP2zsO7fjbIqP5ae22mTw+2act3QskXB5tFi4x1snavnJPl02Rmut/hlM7 HrFr+ZQqsRRnJBpqMRcVJwIAu1jTXDwCAAA= Subject: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:59:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41DB40ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, While cleaning up my MMUSIC notes today, I was listening to the audio recor= ding, in order to get a clarification regarding what "scope is WEBRTC" real= ly means. However, unless I missed something, I didn't get a clear answer. Does it only cover the browser API (JSEP) or does it also cover something t= hat can be sent out on the wire (as long as it is not SIP) by a browser? Feel free to tell me that it is a stupid question, and that the answer is v= ery clear :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) --_000_7594FB04B1934943A5C02806D1A2204B1C41DB40ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
While cleaning up my MMUSIC notes today, I was = listening to the audio recording, in order to get a clarification regarding= what "scope is WEBRTC" really means.  However, unless I mis= sed something, I didn't get a clear answer.
 
Does it only cover the browser API (JSEP) = or does it also cover something that can be sent out on the wire (as long a= s it is not SIP) by a browser?
 
Feel free to tell me that it is a stupid questi= on, and that the answer is very clear :)
 
Regards,
 
Christer
 


Sent from Windows using TouchDown (www.nitrodesk.com)
--_000_7594FB04B1934943A5C02806D1A2204B1C41DB40ESESSMB209erics_-- From christer.holmberg@ericsson.com Mon Aug 5 10:05:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C415821F9F3D for ; Mon, 5 Aug 2013 10:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.78 X-Spam-Level: X-Spam-Status: No, score=-5.78 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk+v7piaR1Q5 for ; Mon, 5 Aug 2013 10:05:29 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 980E621F9EF4 for ; Mon, 5 Aug 2013 10:05:23 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-78-51ffdb512f57 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D5.5E.05990.15BDFF15; Mon, 5 Aug 2013 19:05:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Mon, 5 Aug 2013 19:05:21 +0200 From: Christer Holmberg To: Hadriel Kaplan , Adam Roach Thread-Topic: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) Thread-Index: AQHOkfuxQP+jLN773kOpD9GU/Ld9gJmG1/eK Date: Mon, 5 Aug 2013 17:05:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41DBA6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <51FFCBE8.9030601@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41DBA6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvrW7Q7f+BBg27mC32/F3EbvFp0ydm i6nLH7M4MHssWfKTyWPWzicsHh+f3mIJYI7isklJzcksSy3St0vgylgz9xt7wTvDikunL7E0 MLZrdTFyckgImEi8vrSXDcIWk7hwbz2QzcUhJHCYUWLl3WZmCGcxo8SRKUvZuxg5ONgELCS6 /2mDNIgI+EqcPXyfEcRmFlCX6PndwgxiCwsUSMzZ+ZwVpFxEoFBixWlJiHIjieuLJrGD2CwC KhL7u+ewgti8QGM+7DnGBLFqJZPEspdnmUASnAJ2EhNmLGEBsRmBjvt+ag0TxC5xiVtP5jNB HC0gsWTPeWYIW1Ti5eN/rBA1+RIHPx9mhlggKHFy5hOWCYwis5C0z0JSNgtJGURcR2LB7k9s ELa2xLKFr5lh7DMHHjMhiy9gZF/FyJ6bmJmTXm60iREYTwe3/FbdwXjnnMghRmkOFiVx3s16 ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MAZnx8qyr99/XER+zt6EIuZAQ8XQ3ncamppS qdGuLjMDD9lFq92ebKcUMPGA8FRV4S9JgQYbeZ943HrN4PfarvTwialq/3pC9KzL1vPeZPOq NJhlULr45hne+qSvtsZfDy5+xMKZdefBgvvzl82dwqku+dloLe9it0OqMbduuHAz82Qs1f78 R4mlOCPRUIu5qDgRADGtimR1AgAA Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:05:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41DBA6ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In SIP, unless you have control of each node between the endpoints, the onl= y way to guarantee a "consistent break" is by using Proxy-Require. But, as we know, that sucks, because it would mandate entities that could n= ot care less about SDP (yes, such entities DO still exist :) to support bun= dle-only. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hadriel Kaplan [hadriel.kaplan@oracle.com] To: Adam Roach [adam@nostrum.com] CC: mmusic (E-mail) [mmusic@ietf.org] Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in= bundled m- lines (SDP Offers only) On Aug 5, 2013, at 11:59 AM, Adam Roach wrote: > On 8/5/13 10:39, Hadriel Kaplan wrote: >> No, I'm concerned with usages other than WebRTC. The question was on whe= ther the bundle-only port-0 thing should be generically applicable, or scop= ed to WebRTC. So I'm thinking of what its impact is on SIP usage in the rea= l world, including on things that go bump in the night. All kinds of crap h= appens in the middle these days in SIP networks. (and no, not only with SBC= s) > > I don't think I'd expect bundle-only lines to work through extra-specific= ation bumps in the wire. If the bumps are upgraded to work with bundle, gre= at, but I know that this won't happen overnight (and, for many corners of t= he network, ever). But given that these bumps in some sense serve as the "o= ther end" of the connection, a failure to get bundle-only lines through the= m is merely the design working per its requirements. > > Remember, we're designing these lines to be fragile on purpose. That's th= e whole point of using a zero port: if we don't have end-to-end understandi= ng of bundle-only, we need them to break. Sure, but the problem I'm worried about is when they break in weird ways - = like they fail in the answer phase rather than offer phase; or they appear = to succeed in SDP, but there's no media; or not enough bandwidth is allocat= ed in controlled pipes; or the call gets torn down some time later by those= bumps-in-the-wire. -hadriel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C41DBA6ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In SIP, unless you have control of each node between = the endpoints, the only way to guarantee a "consistent break" is = by using Proxy-Require.
But, as we know, that sucks, because it would ma= ndate entities that could not care less about SDP (yes, such entities DO st= ill exist :) to support bundle-only.
 
Regards,
 
Christer
 

Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Adam Roach [adam@nostrum.com]
CC: mmusic (E-mail) [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero u= sage in bundled m- lines (SDP Offers only)

On Aug 5, 2013, at 11:59 AM, Adam Roach <adam@nostrum.com> wrote:

> On 8/5/13 10:39, Hadriel Kaplan wrote:
>> No, I'm concerned with usages other than WebRTC. The question was = on whether the bundle-only port-0 thing should be generically applicable, o= r scoped to WebRTC. So I'm thinking of what its impact is on SIP usage in t= he real world, including on things that go bump in the night. All kinds of crap happens in the middle these days i= n SIP networks. (and no, not only with SBCs)
>
> I don't think I'd expect bundle-only lines to work through extra-speci= fication bumps in the wire. If the bumps are upgraded to work with bundle, = great, but I know that this won't happen overnight (and, for many corners o= f the network, ever). But given that these bumps in some sense serve as the "other end" of the connec= tion, a failure to get bundle-only lines through them is merely the design = working per its requirements.
>
> Remember, we're designing these lines to be fragile on purpose. That's= the whole point of using a zero port: if we don't have end-to-end understa= nding of bundle-only, we need them to break.

Sure, but the problem I'm worried about is when they break in weird ways - = like they fail in the answer phase rather than offer phase; or they appear = to succeed in SDP, but there's no media; or not enough bandwidth is allocat= ed in controlled pipes; or the call gets torn down some time later by those bumps-in-the-wire.

-hadriel

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C41DBA6ESESSMB209erics_-- From matthew@matthew.at Mon Aug 5 12:42:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8A921F9EA7 for ; Mon, 5 Aug 2013 12:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyTKFm0OPKen for ; Mon, 5 Aug 2013 12:42:34 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id A300021F9E9A for ; Mon, 5 Aug 2013 12:42:34 -0700 (PDT) Received: from [10.92.38.212] (50-0-2-26.static.sonic.net [50.0.2.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id E8E251480B9 for ; Mon, 5 Aug 2013 12:42:31 -0700 (PDT) Message-ID: <5200000A.40102@matthew.at> Date: Mon, 05 Aug 2013 12:42:02 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------030409010803090200040800" Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:42:40 -0000 This is a multi-part message in MIME format. --------------030409010803090200040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/5/2013 9:59 AM, Christer Holmberg wrote: > Hi, > While cleaning up my MMUSIC notes today, I was listening to the audio > recording, in order to get a clarification regarding what "scope is > WEBRTC" really means. However, unless I missed something, I didn't get > a clear answer. > Does it only cover the browser API (JSEP) or does it also cover > something that can be sent out on the wire (as long as it is not SIP) > by a browser? > And what if it passes through a gateway that doesn't inspect the SDP and blindly passes it to a SIP device. What happens then? RTCWEB used SDP so it would be compatible with SIP legacy devices, so certainly this will work... or something about all this has gone off the rails. Matthew Kaufman --------------030409010803090200040800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/5/2013 9:59 AM, Christer Holmberg wrote:
Hi,
 
While cleaning up my MMUSIC notes today, I was listening to the audio recording, in order to get a clarification regarding what "scope is WEBRTC" really means.  However, unless I missed something, I didn't get a clear answer.
 
Does it only cover the browser API (JSEP) or does it also cover something that can be sent out on the wire (as long as it is not SIP) by a browser?
 


And what if it passes through a gateway that doesn't inspect the SDP and blindly passes it to a SIP device. What happens then?

RTCWEB used SDP so it would be compatible with SIP legacy devices, so certainly this will work... or something about all this has gone off the rails.

Matthew Kaufman
--------------030409010803090200040800-- From pkyzivat@alum.mit.edu Mon Aug 5 14:25:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA6F21F9D98 for ; Mon, 5 Aug 2013 14:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNsQcT12AsEo for ; Mon, 5 Aug 2013 14:25:29 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 29D4721F9ACA for ; Mon, 5 Aug 2013 14:25:28 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id 8zLX1m0041vXlb85D9RUql; Mon, 05 Aug 2013 21:25:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 99RU1m00M3ZTu2S3d9RUza; Mon, 05 Aug 2013 21:25:28 +0000 Message-ID: <52001847.3090805@alum.mit.edu> Date: Mon, 05 Aug 2013 23:25:27 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> In-Reply-To: <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.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=q20121106; t=1375737928; bh=2FqPbcOhSscBDN8QJbhkcepyHNRBK1SIBjAhi57DD78=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hkp1weR81dOQADQRkQTqC7pq3bJM/8s5gl4FUCrfYlvqIaQKohtlocxzqFhf1ELtF qyzGPfw4z5sQKVXhv8G/vEpDhTDPO4YGVTVXy0OmzJxSeVK5QuSNJr+wAjqDFndlzV GF9bjb+BhL+ieK3pD4vVIMfrFvzRQoZLMocMBCd5ZxGEmQvCeZ/jDlENY6LyfGFqBA ompWFzzFMcAIzUBWsfCcXp0oH47I+YWgueeNdwQyCDvxSkwGnW2ALcspFfY+snK5Xm x+VoCvfCPeawQHOXs2CJRxuPajAmJhENWGevFwEyMbNg1bB5BWbEua9nNZYcZIQzmZ EnB7j6f7GLKDQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:25:35 -0000 On 8/5/13 4:51 PM, Hadriel Kaplan wrote: > > On Jul 31, 2013, at 12:42 PM, Paul Kyzivat wrote: > >> I don't understand how sendonly and recvonly reduce glare. >> If I offer a sendonly m-line, it still must be answered. And subsequently an offer for that m-line can come from either side, possibly producing glare. >> >> ISTM that you should offer a sendrecv m-line iff you intend a bidirectional flow, where the two sides are related, will have common properties and lifetimes. >> >> There is still a problem if both sides want a bidirectional flow, but aren't agreed on who should initiate it. In that case they both might offer and glare. And there there remains the question of whether they recognize this as glare, rather than thinking they need both flows. > > My understanding is the concept isn't such that there isn't an offer going in both directions - there is an offer going in both directions. But if the two offers don't "collide" in the things they change, then it's not a glare, and instead they can just accept the offer they each receive as an answer. That isn't my understanding. My understanding was that the intent was to reduce the probability that there will be concurrent offers from both sides for the same subset of the SDP. > So in the direction attribute case, if you send a=sendonly and the other side sent a=recvonly, there is no collision - each side can just treat the offer as an answer. Likewise if you both send "a=sendrecv", or both send "a=inactive". Assume that we did an initial full O/A, and m-line#1 sendonly for X and recvonly for Y. Subsequently, one side, or the other, or both, may wish to make a change to the media section headed by m-line#1. For instance, one side may wish to change the codec list - perhaps drop one of the PTs from the initial O/A, or add a new one. If both sides attempt this then there is still glare. One can't assume that one side won't ever have need to do this. > We can even define rock-paper-scissor rules, as was done for when a stream is removed and changed at the same time (in that case removal trumps changing). For example, we can make it so that an "a=inactive" trumps all other directions; so regardless of what direction attribute you sent, if you receive an "a=inactive", that's the new state. Having one side change the directionality is just one of the multitude of changes that might come up. It probably isn't the most significant one. The likelihood if it will be reduced if sendrecv is never used. > We could even define a lookup table for it, like this: > > Sent Offer Rcvd Offer Local state > -------------------------------------- > sendrecv sendrecv sendrecv > sendrecv sendonly recvonly > sendrecv recvonly sendonly > sendrecv inactive inactive > sendonly sendrecv sendonly > sendonly sendonly inactive > sendonly recvonly sendonly > sendonly inactive inactive > recvonly sendrecv recvonly > recvonly sendonly recvonly > recvonly recvonly inactive > recvonly inactive inactive > inactive sendrecv inactive > inactive sendonly inactive > inactive recvonly inactive > inactive inactive inactive If nothing else was changed, then there could be some advantage to this in reducing glare. But it doesn't help with changing anything else about the media section. And while similar rules might be worked out for some of those things, I think it will be hard. (Similar in scale and complexity to draft-nandakumar-mmusic-sdp-mux-attributes.) I think it is probably true that using sendonly and recvonly when adding *new* m-lines may work out better than using sendrecv and counting on the other side to pair the reverse direction. But even then it will only matter with certain usage scenarios. IMO the key to using sendrecv is not to avoid it entirely, but rather to figure out when it makes sense. I think that is when you *want* "fate sharing" between the paired streams. Thanks, Paul From hadriel.kaplan@oracle.com Mon Aug 5 14:58:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B77921F9E01 for ; Mon, 5 Aug 2013 14:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLT83XLX5jW9 for ; Mon, 5 Aug 2013 14:58:17 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2140A21F93D4 for ; Mon, 5 Aug 2013 14:58:16 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75LwE5Z000558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 21:58:15 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75LwDuY010537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 21:58:14 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75LwDfi010523; Mon, 5 Aug 2013 21:58:13 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 14:58:13 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <52001847.3090805@alum.mit.edu> Date: Mon, 5 Aug 2013 17:58:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05467AC4-04ED-403C-BDA2-3869E6E32C4B@oracle.com> References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <52001847.3090805@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:58:23 -0000 On Aug 5, 2013, at 5:25 PM, Paul Kyzivat wrote: >> My understanding is the concept isn't such that there isn't an offer = going in both directions - there is an offer going in both directions. = But if the two offers don't "collide" in the things they change, then = it's not a glare, and instead they can just accept the offer they each = receive as an answer. >=20 > That isn't my understanding. My understanding was that the intent was = to reduce the probability that there will be concurrent offers from both = sides for the same subset of the SDP. Huh. Yup you could be right. Heck if I know - I'm only going by what I = thought Martin said at the mic in the meeting. I thought he said it = would be useful to reduce glare if all that changed was direction = attribute on both sides. (like you both hit "hold" or "un-hold" = whatever) But I could easily be misunderstanding what he said. -hadriel From hadriel.kaplan@oracle.com Mon Aug 5 15:01:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBB521F9CAD for ; Mon, 5 Aug 2013 15:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orvJ3nRcNToY for ; Mon, 5 Aug 2013 15:00:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D8EAF21F9BF1 for ; Mon, 5 Aug 2013 15:00:59 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75M0tQn002843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 22:00:56 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75M0ss7016462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 22:00:55 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75M0swU007431; Mon, 5 Aug 2013 22:00:54 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 15:00:54 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41D869@ESESSMB209.ericsson.se> Date: Mon, 5 Aug 2013 18:00:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7810C843-44A3-42C4-A4D1-5FCBC033A195@oracle.com> References: <51F93E68.20705@alum.mit.edu>, <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41D869@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "mmusic_ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:01:06 -0000 On Aug 5, 2013, at 11:01 AM, Christer Holmberg = wrote: > =20 > So, you are basically saying that both endpoints can send partial = offers for the SAME m- line, WITHOUT "triggering" glare, if there is no = "state collision"??? > =20 > My understanding of the UP (unified plan) was that you would still get = glare if both endpoints simultaneously send a partial offer for the same = m- line.=20 Currently in the UP draft, that's true. I thought Martin's point at the = mic was we could do a bit better for specific attribute changes, such as = direction, of the same m-line. Or I could be reading something into his = words that he didn't intend. I eagerly await his email to enlighten us. :) -hadriel From hadriel.kaplan@oracle.com Mon Aug 5 15:45:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047A021F9D7A for ; Mon, 5 Aug 2013 15:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.879 X-Spam-Level: X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Relmh+h4--3d for ; Mon, 5 Aug 2013 15:45:35 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C5C5C21F9A30 for ; Mon, 5 Aug 2013 15:45:32 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r75MjTbM017201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 22:45:31 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75MjSW3024344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Aug 2013 22:45:29 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r75MjRKQ027236; Mon, 5 Aug 2013 22:45:28 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Aug 2013 15:45:27 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <52001847.3090805@alum.mit.edu> Date: Mon, 5 Aug 2013 18:45:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <45E41954-372E-4483-B526-1C92EF0656C8@oracle.com> References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <52001847.3090805@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:45:42 -0000 On Aug 5, 2013, at 5:25 PM, Paul Kyzivat wrote: > Having one side change the directionality is just one of the multitude = of changes that might come up. It probably isn't the most significant = one. The likelihood if it will be reduced if sendrecv is never used. Afaict in *SIP* the most common causes of glare are (1) transport = addr:port changes and (2) directionality attribute changes. Usually = early in calls, like in the first few seconds; sometimes in the middle = of calls, if both sides press a hold button at the same time for = example.[1] But yeah since the use-case that drove UP is basically hangouts, Martin = probably did mean something completely unrelated to what I was thinking. -hadriel [1] It's hard to generalize them into "most common causes", because = there're plenty of other cases too; and probably different people see = different cases more/less frequently. From christer.holmberg@ericsson.com Mon Aug 5 15:55:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D3321F9EF6 for ; Mon, 5 Aug 2013 15:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.188 X-Spam-Level: X-Spam-Status: No, score=-5.188 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_44=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07G7+NBXel4S for ; Mon, 5 Aug 2013 15:55:41 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A6E6021F9EE5 for ; Mon, 5 Aug 2013 15:55:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-58-52002d642b94 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 25.E5.00725.46D20025; Tue, 6 Aug 2013 00:55:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 00:55:31 +0200 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [MMUSIC] unified plan glareless atomicity improvement Thread-Index: AQHOjefTpSIHc3SbG0aBA3v1ZtE4opl+3H0AgAe8nYCAAG4qgIAAFlcAgAAj7NA= Date: Mon, 5 Aug 2013 22:55:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41E15C@ESESSMB209.ericsson.se> References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <52001847.3090805@alum.mit.edu> <45E41954-372E-4483-B526-1C92EF0656C8@oracle.com> In-Reply-To: <45E41954-372E-4483-B526-1C92EF0656C8@oracle.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrELMWRmVeSWpSXmKPExsUyM+JvrW6KLkOQwY8zshafNn1itpi6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj49Pb7EEMEdx2aSk5mSWpRbp2yVwZUxc/5q1YAVPxf99J1gb GPu5uhg5OSQETCQWn/nJCGGLSVy4t56ti5GLQ0jgMKNE+9v37BDOYkaJaS8eMncxcnCwCVhI dP/TBmkQEQiT+DdpGStImFlAXeLq4iCQsLCAk8SrG/vYQMIiAs4Sc167QlT7SRz9+IUFJMwi oCKxdVtmFyM7B6+Ar8RPVYg1vxglLlx5yw5SzSlgJ7H3xEKwwxiBDvt+ag0TiM0sIC7x4eB1 ZoiDBSSW7DkPZYtKvHz8jxXCVpL4seESC0S9nsSNqVPYIGxtiWULX4PV8woISpyc+YRlAqPY LCRjZyFpmYWkZRaSlgWMLKsY2XMTM3PSyw03MQLj5eCW37o7GE+dEznEKM3BoiTOu0nvTKCQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGRjXBVjYXh1i+zBNqb3ms5raWpIjsPhFz5c+ai3Fv o7b+qbqwx3b/4dNhK9Q2cWVl7d7SEuR3TWD6opnKEw++iZLdFmFq1/9CMlZq5lXvXBm9I5+K Slgm6d12maX1ISNwXqO6+N6d0nF35BbFfl0arKc/c/Xr2Ts+vfzUdOIUe+PP6hvfd9b0RSix FGckGmoxFxUnAgCDE5raZQIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 22:55:46 -0000 Hi, If you use separate m- lines per media direction, there MAY be a smaller ri= sk that both endpoints try to modify the same m- line. Maybe that is what h= e was talking about :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Hadriel Kaplan L=E4hetetty: 6. elokuuta 2013 1:45 Vastaanottaja: Paul Kyzivat Kopio: mmusic@ietf.org Aihe: Re: [MMUSIC] unified plan glareless atomicity improvement On Aug 5, 2013, at 5:25 PM, Paul Kyzivat wrote: > Having one side change the directionality is just one of the multitude of= changes that might come up. It probably isn't the most significant one. Th= e likelihood if it will be reduced if sendrecv is never used. Afaict in *SIP* the most common causes of glare are (1) transport addr:port= changes and (2) directionality attribute changes. Usually early in calls,= like in the first few seconds; sometimes in the middle of calls, if both s= ides press a hold button at the same time for example.[1] But yeah since the use-case that drove UP is basically hangouts, Martin pro= bably did mean something completely unrelated to what I was thinking. -hadriel [1] It's hard to generalize them into "most common causes", because there'r= e plenty of other cases too; and probably different people see different ca= ses more/less frequently. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Tue Aug 6 08:49:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189FE11E80D3 for ; Tue, 6 Aug 2013 08:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQaYQpHxndAT for ; Tue, 6 Aug 2013 08:49:14 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB5721F9C7B for ; Tue, 6 Aug 2013 08:49:13 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id 9SKd1m0030QuhwU5ETpDig; Tue, 06 Aug 2013 15:49:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 9TpD1m00N3ZTu2S3NTpDtd; Tue, 06 Aug 2013 15:49:13 +0000 Message-ID: <52011AF8.10003@alum.mit.edu> Date: Tue, 06 Aug 2013 17:49:12 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> In-Reply-To: <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.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=q20121106; t=1375804153; bh=lssPGRE7ei/S0q/5tqpeDSmqrxLYSxsaJ+O4BR+pR5w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VWhs/61W7IDHxZkkpYBD/AG6d0aAX8a+p/YABFw/WYWi2R+e1dtFOYhlt0d37gOOp K97DPViVX8WnCrgkhzGGR46rbNlEnFTWjfNhwSeMKpGNfpYZIpqc4vt20y9OiYqjJ0 /hjdiLRo+EVizobGbEgNMN7HM27CxSU4jnUF+9JPzLgU+tlvCYKcRrTz1MIG92ESEG Pp6DOKnXZdi91IXHxPOeGM5k3hyRiYjP5pbC5IeyRpig14OTk5w4ANoDQlEOs5OpJ6 FNd8msLgW57O07ApQmYXUX7kuTPQ882sbwuEww2V7yDcD/5GDmnmeq6ItPfqsK9pXY XmlPIYiV29Qww== Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:49:19 -0000 I don't really understand the "only for WebRTC" agreement. I do see how defining extensions to O/A might be done only for WebRTC and not for 3264. (I don't *agree*, but I do *understand* that.) But BUNDLE is a change to SDP, and SDP extensions are required to specify how they interact with O/A. I don't think it makes any sense to say that such changes only apply to WebRTC. They should apply to anything that chooses to claim support to the BUNDLE draft. Thanks, Paul On 8/5/13 5:39 PM, Hadriel Kaplan wrote: > > On Aug 5, 2013, at 11:31 AM, Adam Roach wrote: > >> On 8/5/13 10:21, Hadriel Kaplan wrote: >>> It was my understanding that the bundle-only port-0 concept requires and will always perform a second offer/answer round, with real port numbers. Yes or no? >> >> The port-0 concept does *not* require a second exchange. >> There are a lot of circumstances in which a second exchange is likely to take place (cf. "Handshaking"), but none of these are influenced one way or another by the use of zero-ports on bundle-only initial offers. >> >> I presume you're concerned that the far end won't know which port to use? There's really not an issue here. These lines are interpreted by a bundle-aware implementation as having the same port number as the non-bundle-only lines that they're bundled together with. To be clear: you can't have a bundle that consists exclusively of bundle-only lines. At least one of them has to be non-bundle-only and have a real port number associated with it. > > No, I'm concerned with usages other than WebRTC. The question was on whether the bundle-only port-0 thing should be generically applicable, or scoped to WebRTC. So I'm thinking of what its impact is on SIP usage in the real world, including on things that go bump in the night. All kinds of crap happens in the middle these days in SIP networks. (and no, not only with SBCs) > > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Tue Aug 6 08:59:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CF221F85BB for ; Tue, 6 Aug 2013 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.828 X-Spam-Level: X-Spam-Status: No, score=-5.828 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnnxSg4IX-Hy for ; Tue, 6 Aug 2013 08:59:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEAD21F9CF1 for ; Tue, 6 Aug 2013 08:59:33 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-d5-52011d651875 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4E.E5.05990.56D11025; Tue, 6 Aug 2013 17:59:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 17:59:33 +0200 From: Christer Holmberg To: Paul Kyzivat , mmusic_ietf.org Thread-Topic: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) Thread-Index: AQHOkryG+afa8aj9VkWD+BDhF1I6ipmIVmgc Date: Tue, 6 Aug 2013 15:59:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41EAF2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com>, <52011AF8.10003@alum.mit.edu> In-Reply-To: <52011AF8.10003@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41EAF2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvrW6qLGOQQfNhQYupyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4vnAOe8Fy64pdDx8yNjB+M+xi5OSQEDCR eNN6kAnCFpO4cG89WxcjF4eQwGFGieY/c9khnMWMEi9v/WfpYuTgYBOwkOj+pw3SICLgLfGh 4TQriC0sUCBx4PJyVoh4ocTl+7+hbCOJd7eaWEBsFgEVia2Pt4At4xXwlehZcpERYv4XRok9 l48wgiQ4BbQk2pYtYAOxGYEu+n5qDVgDs4C4xK0n86EuFZBYsuc8M4QtKvHy8T9WiJp8iXnr b7JDLBCUODnzCcsERuFZSNpnISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2Jk z03MzEkvN9rECIySg1t+q+5gvHNO5BCjNAeLkjjvZr0zgUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYhT17ZSTc3j1o+aD29Zy32+znPR6Z597o3/TkiEy5vXP2Bd+Drtnz2dW4NHMrJ9+a qaYqvtXok5R/c/OjC5UGj49HfP2wT+fc1ItfTRgdNi//YvDy0O4ZiafvGCk23cnirH8pFhnc dylR98/mvTEv5irUPdnRv9Lgj6xLy5rsZ1tPT7MtjZilpcRSnJFoqMVcVJwIABHcFEdgAgAA Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:59:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41EAF2ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, Personally, I intend to focus mainly on the technical parts - others will t= hen have to tell me what/how to write in order to scope some feature, if ne= eded :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Paul Kyzivat [pkyzivat@alum.mit.edu] To: mmusic@ietf.org [mmusic@ietf.org] Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in= bundled m- lines (SDP Offers only) I don't really understand the "only for WebRTC" agreement. I do see how defining extensions to O/A might be done only for WebRTC and not for 3264. (I don't *agree*, but I do *understand* that.) But BUNDLE is a change to SDP, and SDP extensions are required to specify how they interact with O/A. I don't think it makes any sense to say that such changes only apply to WebRTC. They should apply to anything that chooses to claim support to the BUNDLE draft. Thanks, Paul On 8/5/13 5:39 PM, Hadriel Kaplan wrote: > > On Aug 5, 2013, at 11:31 AM, Adam Roach wrote: > >> On 8/5/13 10:21, Hadriel Kaplan wrote: >>> It was my understanding that the bundle-only port-0 concept requires an= d will always perform a second offer/answer round, with real port numbers. = Yes or no? >> >> The port-0 concept does *not* require a second exchange. >> There are a lot of circumstances in which a second exchange is likely to= take place (cf. "Handshaking"), but none of these are influenced one way o= r another by the use of zero-ports on bundle-only initial offers. >> >> I presume you're concerned that the far end won't know which port to use= ? There's really not an issue here. These lines are interpreted by a bundle= -aware implementation as having the same port number as the non-bundle-only= lines that they're bundled together with. To be clear: you can't have a bu= ndle that consists exclusively of bundle-only lines. At least one of them h= as to be non-bundle-only and have a real port number associated with it. > > No, I'm concerned with usages other than WebRTC. The question was on whe= ther the bundle-only port-0 thing should be generically applicable, or scop= ed to WebRTC. So I'm thinking of what its impact is on SIP usage in the re= al world, including on things that go bump in the night. All kinds of crap= happens in the middle these days in SIP networks. (and no, not only with S= BCs) > > -hadriel > > _______________________________________________ > 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 --_000_7594FB04B1934943A5C02806D1A2204B1C41EAF2ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Paul,
 
Personally, I intend to focus mainly on th= e technical parts - others will then have to tell me what/how to write in o= rder to scope some feature, if needed :)
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [pkyzivat@alum.mit.edu]
To: mmusic@ietf.org [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero u= sage in bundled m- lines (SDP Offers only)
I don't really understand the "only for WebRT= C" agreement.
I do see how defining extensions to O/A might be done only for WebRTC
and not for 3264. (I don't *agree*, but I do *understand* that.)

But BUNDLE is a change to SDP, and SDP extensions are required to
specify how they interact with O/A. I don't think it makes any sense to say that such changes only apply to WebRTC. They should apply to
anything that chooses to claim support to the BUNDLE draft.

        Thanks,
        Paul

On 8/5/13 5:39 PM, Hadriel Kaplan wrote:
>
> On Aug 5, 2013, at 11:31 AM, Adam Roach <adam@nostrum.com> wrote= :
>
>> On 8/5/13 10:21, Hadriel Kaplan wrote:
>>> It was my understanding that the bundle-only port-0 concept re= quires and will always perform a second offer/answer round, with real port = numbers.  Yes or no?
>>
>> The port-0 concept does *not* require a second exchange.
>> There are a lot of circumstances in which a second exchange is lik= ely to take place (cf. "Handshaking"), but none of these are infl= uenced one way or another by the use of zero-ports on bundle-only initial o= ffers.
>>
>> I presume you're concerned that the far end won't know which port = to use? There's really not an issue here. These lines are interpreted by a = bundle-aware implementation as having the same port number as the non-bundl= e-only lines that they're bundled together with. To be clear: you can't have a bundle that consists exclusively of bu= ndle-only lines. At least one of them has to be non-bundle-only and have a = real port number associated with it.
>
> No, I'm concerned with usages other than WebRTC.  The question wa= s on whether the bundle-only port-0 thing should be generically applicable,= or scoped to WebRTC.  So I'm thinking of what its impact is on SIP us= age in the real world, including on things that go bump in the night.  All kinds of crap happens in the middle these = days in SIP networks. (and no, not only with SBCs)
>
> -hadriel
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C41EAF2ESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Aug 6 09:14:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FD521F9F5C for ; Tue, 6 Aug 2013 09:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.834 X-Spam-Level: X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEWAHY0OJplY for ; Tue, 6 Aug 2013 09:14:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3A021F8C20 for ; Tue, 6 Aug 2013 09:14:30 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-d0-520120e695a4 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 18.16.19388.6E021025; Tue, 6 Aug 2013 18:14:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 18:14:28 +0200 From: Christer Holmberg To: mmusic Thread-Topic: Interactions between POFs, PANs and 3264 Offer/Answers Thread-Index: Ac6SwAaH+8B2wVyxQFSEGu6rKTxpcQ== Date: Tue, 6 Aug 2013 16:14:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41EC88ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvre4zBcYgg2nb+CymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI13Z7IV7BCt2HT2IVsD4xfBLkZODgkBE4nlB+YwQ9hiEhfu rWfrYuTiEBI4zCgxZd8kJghnMaPExG/HWLsYOTjYBCwkuv9pgzSICMhI7N20GaxZWMBe4vv1 HkaIuIvE/XM/mCBsPYkfZ5eC2SwCKhJrNu9hAbF5BXwlXjZMZgOxGYEWfz+1BqyGWUBc4taT +UwQBwlILNlzHuo4UYmXj/+xQtTkS7x/tpwJYo6gxMmZT1gmMArOQtI+C0nZLCRlEHE9iRtT p7BB2NoSyxa+ZoawdSVm/DvEgiy+gJF9FSN7bmJmTnq5+SZGYHgf3PLbYAfjpvtihxilOViU xHk3650JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBYJORyMu5alkrDjOKIA6G7hTnXfgw6 eJ/rncg/5yVHrrQ1smRdeeIo9O5zc/weLjeH9kk/DoiL9cdsX87/57/j22VLLnfdbpuWGOUZ EK3ilt746p69dM9XPmb2hcnt9pun966cxvLy9YLiu4dqP/IJhK44OFNnZpfaq8j0nj0GBolb 0q0aEhOUWIozEg21mIuKEwE9/KjnPQIAAA== Subject: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:14:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41EC88ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, It has been indicated that POFs (partial offers) and PANs (partial answers)= form a stand-alone mechanism, instead of being an extension of RFC3264. Now, assuming that is true, we still need to describe the interaction betwe= en POFs, PANs and 3264 Offer/Answers. Because, if I send a POF, and then receive a 3264 Offer (including the same= m- line as the POF), there is a glare and I need to reject the 3264 Offer= . In the same way, if I send a 3264 Offer, and receive a POF (including the s= ame m- line as the 3264 Offer), there is a glare and I need to reject the P= OF. I ASSUME the above is clear to everyone, including the authors of the UP, b= ut IF someone has a different opinion I'd like to hear about it :) Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) --_000_7594FB04B1934943A5C02806D1A2204B1C41EC88ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
 
It has been indicated that POFs (partial offers) and PANs (partial ans= wers) form a stand-alone mechanism, instead of being an exte= nsion of RFC3264.

Now, assuming that is true, we still need to describe the interaction betwe= en POFs, PANs and 3264 Offer/Answers.
 
Because, if I send a POF, and then receive a 3264 Offer (includin= g the same m- line as the POF),  there is a glare and I need to reject= the 3264 Offer.
 
In the same way, if I send a 3264 Offer, and receive a POF (inclu= ding the same m- line as the 3264 Offer), there is a glare and I need to re= ject the POF.
 
 --089e013cb7cc9098cb04e35cbd71-- From christer.holmberg@ericsson.com Wed Aug 7 08:21:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD3421F9C68 for ; Wed, 7 Aug 2013 08:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yryzN1jlwgoJ for ; Wed, 7 Aug 2013 08:21:35 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BBC0021E8136 for ; Wed, 7 Aug 2013 08:21:28 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-28-520265f7bbe1 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FC.D0.05990.7F562025; Wed, 7 Aug 2013 17:21:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 17:21:27 +0200 From: Christer Holmberg To: Mary Barnes , Paul Kyzivat Thread-Topic: [MMUSIC] UP: Meaning of "scope is WEBRTC" Thread-Index: Ac6R/R3kheGg3J0cRN604x+uNsUCKAA8dQUAAB20PCD///pbgIAAFRGA///YZWA= Date: Wed, 7 Aug 2013 15:21:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C421552ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvre73VKYgg00btSw+79/PbDF1+WMW ixUbDrA6MHv8ff+ByWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyjj+qJOx4MAkxopDq38w NjBOre9i5OSQEDCR2H92GSOELSZx4d56ti5GLg4hgcOMEt9W/GKEcBYzSmy73QXkcHCwCVhI dP/TBmkQEQiROP+qhQUkzCygLnF1cRBIWFjATGLOxzYWiBJziYavD5ghbD+JZUtusoPYLAIq Ekt29IHZvAK+ErNbbrNArNrBJHFowkSwZk6BQIk3zefAihiBjvt+ag0TiM0sIC7x4eB1Zoij BSSW7DkPZYtKvHz8jxXCVpL4seESC0R9vsTLpzeZIZYJSpyc+YRlAqPoLCSjZiEpm4WkDCKu J3Fj6hQ2CFtbYtnC11D1uhIz/h1iQRZfwMi+ipE9NzEzJ73caBMjMNIObvmtuoPxzjmRQ4zS HCxK4ryb9c4ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAUb39Q6XJs2luDsualywX4jU88 mc33stj25xauX2Z77kiLuK354GC5tbdkCd/PK3eSmR/mnz319eH63Ww+ngc643Oin+QWWQjV GnqY9HF8D7W8Hj1jpx7ryy4O8asXjkvM/J0SnbV6n8MK3efndfbbzZ3tKNNpwSEmVLXNreLj 5MecR99pca9QYinOSDTUYi4qTgQAtz+YLYICAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:21:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C421552ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Ok, so what is "RTCWEB usage" then? :) For example, if I implement a JavaScript SIP app, and want to use the UP wi= th SIP on the wire, would that be a "RTCWEB usage"? My understanding is tha= t it would NOT be. My personal understanding of the scope is: 1) JSEP; and 2) Browser-to-browser cases where we KNOW there are no intermediaries = etc in between. Regards, Christer L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Mary Barnes L=E4hetetty: 7. elokuuta 2013 17:56 Vastaanottaja: Paul Kyzivat Kopio: mmusic@ietf.org Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat > wrote: On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote: As one of those that used the term, my intention was that the initial decision was to agree to define what RTCWEB needed. As each dependent working group looks at the extensions they need to do, then they need to make the decision as to whether a wider scope of possible, desirable, or dangerous. So the BUNDLE status at the moment is that any changes for the unified plan should work for RTCWEB usage, but not for general. It would probably make sense to make it more generally applicable, but that is the next step in the decision process, and may need some other technical decisions before it happens. I don't know how you intend the above to be parsed. Specifically, when you = say: "any changes for the unified plan should work for RTCWEB usage" Do you mean: 1) that the changes should be designed solely with RTCWEB usage in mind? (B= ut are still applicable in other environments that find them useful and cho= ose to adopt them.) Or do you mean: 2) that those changes should not be used in any environment other than RTCW= EB? I might be able to accept (1), but not (2). [MB] I would agree with your (1), however, not with the parenthetical part.= I would suggest that be "But MAY still be applicable in other environment= s... " My concern is that at this point in time, you can't say that the c= hanges ARE applicable to other environments .... [/MB] Thanks, Paul Keith ------------------------------------------------------------------------ *From:*mmusic-bounces@ietf.org [mailto:mmus= ic-bounces@ietf.org] *On Behalf Of *Bernard Aboba *Sent:* 07 August 2013 00:50 *To:* Christer Holmberg; mmusic *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" Christer said: "While cleaning up my MMUSIC notes today, I was listening to the audio recording, in order to get a clarification regarding what "scope is WEBRTC" really means. However, unless I missed something, I didn't get a clear answer. Does it only cover the browser API (JSEP) or does it also cover something that can be sent out on the wire (as long as it is not SIP) by a browser? Feel free to tell me that it is a stupid question, and that the answer is very clear :)" [BA] I actually think it is a good question :) One interpretation of "scope is WebRTC" is that the SDP in "Unified Plan" applies to use within the JSEP API. As a result, one might expect the SDP used in createOffer, setLocalDescription and setRemoteDescription to resemble that in the "Unified Plan" document. Since signaling is out of scope for WebRTC, applications that use the JSEP API might or might not use the "Unified Plan" SDP in signaling on the wire. However, "Unified Plan" includes normative references to published SDP specifications that were developed for general use, and the adoption of "Unified Plan" (or even an applicability statement within the "Unified Plan" document) doesn't change the applicability of those documents. Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgroup: SIMULCAST) Ultimately, I am expecting the work involved in "Unified Plan" to span multiple documents, and to clarify the applicability, those individual documents will need to explain what they apply to (just WebRTC use or more general use). _______________________________________________ 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 --_000_7594FB04B1934943A5C02806D1A2204B1C421552ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Ok, so wha= t is ”RTCWEB usage” then? :)

 = ;

For exampl= e, if I implement a JavaScript SIP app, and want to use the UP with SIP on = the wire, would that be a “RTCWEB usage”? My understanding is that it would NOT be.

 = ;

My persona= l understanding of the scope is:

 = ;

1)      JS= EP; and

2)      Br= owser-to-browser cases where we KNOW there are no intermediaries etc in bet= ween.

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mary Barnes
L=E4hetetty: 7. elokuuta 2013 17:56
Vastaanottaja: Paul Kyzivat
Kopio: mmusic@ietf.org
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

 

On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:

On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:<= /o:p>

As one of those that used the term, my intention was= that the initial
decision was to agree to define what RTCWEB needed.

As each dependent working group looks at the extensions they need to do, then they need to make the decision as to whether a wider scope of
possible, desirable, or dangerous.

So the BUNDLE status at the moment is that any changes for the unified
plan should work for RTCWEB usage, but not for general. It would
probably make sense to make it more generally applicable, but that is
the next step in the decision process, and may need some other technical decisions before it happens.

 

I don't know how you intend the above to be parsed. = Specifically, when you say:


  "any changes for the unified plan should work for RTCWEB usage&= quot;

Do you mean:

1) that the changes should be designed solely with RTCWEB usage in mind? (B= ut are still applicable in other environments that find them useful and cho= ose to adopt them.)

Or do you mean:

2) that those changes should not be used in any environment other than RTCW= EB?

I might be able to accept (1), but not (2).

[MB] I would agree with your (1), however, not with = the parenthetical part.  I would suggest that be "But MAY still b= e applicable in other environments... "   My concern is that at t= his point in time, you can't say that the changes ARE applicable to other environments ....  [/MB]

 


        Thanks,
        Paul

Keith

------------------------------------------------------------------------
*From:*mmusic-= bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On
Behalf Of *Bernard Aboba
*Sent:* 07 August 2013 00:50
*To:* Christer Holmberg; mmusic
*Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"



Christer said:

"While cleaning up my MMUSIC notes today, I was listening to the audio=
recording, in order to get a clarification regarding what "scope is WEBRTC" really means.  However, unless I missed something, I didn= 't get
a clear answer.

Does it only cover the browser API (JSEP) or does it also cover
something that can be sent out on the wire (as long as it is not SIP) by a browser?

Feel free to tell me that it is a stupid question, and that the answer
is very clear :)"

[BA]  I actually think it is a good question :)

One interpretation of "scope is WebRTC"  is that the  S= DP in "Unified
Plan" applies to use within  the JSEP API.    As a resu= lt, one
might expect the SDP used in createOffer, setLocalDescription and
setRemoteDescription to resemble that in the "Unified Plan" docum= ent.
Since signaling is out of scope for WebRTC, applications that use the
JSEP API might or might not use the "Unified Plan" SDP in signali= ng on
the wire.

However, "Unified Plan" includes normative references to publishe= d SDP
specifications that were developed for general use, and the adoption of
"Unified Plan" (or even an applicability statement within the &qu= ot;Unified
Plan" document) doesn't change the applicability of those documents.
Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgro= up:
SIMULCAST)

Ultimately, I am expecting the work involved in "Unified Plan" to= span
multiple documents, and to clarify the applicability,  those individua= l
documents will need to explain what they apply to (just WebRTC use or
more general use).


_____________________= __________________________
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

 

--_000_7594FB04B1934943A5C02806D1A2204B1C421552ESESSMB209erics_-- From christer.holmberg@ericsson.com Wed Aug 7 08:25:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0524C21F9ADC for ; Wed, 7 Aug 2013 08:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWIRNtyUFIS2 for ; Wed, 7 Aug 2013 08:25:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2284821F86B1 for ; Wed, 7 Aug 2013 08:25:04 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-49-520266cfcaba Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 33.DB.00725.FC662025; Wed, 7 Aug 2013 17:25:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 17:25:03 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers Thread-Index: Ac6SwAaH+8B2wVyxQFSEGu6rKTxpcQALCkmAABMWT0AACiF6gAAIL0Ew Date: Wed, 7 Aug 2013 15:25:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C421565@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> <5201871B.4090903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C41F8D5@ESESSMB209.ericsson.se> <52024B2F.1030900@alum.mit.edu> In-Reply-To: <52024B2F.1030900@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI 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+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre75NKYgg48TtCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj4d0OxoK//BWnP55ka2A8x9PFyMkhIWAi sfDKCnYIW0ziwr31bF2MXBxCAocZJeZNm8IE4SxmlPi3u4Wli5GDg03AQqL7nzZIg4iAr8Sz x7fZQGxhAR+Jqd+WM4KUgMTPT6mBMN0kjj41A6lgEVCRmD19PiOIzQtUMffrblaI6VcYJX78 WwI2hlNAR+LljH/MIDYj0D3fT61hArGZBcQlPhy8zgxxp4DEkj3noWxRiZeP/7FC2EoSPzZc YoGo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG9tzEzJz0 csNNjMBIOLjlt+4OxlPnRA4xSnOwKInzbtI7EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB UaBN+cRPgRNR5le3PVlge2itRo7ppw12gSuNJ1+JDnRfobd3+knXqJcPAgpStrOrmYqmnD+/ /XT1y6At29/0nru/VTtgYk3LJ+kftZ83RzdW79CPnpIsfNswWZx95XVDo+V9X1xvPqlRNpvI 4adyaHHHtRbt+Y/m6dYmV35MO/PqyNQPkkuO5SqxFGckGmoxFxUnAgAbWwABUgIAAA== Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:25:16 -0000 Hi, > What about adding a new m-line into a bundle? > IIUC this is likely to be one of the most important use cases. > Can this all be done with POF and PAN? I have been thinking about that, because BUNDLE is one example where a chan= ge to one m- line may have impacts on other m- lines. Also, my understanding of the UP is that a PAN can only contain m- line tha= t were present in the POF. So, if the POF triggers additional m- lines to b= e changed on the remote side, those m- lines cannot be placed into the PAN. Regards, Christer =09 On 8/7/13 8:39 AM, Christer Holmberg wrote: > Hi, > >>> It has been indicated that POFs (partial offers) and PANs (partial answ= ers) form a stand-alone mechanism, instead of being an extension of RFC3264= . >>> >>> Now, assuming that is true, we still need to describe the interaction b= etween POFs, PANs and 3264 Offer/Answers. >>> >>> Because, if I send a POF, and then receive a 3264 Offer (including the = same m- line as the POF), there is a glare and I need to reject the 3264 O= ffer. >>> >>> In the same way, if I send a 3264 Offer, and receive a POF (including t= he same m- line as the 3264 Offer), there is a glare and I need to reject t= he POF. >>> >>> I ASSUME the above is clear to everyone, including the authors of the U= P, but IF someone has a different opinion I'd like to hear about it :) >> >> That is certainly what I had been assuming. Of course, if the POF is a n= ew m-line (that is, it doesn't appear in the offer coming the other way), t= hen there is no glare condition. > > Correct - assuming that the addition of the new m- lines does not indirec= tly affect values etc associated with existing m- lines. > > 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 mary.ietf.barnes@gmail.com Wed Aug 7 08:25:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0644221F9B53 for ; Wed, 7 Aug 2013 08:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh95lRz4+d-i for ; Wed, 7 Aug 2013 08:25:20 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id D46D721F9CA4 for ; Wed, 7 Aug 2013 08:25:14 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id cz11so1053684qeb.25 for ; Wed, 07 Aug 2013 08:25:14 -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=QRJPMZvp8TM11TO8mP3Z1Wq9zeGOaZrma7bfMn1g6Nw=; b=y8LNJLaFkELPCNcXEU0YvQtA8uIkbLXrTHnQGc1CDlOtiu0JI+BIyEPrtuXBXKCQiu qiKort6bheZSoqydOgVAcVpOz23zoZ3XneOlBBZePBSye5yW7ty2Jj8Q/fsayKoh9PkM WSR2kxgSXVANCVCqXzOp5LqLm263tkZYwoCLta3mX9AbTMg3bpdazHamVV9yi3wKpZE7 p3Rj+TjdxPHqlO++KxyraFnhx21syd5+Y9RM+AfgwmOUL9OA1NJmn6Ix5m/PwRva6Ie2 Sdjeh1j8lMcAgm9Ha+SQLnoK7kwPfXi0qRvzSZf+7Gkr+IsHGaJ9rS+xXGgbqoGyxOzQ vejw== MIME-Version: 1.0 X-Received: by 10.224.169.3 with SMTP id w3mr1288797qay.13.1375889114262; Wed, 07 Aug 2013 08:25:14 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Wed, 7 Aug 2013 08:25:14 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> Date: Wed, 7 Aug 2013 10:25:14 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e011823a2e7f66804e35d25a3 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:25:21 -0000 --089e011823a2e7f66804e35d25a3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi,**** > > ** ** > > Ok, so what is =94RTCWEB usage=94 then? :)**** > > ** ** > > For example, if I implement a JavaScript SIP app, and want to use the UP > with SIP on the wire, would that be a =93RTCWEB usage=94? My understandin= g is > that it would NOT be.**** > > ** ** > > My personal understanding of the scope is: > [MB] That is also my understanding. [/MB] > **** > > ** ** > > **1) **JSEP; and**** > > **2) **Browser-to-browser cases where we KNOW there are no > intermediaries etc in between.**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > ** ** > > *L=E4hett=E4j=E4:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.or= g] *Puolesta > *Mary Barnes > *L=E4hetetty:* 7. elokuuta 2013 17:56 > *Vastaanottaja:* Paul Kyzivat > *Kopio:* mmusic@ietf.org > *Aihe:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"**** > > ** ** > > On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat > wrote:**** > > On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:**** > > As one of those that used the term, my intention was that the initial > decision was to agree to define what RTCWEB needed. > > As each dependent working group looks at the extensions they need to do, > then they need to make the decision as to whether a wider scope of > possible, desirable, or dangerous. > > So the BUNDLE status at the moment is that any changes for the unified > plan should work for RTCWEB usage, but not for general. It would > probably make sense to make it more generally applicable, but that is > the next step in the decision process, and may need some other technical > decisions before it happens.**** > > ** ** > > I don't know how you intend the above to be parsed. Specifically, when yo= u > say:**** > > > "any changes for the unified plan should work for RTCWEB usage"**** > > Do you mean: > > 1) that the changes should be designed solely with RTCWEB usage in mind? > (But are still applicable in other environments that find them useful and > choose to adopt them.) > > Or do you mean: > > 2) that those changes should not be used in any environment other than > RTCWEB? > > I might be able to accept (1), but not (2).**** > > [MB] I would agree with your (1), however, not with the parenthetical > part. I would suggest that be "But MAY still be applicable in other > environments... " My concern is that at this point in time, you can't s= ay > that the changes ARE applicable to other environments .... [/MB]**** > > **** > > > Thanks, > Paul > > **** > > Keith > > ------------------------------------------------------------------------ > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Bernard Aboba > *Sent:* 07 August 2013 00:50 > *To:* Christer Holmberg; mmusic > *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"**** > > > > Christer said: > > "While cleaning up my MMUSIC notes today, I was listening to the audio > recording, in order to get a clarification regarding what "scope is > WEBRTC" really means. However, unless I missed something, I didn't get > a clear answer. > > Does it only cover the browser API (JSEP) or does it also cover > something that can be sent out on the wire (as long as it is not SIP) by > a browser? > > Feel free to tell me that it is a stupid question, and that the answer > is very clear :)" > > [BA] I actually think it is a good question :) > > One interpretation of "scope is WebRTC" is that the SDP in "Unified > Plan" applies to use within the JSEP API. As a result, one > might expect the SDP used in createOffer, setLocalDescription and > setRemoteDescription to resemble that in the "Unified Plan" document. > Since signaling is out of scope for WebRTC, applications that use the > JSEP API might or might not use the "Unified Plan" SDP in signaling on > the wire. > > However, "Unified Plan" includes normative references to published SDP > specifications that were developed for general use, and the adoption of > "Unified Plan" (or even an applicability statement within the "Unified > Plan" document) doesn't change the applicability of those documents. > > Also, there may be some specifications that are part of the "Unified > Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgroup: > SIMULCAST) > > Ultimately, I am expecting the work involved in "Unified Plan" to span > multiple documents, and to clarify the applicability, those individual > documents will need to explain what they apply to (just WebRTC use or > more general use). > > > **** > > _______________________________________________ > 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**** > > ** ** > --089e011823a2e7f66804e35d25a3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:

Hi,<= /p>

=A0<= /p>

Ok, so wha= t is =94RTCWEB usage=94 then? :)

=A0=

For exampl= e, if I implement a JavaScript SIP app, and want to use the UP with SIP on = the wire, would that be a =93RTCWEB usage=94? My understanding is that it would NOT be.

=A0=

My persona= l understanding of the scope is:

[M= B] That is also my understanding. [/MB]=A0

<= u>

=A0=

1)=A0=A0=A0=A0=A0 JSEP;= and

2)=A0=A0=A0=A0=A0 Brows= er-to-browser cases where we KNOW there are no intermediaries etc in betwee= n.

=A0=

Regards,

=A0=

Christer

=A0=

L=E4hett=E4j=E4: mmusic-boun= ces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mary Barnes
L=E4hetetty: 7. elokuuta 2013 17:56
Vastaanottaja: Paul Kyzivat
Kopio: mmusic@i= etf.org
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"=

=A0

On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:

On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:

As one of those that used the term, my intention was= that the initial
decision was to agree to define what RTCWEB needed.

As each dependent working group looks at the extensions they need to do, then they need to make the decision as to whether a wider scope of
possible, desirable, or dangerous.

So the BUNDLE status at the moment is that any changes for the unified
plan should work for RTCWEB usage, but not for general. It would
probably make sense to make it more generally applicable, but that is
the next step in the decision process, and may need some other technical decisions before it happens.

=A0

I don't know how you intend the above to be pars= ed. Specifically, when you say:


=A0 "any changes for the unified plan should work for RTCWEB usage&quo= t;

Do you mean:

1) that the changes should be designed solely with RTCWEB usage in mind? (B= ut are still applicable in other environments that find them useful and cho= ose to adopt them.)

Or do you mean:

2) that those changes should not be used in any environment other than RTCW= EB?

I might be able to accept (1), but not (2).

[MB] I would agree with your (1), however, not with = the parenthetical part. =A0I would suggest that be "But MAY still be a= pplicable in other environments... " =A0 My concern is that at this po= int in time, you can't say that the changes ARE applicable to other environments .... =A0[/MB]

=A0


=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Keith

------------------------------------------------------------------------
*From:*mmusic-= bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On
Behalf Of *Bernard Aboba
*Sent:* 07 August 2013 00:50
*To:* Christer Holmberg; mmusic
*Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"



Christer said:

"While cleaning up my MMUSIC notes today, I was listening to the audio=
recording, in order to get a clarification regarding what "scope is WEBRTC" really means. =A0However, unless I missed something, I didn= 9;t get
a clear answer.

Does it only cover the browser API (JSEP) or does it also cover
something that can be sent out on the wire (as long as it is not SIP) by a browser?

Feel free to tell me that it is a stupid question, and that the answer
is very clear :)"

[BA] =A0I actually think it is a good question :)

One interpretation of "scope is WebRTC" =A0is that the =A0SDP in = "Unified
Plan" applies to use within =A0the JSEP API. =A0 =A0As a result, one might expect the SDP used in createOffer, setLocalDescription and
setRemoteDescription to resemble that in the "Unified Plan" docum= ent.
Since signaling is out of scope for WebRTC, applications that use the
JSEP API might or might not use the "Unified Plan" SDP in signali= ng on
the wire.

However, "Unified Plan" includes normative references to publishe= d SDP
specifications that were developed for general use, and the adoption of
"Unified Plan" (or even an applicability statement within the &qu= ot;Unified
Plan" document) doesn't change the applicability of those document= s.

Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgro= up:
SIMULCAST)

Ultimately, I am expecting the work involved in "Unified Plan" to= span
multiple documents, and to clarify the applicability, =A0those individual documents will need to explain what they apply to (just WebRTC use or
more general use).


_____________________= __________________________
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

=A0


--089e011823a2e7f66804e35d25a3-- From christer.holmberg@ericsson.com Wed Aug 7 08:27:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F51921E8142 for ; Wed, 7 Aug 2013 08:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmvYprlBWGN7 for ; Wed, 7 Aug 2013 08:27:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79F1821E813B for ; Wed, 7 Aug 2013 08:27:38 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-bb-52026768dbb8 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BD.0C.00725.86762025; Wed, 7 Aug 2013 17:27:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 17:27:36 +0200 From: Christer Holmberg To: Mary Barnes Thread-Topic: [MMUSIC] UP: Meaning of "scope is WEBRTC" Thread-Index: Ac6R/R3kheGg3J0cRN604x+uNsUCKAA8dQUAAB20PCD///pbgIAAFRGA///YZWCAAC/CAP//3j7Q Date: Wed, 7 Aug 2013 15:27:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C42157D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C42157DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+JvrW5GOlOQQftKXYvP+/czW0xd/pjF YsWGA6wOzB5/339g8tg56y67x5IlP5kCmKO4bFJSczLLUov07RK4MlYdES04uoGxoudFP2MD 47zZjF2MnBwSAiYSB2b/gLLFJC7cW8/WxcjFISRwmFHi8fsvUM5iRolt7+6wdzFycLAJWEh0 /9MGaRAR0JH49vktG4jNLOAr8XLBF2YQW1jATGLOxzYWiBpziYavD5gh7CiJnlU/weIsAioS m+d+AFvMC9T778ceFqjFzBI/Xk4AK+IUCJQ4828eWDMj0HXfT61hglgmLvHh4HVmiKsFJJbs OQ9li0q8fPyPFcJWkvix4RILRH2+ROehk2wQywQlTs58wjKBUXQWklGzkJTNQlIGEdeTuDF1 ChuErS2xbOFrqHpdiRn/DrEgiy9gZF/FyJ6bmJmTXm64iREYawe3/NbdwXjqnMghRmkOFiVx 3k16ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MIY7Jf0zlwuNrGpu9+xfeSD3W4Bbplzi /cQlVvxNmgc3PuD7XnigIO/R7If7EvnUCl7VrD9brzNjMfcFjhffH6osTw7emjflcSR/ks7+ R+5pMQsWlCYc3ny36piW4uXDjw69SXIxahHYf66TWa5e77Rx5rclRx2nX9ix4tNlle1npSt0 P6oktCqxFGckGmoxFxUnAgA+FjtrgwIAAA== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:27:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C42157DESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If everyone has the same understanding, I would ask the chairs to make it v= ery clear in the final minutes ;) Regards, Christer L=E4hett=E4j=E4: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] L=E4hetetty: 7. elokuuta 2013 18:25 Vastaanottaja: Christer Holmberg Kopio: Paul Kyzivat; mmusic@ietf.org Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg > wrote: Hi, Ok, so what is "RTCWEB usage" then? :) For example, if I implement a JavaScript SIP app, and want to use the UP wi= th SIP on the wire, would that be a "RTCWEB usage"? My understanding is tha= t it would NOT be. My personal understanding of the scope is: [MB] That is also my understanding. [/MB] 1) JSEP; and 2) Browser-to-browser cases where we KNOW there are no intermediaries = etc in between. Regards, Christer L=E4hett=E4j=E4: mmusic-bounces@ietf.org [m= ailto:mmusic-bounces@ietf.org] Puolesta Mar= y Barnes L=E4hetetty: 7. elokuuta 2013 17:56 Vastaanottaja: Paul Kyzivat Kopio: mmusic@ietf.org Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat > wrote: On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote: As one of those that used the term, my intention was that the initial decision was to agree to define what RTCWEB needed. As each dependent working group looks at the extensions they need to do, then they need to make the decision as to whether a wider scope of possible, desirable, or dangerous. So the BUNDLE status at the moment is that any changes for the unified plan should work for RTCWEB usage, but not for general. It would probably make sense to make it more generally applicable, but that is the next step in the decision process, and may need some other technical decisions before it happens. I don't know how you intend the above to be parsed. Specifically, when you = say: "any changes for the unified plan should work for RTCWEB usage" Do you mean: 1) that the changes should be designed solely with RTCWEB usage in mind? (B= ut are still applicable in other environments that find them useful and cho= ose to adopt them.) Or do you mean: 2) that those changes should not be used in any environment other than RTCW= EB? I might be able to accept (1), but not (2). [MB] I would agree with your (1), however, not with the parenthetical part.= I would suggest that be "But MAY still be applicable in other environment= s... " My concern is that at this point in time, you can't say that the c= hanges ARE applicable to other environments .... [/MB] Thanks, Paul Keith ------------------------------------------------------------------------ *From:*mmusic-bounces@ietf.org [mailto:mmus= ic-bounces@ietf.org] *On Behalf Of *Bernard Aboba *Sent:* 07 August 2013 00:50 *To:* Christer Holmberg; mmusic *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" Christer said: "While cleaning up my MMUSIC notes today, I was listening to the audio recording, in order to get a clarification regarding what "scope is WEBRTC" really means. However, unless I missed something, I didn't get a clear answer. Does it only cover the browser API (JSEP) or does it also cover something that can be sent out on the wire (as long as it is not SIP) by a browser? Feel free to tell me that it is a stupid question, and that the answer is very clear :)" [BA] I actually think it is a good question :) One interpretation of "scope is WebRTC" is that the SDP in "Unified Plan" applies to use within the JSEP API. As a result, one might expect the SDP used in createOffer, setLocalDescription and setRemoteDescription to resemble that in the "Unified Plan" document. Since signaling is out of scope for WebRTC, applications that use the JSEP API might or might not use the "Unified Plan" SDP in signaling on the wire. However, "Unified Plan" includes normative references to published SDP specifications that were developed for general use, and the adoption of "Unified Plan" (or even an applicability statement within the "Unified Plan" document) doesn't change the applicability of those documents. Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgroup: SIMULCAST) Ultimately, I am expecting the work involved in "Unified Plan" to span multiple documents, and to clarify the applicability, those individual documents will need to explain what they apply to (just WebRTC use or more general use). _______________________________________________ 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 --_000_7594FB04B1934943A5C02806D1A2204B1C42157DESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If everyon= e has the same understanding, I would ask the chairs to make it very clear in the final minutes ;)

 = ;

Regards,

 = ;

Christer

 = ;

 = ;

 = ;

L=E4hett=E4j=E4: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
L=E4hetetty: 7. elokuuta 2013 18:25
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic@ietf.org
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

 

 

 

On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

Ok, so what is ”RT= CWEB usage” then? :)

 =

For example, if I implem= ent a JavaScript SIP app, and want to use the UP with SIP on the wire, would that be a “RTCWEB usage”? My understanding is = that it would NOT be.

 =

My personal understandin= g of the scope is:

[MB] That is also my understanding. [/MB] =

 =

1)      JSEP; and

2)      Browser-to-browser cases w= here we KNOW there are no intermediaries etc in between.<= /p>

 =

Regards,

 =

Christer

 =

L=E4hett=E4j=E4: mmusic-bounces= @ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mary Barnes
L=E4hetetty: 7. elokuuta 2013 17:56
Vastaanottaja: Paul Kyzivat
Kopio: mmusic@i= etf.org
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"=

 

On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wro= te:

On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:

As one of those that used the term, my intention was that the init= ial
decision was to agree to define what RTCWEB needed.

As each dependent working group looks at the extensions they need to do, then they need to make the decision as to whether a wider scope of
possible, desirable, or dangerous.

So the BUNDLE status at the moment is that any changes for the unified
plan should work for RTCWEB usage, but not for general. It would
probably make sense to make it more generally applicable, but that is
the next step in the decision process, and may need some other technical decisions before it happens.

 

I don't know how you intend the above to be parsed. Specifically, = when you say:


  "any changes for the unified plan should work for RTCWEB usage&= quot;

Do you mean:

1) that the changes should be designed solely with RTCWEB usage in mind? (B= ut are still applicable in other environments that find them useful and cho= ose to adopt them.)

Or do you mean:

2) that those changes should not be used in any environment other than RTCW= EB?

I might be able to accept (1), but not (2).

[MB] I would agree with your (1), however, not with the parentheti= cal part.  I would suggest that be "But MAY still be applicable i= n other environments... "   My concern is that at this point in time, you can't say that the changes ARE applicable to ot= her environments ....  [/MB]

 


        Thanks,
        Paul

Keith

------------------------------------------------------------------------
*From:*mmusic-= bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On
Behalf Of *Bernard Aboba
*Sent:* 07 August 2013 00:50
*To:* Christer Holmberg; mmusic
*Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"



Christer said:

"While cleaning up my MMUSIC notes today, I was listening to the audio=
recording, in order to get a clarification regarding what "scope is WEBRTC" really means.  However, unless I missed something, I didn= 't get
a clear answer.

Does it only cover the browser API (JSEP) or does it also cover
something that can be sent out on the wire (as long as it is not SIP) by a browser?

Feel free to tell me that it is a stupid question, and that the answer
is very clear :)"

[BA]  I actually think it is a good question :)

One interpretation of "scope is WebRTC"  is that the  S= DP in "Unified
Plan" applies to use within  the JSEP API.    As a resu= lt, one
might expect the SDP used in createOffer, setLocalDescription and
setRemoteDescription to resemble that in the "Unified Plan" docum= ent.
Since signaling is out of scope for WebRTC, applications that use the
JSEP API might or might not use the "Unified Plan" SDP in signali= ng on
the wire.

However, "Unified Plan" includes normative references to publishe= d SDP
specifications that were developed for general use, and the adoption of
"Unified Plan" (or even an applicability statement within the &qu= ot;Unified
Plan" document) doesn't change the applicability of those documents.
Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgro= up:
SIMULCAST)

Ultimately, I am expecting the work involved in "Unified Plan" to= span
multiple documents, and to clarify the applicability,  those individua= l
documents will need to explain what they apply to (just WebRTC use or
more general use).

_______________________________________________
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

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C42157DESESSMB209erics_-- From keith.drage@alcatel-lucent.com Wed Aug 7 10:26:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E3221F9EF5 for ; Wed, 7 Aug 2013 10:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.626 X-Spam-Level: X-Spam-Status: No, score=-110.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG6LgPBR3R88 for ; Wed, 7 Aug 2013 10:26:37 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id ECC8821F9E34 for ; Wed, 7 Aug 2013 10:26:21 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r77HQG72022006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2013 12:26:18 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r77HQF6t022301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 19:26:16 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 7 Aug 2013 19:26:15 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] UP: Meaning of "scope is WEBRTC" Thread-Index: Ac6R/R3kheGg3J0cRN604x+uNsUCKAA8dQUAAB20PCD///pbgP//rs1Q Date: Wed, 7 Aug 2013 17:26:15 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07DDFC@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> In-Reply-To: <52024E57.9070602@alum.mit.edu> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:26:46 -0000 I said that all the involved groups need to make a second step with all the= ir deliverables, which is to decide whether what they are doing is used gen= erally, or solely in the context of WEBRTC. Deciding whether it is 1) or 2) has not been defined in my understanding, a= nd would really come under the scope of the second decision. I for one am hoping as much of this as possible comes out as being generall= y applicable, and obviously designed as such as a result, but the MMUSIC WG= did not appear to be ready to say that last week. So some steps to get the= re. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat=20 > Sent: 07 August 2013 14:41 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" >=20 > On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote: > > As one of those that used the term, my intention was that the initial > > decision was to agree to define what RTCWEB needed. > > > > As each dependent working group looks at the extensions they need to do= , > > then they need to make the decision as to whether a wider scope of > > possible, desirable, or dangerous. > > > > So the BUNDLE status at the moment is that any changes for the unified > > plan should work for RTCWEB usage, but not for general. It would > > probably make sense to make it more generally applicable, but that is > > the next step in the decision process, and may need some other technica= l > > decisions before it happens. >=20 > I don't know how you intend the above to be parsed. Specifically, when > you say: > "any changes for the unified plan should work for RTCWEB usage" >=20 > Do you mean: >=20 > 1) that the changes should be designed solely with RTCWEB usage in mind? > (But are still applicable in other environments that find them useful > and choose to adopt them.) >=20 > Or do you mean: >=20 > 2) that those changes should not be used in any environment other than > RTCWEB? >=20 > I might be able to accept (1), but not (2). >=20 > Thanks, > Paul >=20 >=20 > > Keith > > > > -----------------------------------------------------------------------= - > > > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > > Behalf Of *Bernard Aboba > > *Sent:* 07 August 2013 00:50 > > *To:* Christer Holmberg; mmusic > > *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > > > > Christer said: > > > > "While cleaning up my MMUSIC notes today, I was listening to the audio > > recording, in order to get a clarification regarding what "scope is > > WEBRTC" really means. However, unless I missed something, I didn't get > > a clear answer. > > > > Does it only cover the browser API (JSEP) or does it also cover > > something that can be sent out on the wire (as long as it is not SIP) b= y > > a browser? > > > > Feel free to tell me that it is a stupid question, and that the answer > > is very clear :)" > > > > [BA] I actually think it is a good question :) > > > > One interpretation of "scope is WebRTC" is that the SDP in "Unified > > Plan" applies to use within the JSEP API. As a result, one > > might expect the SDP used in createOffer, setLocalDescription and > > setRemoteDescription to resemble that in the "Unified Plan" document. > > Since signaling is out of scope for WebRTC, applications that use the > > JSEP API might or might not use the "Unified Plan" SDP in signaling on > > the wire. > > > > However, "Unified Plan" includes normative references to published SDP > > specifications that were developed for general use, and the adoption of > > "Unified Plan" (or even an applicability statement within the "Unified > > Plan" document) doesn't change the applicability of those documents. > > > > Also, there may be some specifications that are part of the "Unified > > Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgrou= p: > > SIMULCAST) > > > > Ultimately, I am expecting the work involved in "Unified Plan" to span > > multiple documents, and to clarify the applicability, those individual > > documents will need to explain what they apply to (just WebRTC use or > > more general use). > > > > > > > > _______________________________________________ > > 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 hadriel.kaplan@oracle.com Wed Aug 7 10:26:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BD621F9ADC for ; Wed, 7 Aug 2013 10:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEPuzBweBYcE for ; Wed, 7 Aug 2013 10:26:39 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 69AE121F9C33 for ; Wed, 7 Aug 2013 10:26:21 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r77HQBGi016944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 17:26:12 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77HQAgK029448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 17:26:11 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77HQAVx011234; Wed, 7 Aug 2013 17:26:10 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Aug 2013 10:26:10 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> Date: Wed, 7 Aug 2013 13:26:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88A95F79-C0D2-4B0A-B762-99E3BE662DD0@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:26:46 -0000 On Aug 7, 2013, at 11:21 AM, Christer Holmberg = wrote: > Ok, so what is =94RTCWEB usage=94 then? :) > For example, if I implement a JavaScript SIP app, and want to use the = UP with SIP on the wire, would that be a =93RTCWEB usage=94? My = understanding is that it would NOT be. No it wouldn't be, imo, but perhaps in a different way than you mean it. = If you implement "SIP", by definition you follow the SIP RFCs. If you = don't follow SIP RFCs, you're not really implementing SIP. It's no = different than if you wrote it in C++ or Java or whatever, as a native = application. The fact that you're running inside a browser and using = javascript as a language doesn't change the SIP protocol or what it = needs to do/not-do to interoperate with other SIP devices. =20 If you don't want to interoperate with other SIP devices and the = deployed SIP domains, then do whatever you like and add whatever = extensions you wish. There's no protocol police, nor need for one, when = two hosts want to do whatever they want to do with each other. So long = as they are running the same code (e.g., javascript), or privately agree = on how things work between each other, things work in an interoperable = fashion. I think people want to think of WebRTC as SIPv3, but it isn't - there's = no actual signaling protocol defined, nor does it make sense to define = one. Even the JSEP draft makes the point that the application can do = whatever it likes on-the-wire. (right?) The fact that WebRTC uses SDP = for the "API" is an (unfortunate) coincidence - I don't mean it was done = by accident, since clearly it wasn't - but I mean its usage in a WebRTC = context is not defined as the on-the-wire encoding for host-to-host = media session exchange/negotiation protocol. We might use it that way = in our javascript app, and draw it that way in powerpoint, but it's not = one. It's silly to constrain WebRTC applications to semantics/behaviors = SIP or RTSP or MGCP support, even when using SDP for the Javascript API. = If JSEP, for example, wants to go do all kinds of new things for = itself, it should be able to - without impacting anything else. > My personal understanding of the scope is: > =20 > 1) JSEP; and > 2) Browser-to-browser cases where we KNOW there are no = intermediaries etc in between. My understanding of the "scope" is that it's applicable to the actual = Javascript API as well as (1) JSEP. Saying (2) is a bit weird, both = because it can be between a browser and a native application or server = or gateway or whatever, but also because there are in fact = intermediaries (HTTP Proxies, for example). -hadriel From hadriel.kaplan@oracle.com Wed Aug 7 10:29:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E921F8E8E for ; Wed, 7 Aug 2013 10:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhqBYkyaAa74 for ; Wed, 7 Aug 2013 10:29:39 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D81F21F9DA3 for ; Wed, 7 Aug 2013 10:29:39 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r77HTVJA020174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 17:29:32 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77HTU8v013784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 17:29:31 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77HTUSj006809; Wed, 7 Aug 2013 17:29:30 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Aug 2013 10:29:30 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Wed, 7 Aug 2013 13:29:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50E23526-DB28-4F1E-9E0F-27B00777C08F@oracle.com> References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <52001847.3090805@alum.mit.edu> <45E41954-372E-4483-B526-1C92EF0656C8@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41E15C@ESESSMB209.ericsson.se> To: Martin Thomson X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:29:53 -0000 On Aug 7, 2013, at 1:44 AM, Martin Thomson = wrote: > On 6 August 2013 00:55, Christer Holmberg > wrote: >> If you use separate m- lines per media direction, there MAY be a = smaller risk that both endpoints try to modify the same m- line. Maybe = that is what he was talking about :) >=20 > That's actually all I was suggesting. But the wild speculation that > ensued was quite interesting nonetheless. >=20 > I believe that most of what has been said on this thread is also true. > Yes, you can probably reduce glare further by defining some specific > rules (reject beats any other change, etc...). Yes, you can devise > rules for other stuff. Yes, it's probably not worth it for a lot of > those things anyway. Yes, changing parameters that affect multiple > m-lines, like transport parameters, is probably going to cause > unavoidable wide-scale glare. Etc.. Huh. Well my idea was much better... sure, it may not provide any = value, benefit, or fix any problem... but it's a way cooler idea. ;) -hadriel From hadriel.kaplan@oracle.com Wed Aug 7 10:52:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3FF11E80E0 for ; Wed, 7 Aug 2013 10:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9w7S9dD6wPr for ; Wed, 7 Aug 2013 10:52:47 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 709FA11E8160 for ; Wed, 7 Aug 2013 10:52:45 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r77HqhJL013697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 17:52:44 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77HqgOm006853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 17:52:43 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77HqgMQ009580; Wed, 7 Aug 2013 17:52:42 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Aug 2013 10:52:42 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <52011AF8.10003@alum.mit.edu> Date: Wed, 7 Aug 2013 13:52:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <52011AF8.10003@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:52:55 -0000 On Aug 6, 2013, at 11:49 AM, Paul Kyzivat wrote: > I don't really understand the "only for WebRTC" agreement. > I do see how defining extensions to O/A might be done only for WebRTC = and not for 3264. (I don't *agree*, but I do *understand* that.) >=20 > But BUNDLE is a change to SDP, and SDP extensions are required to = specify how they interact with O/A. Is that actually true? I don't see that requirement in RFC 4566 IANA = registration procedures, nor in IANA's SDP parameters registry. > I don't think it makes any sense to say that such changes only apply = to WebRTC. They should apply to anything that chooses to claim support = to the BUNDLE draft. OK, but in a SIP-based usage, I think it's dangerous to offer port=3D0 = media lines and negotiate to use those media lines with the far end due = to an answer containing a new bundle attribute, without sending another = offer indicating you're using those media lines. So I think if we want to use BUNDLE in SIP as well, we should really = require it to do another offer/answer round. In a WebRTC usage (ie, in = Javascript API and JSEP), it can avoid the second round. One way to describe this in a BUNDLE RFC, I think, is to say it MUST do = another offer/answer exchange, except when used in [draft-jsep] or as an = application programming interface. (or something like that) -hadriel From adam@nostrum.com Wed Aug 7 10:55:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8060C21F86BE for ; Wed, 7 Aug 2013 10:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZU9oPPUNoif for ; Wed, 7 Aug 2013 10:55:44 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDB821F81FF for ; Wed, 7 Aug 2013 10:55:41 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r77HtWrL020948 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 12:55:33 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <52028A0F.6080005@nostrum.com> Date: Wed, 07 Aug 2013 12:55:27 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <52001847.3090805@alum.mit.edu> <45E41954-372E-4483-B526-1C92EF0656C8@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41E15C@ESESSMB209.ericsson.se> <50E23526-DB28-4F1E-9E0F-27B00777C08F@oracle.com> In-Reply-To: <50E23526-DB28-4F1E-9E0F-27B00777C08F@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:55:50 -0000 On 8/7/13 12:29, Hadriel Kaplan wrote: > Huh. Well my idea was much better... sure, it may not provide any value, benefit, or fix any problem... but it's a way cooler idea. ;) > Yeah, maybe -- but I think we want to keep this relatively simple. More directly: we need to be careful to evaluate what incremental gains added complexity gets us over a simpler mechanism. I think the scheme you outlined is out in the "diminishing returns" part of the solution space. /a From mary.ietf.barnes@gmail.com Wed Aug 7 11:03:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448E611E814D for ; Wed, 7 Aug 2013 11:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3oMlOyocWK1 for ; Wed, 7 Aug 2013 11:03:04 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8411F0D55 for ; Wed, 7 Aug 2013 11:02:06 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id c1so1070890qcz.33 for ; Wed, 07 Aug 2013 11:02:00 -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=B4gUpkIfm5ZHQwJzubPiFjBd2YFNytSVwVcDSZH/kV0=; b=a/jiIo75vxX+cSS5gI3LVlfQk6kmU2CofbjtX9gBaqDnQq4oA9TA0Kci7TFs9Z0Dot P9NbZlZZ0mAAYo+sASJslg1oo0VbfqDW8lgcVYPIx9/iEny8p1LhlGL9nh8aeCmNnqt/ 17zuNmauc0kDrD4LtaTvVhtujp4ZTnX4inOAsH2Zc+f1zbTTazNoGAZTbqPYpduGk6q1 OHcFBW2im6isvrQ41PlWqmvX6mekI1RCgwA9wezHG2Jsu8Uel7ZWlIBIDj+UC86fKG/G KeukqXF5qc2iQlkiIrlqx+mHN18LIPae6pR5lpafRMzc4D7I1uOHba/byI4+KzmXDgjC TWsg== MIME-Version: 1.0 X-Received: by 10.49.28.9 with SMTP id x9mr2076019qeg.8.1375898520367; Wed, 07 Aug 2013 11:02:00 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Wed, 7 Aug 2013 11:02:00 -0700 (PDT) In-Reply-To: <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <52011AF8.10003@alum.mit.edu> <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> Date: Wed, 7 Aug 2013 13:02:00 -0500 Message-ID: From: Mary Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7bdc07748e846904e35f5680 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:03:05 -0000 --047d7bdc07748e846904e35f5680 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 7, 2013 at 12:52 PM, Hadriel Kaplan wrote: > > On Aug 6, 2013, at 11:49 AM, Paul Kyzivat wrote: > > > I don't really understand the "only for WebRTC" agreement. > > I do see how defining extensions to O/A might be done only for WebRTC > and not for 3264. (I don't *agree*, but I do *understand* that.) > > > > But BUNDLE is a change to SDP, and SDP extensions are required to > specify how they interact with O/A. > > Is that actually true? I don't see that requirement in RFC 4566 IANA > registration procedures, nor in IANA's SDP parameters registry. > > > > I don't think it makes any sense to say that such changes only apply to > WebRTC. They should apply to anything that chooses to claim support to the > BUNDLE draft. > > OK, but in a SIP-based usage, I think it's dangerous to offer port=0 media > lines and negotiate to use those media lines with the far end due to an > answer containing a new bundle attribute, without sending another offer > indicating you're using those media lines. > > So I think if we want to use BUNDLE in SIP as well, we should really > require it to do another offer/answer round. In a WebRTC usage (ie, in > Javascript API and JSEP), it can avoid the second round. > > One way to describe this in a BUNDLE RFC, I think, is to say it MUST do > another offer/answer exchange, except when used in [draft-jsep] or as an > application programming interface. (or something like that) > [MB] Exactly. I think it's extremely important that the different usages of BUNDLE/SDP are clearly delineated. I think that's one of the reasons we have gotten so bogged down with this whole topic. There's no one to have a one size fits all solution give the disparity in the usages. [/MB] > > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7bdc07748e846904e35f5680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 7, 2013 at 12:52 PM, Hadriel Kaplan &= lt;hadriel.k= aplan@oracle.com> wrote:

On Aug 6, 2013, at 11:49 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> I don't really understand the "only for WebRTC" agreemen= t.
> I do see how defining extensions to O/A might be done only for WebRTC = and not for 3264. (I don't *agree*, but I do *understand* that.)
>
> But BUNDLE is a change to SDP, and SDP extensions are required to spec= ify how they interact with O/A.

Is that actually true? =A0I don't see that requirement in RFC 456= 6 IANA registration procedures, nor in IANA's SDP parameters registry.<= br>


> I don't think it makes any sense to say that such changes only app= ly to WebRTC. They should apply to anything that chooses to claim support t= o the BUNDLE draft.

OK, but in a SIP-based usage, I think it's dangerous to offer por= t=3D0 media lines and negotiate to use those media lines with the far end d= ue to an answer containing a new bundle attribute, without sending another = offer indicating you're using those media lines.

So I think if we want to use BUNDLE in SIP as well, we should really requir= e it to do another offer/answer round. =A0In a WebRTC usage (ie, in Javascr= ipt API and JSEP), it can avoid the second round.

One way to describe this in a BUNDLE RFC, I think, is to say it MUST do ano= ther offer/answer exchange, except when used in [draft-jsep] or as an appli= cation programming interface. (or something like that)
[MB] Exactly. =A0I think it's extremely important that the differe= nt usages of BUNDLE/SDP are clearly delineated. =A0I think that's one o= f the reasons we have gotten so bogged down with this whole topic. =A0There= 's no one to have a one size fits all solution give the disparity in th= e usages. [/MB]=A0

-hadriel

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

--047d7bdc07748e846904e35f5680-- From christer.holmberg@ericsson.com Wed Aug 7 11:05:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945DF21F9DDC for ; Wed, 7 Aug 2013 11:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhmwJaUSwWxx for ; Wed, 7 Aug 2013 11:05:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 58F0411E812E for ; Wed, 7 Aug 2013 11:05:24 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-a9-52028c623c3a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 36.1E.05990.26C82025; Wed, 7 Aug 2013 20:05:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 20:05:22 +0200 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Thread-Topic: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) Thread-Index: AQHOk5b141y6RZA7WkyIH1wZ4evbEZmKCV2Q Date: Wed, 7 Aug 2013 18:05:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4216BD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <52011AF8.10003@alum.mit.edu> <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> In-Reply-To: <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvrW5SD1OQwcdFqhafNn1itpi6/DGL xYoNB1gdmD3+vv/A5LFkyU8mj49Pb7EEMEdx2aSk5mSWpRbp2yVwZXw7+Ju14DNXxe2ZJ9ka GE9xdDFyckgImEisWPqPHcIWk7hwbz0biC0kcJhRYtlfoy5GLiB7MaPE+ne7GLsYOTjYBCwk uv9pg9SICIRJ/Ju0jBUkzCygLnF1cRBIWFigQGLavAdsIGERgUKJFaclIaqNJNZObGUGsVkE VCQWrl0BtpVXwFdi1s6V7BCbVjFJfJrYzgSS4BSwk+hZt54FxGYEOu37qTVgcWYBcYkPB68z Q5wsILFkz3koW1Ti5eN/rBC2ksSPDZdYIOp1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis1C MnYWkpZZSFpmIWlZwMiyipE9NzEzJ73caBMjMGYObvmtuoPxzjmRQ4zSHCxK4ryb9c4ECgmk J5akZqemFqQWxReV5qQWH2Jk4uCUamB0r9Z4m+W7yGN9PUP6NasHtceavHaGe1z+JBRw0GFr rMbMpZPUfzCsWzDlp/i6g2sO/vQLnHNkbrqi94Fzl660zreT9GFxEvPMfLExzePwu2yTXds2 uwW3ei/uO6rTvj76y+oJj0pYGPrfNu0Rdpl0+72J9sokrZ2syT46T3R+igtJPXS6tX+XEktx RqKhFnNRcSIAZpDMRmcCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:05:33 -0000 Hi, >> I don't think it makes any sense to say that such changes only apply to = WebRTC. They should apply to anything that chooses to claim support to the = BUNDLE draft. > > OK, but in a SIP-based usage, I think it's dangerous to offer port=3D0 me= dia lines and negotiate to use those media lines with the far end due to an= answer containing a new bundle attribute, without sending another offer in= dicating you're using those media lines. You have to send an offer which indicates the port you are going to use. So= metimes that will be a "second offer" (because the "first offer" contained = different ports). > So I think if we want to use BUNDLE in SIP as well, we should really requ= ire it to do another offer/answer round. In a WebRTC usage (ie, in Javascr= ipt API and JSEP), it can avoid the second round. BUNDLE as such *CAN* be used with SIP. The question is whether specific par= ts, e.g. the SDP bundle-only attribute, needs to be scoped to "WebRTC only"= . > One way to describe this in a BUNDLE RFC, I think, is to say it MUST do a= nother offer/answer exchange, except when used in [draft-jsep] or as an app= lication programming interface. (or something like that) The draft already says that a second offer/answer must be sent, if the prev= ious one did not contain the port values that are going to be used. Regards, Christer From hadriel.kaplan@oracle.com Wed Aug 7 11:17:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586DF21F9C87 for ; Wed, 7 Aug 2013 11:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQUlzp-uyt3e for ; Wed, 7 Aug 2013 11:17:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 610C921F8C65 for ; Wed, 7 Aug 2013 11:17:11 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r77IH6pm005027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 18:17:07 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77IH658011188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 18:17:06 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77IH5Cd001431; Wed, 7 Aug 2013 18:17:05 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Aug 2013 11:17:05 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4216BD@ESESSMB209.ericsson.se> Date: Wed, 7 Aug 2013 14:17:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <18CF11C2-B5C7-4895-A58B-308F76B94CED@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <52011AF8.10003@alum.mit.edu> <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C4216BD@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:17:20 -0000 On Aug 7, 2013, at 2:05 PM, Christer Holmberg = wrote: >> One way to describe this in a BUNDLE RFC, I think, is to say it MUST = do another offer/answer exchange, except when used in [draft-jsep] or as = an application programming interface. (or something like that) >=20 > The draft already says that a second offer/answer must be sent, if the = previous one did not contain the port values that are going to be used. This is challenging to discuss because as far as I'm aware, the UP plan = will make changes to the BUDNLE draft. Correct? If so, saying "but it = already says X" doesn't give me the warm-fuzzies. I believe (but could easily be wrong) the new UP plan would not require = a second O/A. Or at least that's what I interpreted Adam's email to = mean here: http://www.ietf.org/mail-archive/web/mmusic/current/msg12030.html If I misunderstood his email, I apologize. -hadriel From christer.holmberg@ericsson.com Wed Aug 7 11:28:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E903721F9A04 for ; Wed, 7 Aug 2013 11:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADmRzRd4d+iC for ; Wed, 7 Aug 2013 11:28:36 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3A55611E815C for ; Wed, 7 Aug 2013 11:28:36 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-80-520291d25701 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FF.E1.19388.2D192025; Wed, 7 Aug 2013 20:28:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 20:28:34 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) Thread-Index: AQHOk5pV25IxPu7w0kivuSY7sVhIJJmKDzEg Date: Wed, 7 Aug 2013 18:28:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4216F0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <52011AF8.10003@alum.mit.edu> <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C4216BD@ESESSMB209.ericsson.se> <18CF11C2-B5C7-4895-A58B-308F76B94CED@oracle.com> In-Reply-To: <18CF11C2-B5C7-4895-A58B-308F76B94CED@oracle.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre7liUxBBr/2clt82vSJ2WLq8scs DkweS5b8ZPL4+PQWSwBTFJdNSmpOZllqkb5dAldG77mt7AWt3BXbFjs2ML7i6GLk4JAQMJH4 s069i5ETyBSTuHBvPRuILSRwmFGi61xIFyMXkL2YUeL+c5AEBwebgIVE9z9tEFNEQE/i6D1O kHJmAQOJ548usYDYwgIFEvO33WYFsUUECiUu3/8NZRtJzPgyD6yGRUBFYtePV2BxXgFfifnN C5ggVi1ilthybBojSIJTwE7i5babYPcwAt32/dQaJohl4hIfDl5nhrhZQGLJnvNQtqjEy8f/ WCFsJYnGJU9YIep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiy ipE9NzEzJ73cfBMjMDoObvltsINx032xQ4zSHCxK4ryb9c4ECgmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamCMsVw+Kfn7pYrQviedm8OebaxyOXhA39U/yHrZCuuXMj6PzpwQ1q2b/1ZuMufZ H/rbDmS+tco8apKfsuD48QWeNgvnFhTLv3/y7MyWF9O9eCz/Zv+sW8frW59+4O3hbG37fIf2 JaZbXaMuZK56HfLkb3X5NjcRl+zfr5jtWpbNzFxuFMFzf9pyJZbijERDLeai4kQAIw+2cVwC AAA= Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:28:42 -0000 Hi, >>> One way to describe this in a BUNDLE RFC, I think, is to say it MUST do= another offer/answer exchange, except when used in [draft-jsep] or as an a= pplication programming interface. (or something like that) >>=20 >> The draft already says that a second offer/answer must be sent, if the p= revious one did not contain the port values that are going to be used. > > This is challenging to discuss because as far as I'm aware, the UP plan w= ill make changes to the BUDNLE draft. Correct? If so, saying "but it alre= ady says X" doesn't give me the warm-fuzzies. > > I believe (but could easily be wrong) the new UP plan would not require a= second O/A. Or at least that's what I interpreted Adam's email to mean he= re: > http://www.ietf.org/mail-archive/web/mmusic/current/msg12030.html > > If I misunderstood his email, I apologize. You probably understood correct. Now, when I re-read it, I remembered that = I didn't agree :) My opinion is that a second offer is always needed if the= previous offer did not contain the port values that you are actually going= to end up using. So, if the first offer contains bundle-only/port=3D0, and the receiver acce= pts it, the second offer would contain bundle-only/port=3Dbundle_port. But, obviously this is something that we'll have to discuss as part of the = adding-UP-to-BUNDLE procedure. Regards, Christer From hadriel.kaplan@oracle.com Wed Aug 7 13:14:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15B821F9D17 for ; Wed, 7 Aug 2013 13:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+5pugb8v-jD for ; Wed, 7 Aug 2013 13:14:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CDDC021F9D65 for ; Wed, 7 Aug 2013 13:14:19 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r77KECTL020037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 20:14:13 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77KEBsq003082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 20:14:12 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77KEBZb017504; Wed, 7 Aug 2013 20:14:11 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Aug 2013 13:14:11 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <52028A0F.6080005@nostrum.com> Date: Wed, 7 Aug 2013 16:14:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E57AB12-F805-499B-AFE4-099E9E0E5723@oracle.com> References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <52001847.3090805@alum.mit.edu> <45E41954-372E-4483-B526-1C92EF0656C8@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41E15C@ESESSMB209.ericsson.se> <50E23526-DB28-4F1E-9E0F-27B00777C08F@oracle.com> <52028A0F.6080005@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:14:41 -0000 On Aug 7, 2013, at 1:55 PM, Adam Roach wrote: > On 8/7/13 12:29, Hadriel Kaplan wrote: >> Huh. Well my idea was much better... sure, it may not provide any = value, benefit, or fix any problem... but it's a way cooler idea. ;) >>=20 >=20 > Yeah, maybe -- but I think we want to keep this relatively simple. = More directly: we need to be careful to evaluate what incremental gains = added complexity gets us over a simpler mechanism. I think the scheme = you outlined is out in the "diminishing returns" part of the solution = space. Dude, it was a joke. Apparently not a funny one, though. :( -hadriel From christer.holmberg@ericsson.com Wed Aug 7 13:38:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A89311E813F for ; Wed, 7 Aug 2013 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwGHPwZx4CDP for ; Wed, 7 Aug 2013 13:38:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD9821E8146 for ; Wed, 7 Aug 2013 13:37:59 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-f5-5202b0253d44 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 87.68.19388.520B2025; Wed, 7 Aug 2013 22:37:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 22:37:57 +0200 From: Christer Holmberg To: Hadriel Kaplan , Adam Roach Thread-Topic: [MMUSIC] unified plan glareless atomicity improvement Thread-Index: AQHOjefTpSIHc3SbG0aBA3v1ZtE4opl+3H0AgAe8nYCAAG4qgIAAFlcAgAAj7NCAAeNlgIAAxRMAgAAHQoCAACbBgIAAKALw Date: Wed, 7 Aug 2013 20:37:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C42191E@ESESSMB209.ericsson.se> References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <52001847.3090805@alum.mit.edu> <45E41954-372E-4483-B526-1C92EF0656C8@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41E15C@ESESSMB209.ericsson.se> <50E23526-DB28-4F1E-9E0F-27B00777C08F@oracle.com> <52028A0F.6080005@nostrum.com> <1E57AB12-F805-499B-AFE4-099E9E0E5723@oracle.com> In-Reply-To: <1E57AB12-F805-499B-AFE4-099E9E0E5723@oracle.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra7aBqYgg+WT2Cz2/F3EbvFp0ydm i6nLH7M4MHssWfKTyWPWzicsHh+f3mIJYI7isklJzcksSy3St0vgyvh+dytzwVfOiubZt1kb GCdwdDFyckgImEi03DrCDGGLSVy4t56ti5GLQ0jgMKPEkst7oZzFjBIrXy9k7GLk4GATsJDo /qcN0iAi4Ctx9vB9RhCbWcBA4vmjSywgtrCAk8SrG/vYQMpFBJwl5rx2hSjPk+hddZQVJMwi oCLx9bkWSJgXaMrRZSuZIDb1sUjcfjSTCSTBKWAnsfnUV7DxjEC3fT+1hglilbjEh4PXoW4W kFiy5zyULSrx8vE/VghbSaJxyRNWiHo9iRtTp7BB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2F pGUWkpZZSFoWMLKsYmTPTczMSS8338QIjJqDW34b7GDcdF/sEKM0B4uSOO9mvTOBQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhhP3p09e8aKsCslbs7zO5SerXC6Uff1zQuu68vObb895cqj gN5HWwJzjW6+a9Kc9fbegt/VW3aurmMS39a6QTPN7HzGyl9+5QfWc09rfOFwaoH/Ak2f+R+5 d9fM8q2UVLr4zuqV8sKOFy5CkXttw+OP236vv7BX8GJQ2fHGvJV/qqsZGlwFOtTblFiKMxIN tZiLihMBogV5uWgCAAA= Cc: "mmusic@ietf.org \(E-mail\)" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:38:30 -0000 Hadriel, your jokes work much better during f2f meetings, because part of t= he joke telling is that you first laugh at your joke yourself, before anyon= e else :) Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Hadriel Kaplan L=E4hetetty: 7. elokuuta 2013 23:14 Vastaanottaja: Adam Roach Kopio: mmusic@ietf.org (E-mail) Aihe: Re: [MMUSIC] unified plan glareless atomicity improvement On Aug 7, 2013, at 1:55 PM, Adam Roach wrote: > On 8/7/13 12:29, Hadriel Kaplan wrote: >> Huh. Well my idea was much better... sure, it may not provide any value= , benefit, or fix any problem... but it's a way cooler idea. ;) >>=20 >=20 > Yeah, maybe -- but I think we want to keep this relatively simple. More d= irectly: we need to be careful to evaluate what incremental gains added com= plexity gets us over a simpler mechanism. I think the scheme you outlined i= s out in the "diminishing returns" part of the solution space. Dude, it was a joke. Apparently not a funny one, though. :( -hadriel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From partha@parthasarathi.co.in Wed Aug 7 14:50:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429E621F997D for ; Wed, 7 Aug 2013 14:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWKgG8o0teUo for ; Wed, 7 Aug 2013 14:50:41 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id 779AB21F9406 for ; Wed, 7 Aug 2013 14:50:37 -0700 (PDT) Received: from userPC (unknown [122.179.37.144]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id B3516638DEA; Wed, 7 Aug 2013 21:50:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1375912234; bh=6wEgoc3LdShY+OXKPEAibzfIwdh1CXuBSjcvqbeRof0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=A6SEciVCmsdH1ixQb6hLsit0/Ko/+JJN69NSORLUHp9bogomUKf5tEZwCgQFVrFcr 7u2M1DOnhzfpkwGKEuJ9J0bRhM9R1PXMKWgW1D0JL7DhQYu3ZYWrhpSGrtiUWaMZje f1ubKOQ6G35SYnRSskRKda74GBt9UnLlXho1WExU= From: "Parthasarathi R" To: "'Hadriel Kaplan'" , "'Christer Holmberg'" References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <52011AF8.10003@alum.mit.edu> <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C4216BD@ESESSMB209.ericsson.se> <18CF11C2-B5C7-4895-A58B-308F76B94CED@oracle.com> In-Reply-To: <18CF11C2-B5C7-4895-A58B-308F76B94CED@oracle.com> Date: Thu, 8 Aug 2013 03:20:23 +0530 Message-ID: <00e901ce93b8$22bbed90$6833c8b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6Tml8Yf7CUMWgjT+a3EcsjFMe/NAAG1pVg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0209.5202C12A.0047, 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: 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 70.87.28.142 Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 21:50:45 -0000 Hi all, It is a concern area for UP plan in case it works only for WebRTC and not for SIP/general. The changing current BUNDLE approach breaks interop with SIP/legacy endpoints. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Wednesday, August 07, 2013 11:47 PM > To: Christer Holmberg > Cc: mmusic@ietf.org (E-mail) > Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero > usage in bundled m- lines (SDP Offers only) > > > On Aug 7, 2013, at 2:05 PM, Christer Holmberg > wrote: > > >> One way to describe this in a BUNDLE RFC, I think, is to say it MUST > do another offer/answer exchange, except when used in [draft-jsep] or > as an application programming interface. (or something like that) > > > > The draft already says that a second offer/answer must be sent, if > the previous one did not contain the port values that are going to be > used. > > This is challenging to discuss because as far as I'm aware, the UP plan > will make changes to the BUDNLE draft. Correct? If so, saying "but it > already says X" doesn't give me the warm-fuzzies. > > I believe (but could easily be wrong) the new UP plan would not require > a second O/A. Or at least that's what I interpreted Adam's email to > mean here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg12030.html > > If I misunderstood his email, I apologize. > > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Wed Aug 7 23:18:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2F721F9D56 for ; Wed, 7 Aug 2013 23:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPxHkglQhLLu for ; Wed, 7 Aug 2013 23:18:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAAD11E80D9 for ; Wed, 7 Aug 2013 23:18:48 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-e1-5203384739c1 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 35.FC.05990.74833025; Thu, 8 Aug 2013 08:18:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 08:18:47 +0200 From: Christer Holmberg To: mmusic Thread-Topic: BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: Ac6T/yOjlGF0THkKQYuF8hS65+1TmA== Date: Thu, 8 Aug 2013 06:18:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C421C80ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvra67BXOQQXubhsXU5Y9ZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWHldsaC80IVB76eZmtg/M/fxcjJISFgIvHszhJmCFtM4sK9 9WxdjFwcQgKHGSWmrZjJCOEsZpR49/w1kMPBwSZgIdH9TxukQURARmLvps1gzcIC7hLdL9ax QMR9JL4smsUKYetJfH67gBWklUVARaKn2RDE5BXwlXh1TwakghFo7fdTa5hAbGYBcYlbT+Yz QZwjILFkz3mo00QlXj7+xwpRky9x4vxeRhCbV0BQ4uTMJywTGAVnIWmfhaRsFpIyiLiexI2p U9ggbG2JZQtfM0PYuhIz/h1iQRZfwMi+ipE9NzEzJ73caBMjMLQPbvmtuoPxzjmRQ4zSHCxK 4ryb9c4ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC0fVJhajGvu0bmZrhfsZP2ncK/rDZr 9z5989s2wFjTR0X5V/DSi2zPfk5gvn2pa/6NJ3OE5r2Ym3juh3Hl+URVhns7pFcaXl83VU6l xeA+pz1jYLm/0k2hnztiHz5wCdj2YibjlYvN2pk7S7gunzq8c3XevBvut59MuNIUKt7umyf8 z2lWdQSzEktxRqKhFnNRcSIAxV6yWjsCAAA= Subject: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 06:18:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C421C80ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As has been indicated, bundle-only can only be used when one knows that the= receiver, and possible intermediaries etc, support it. So, based on that assumption, my question is: why do we need port 0? Why no= t assign the suggested bundle port to the bundle-only m- lines from the beg= inning? As the bundle port is anyway going to be used (even if the receiver= does not want to use bundle), there is no need to reserve additional ports= for bundle-only m- lines. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) --_000_7594FB04B1934943A5C02806D1A2204B1C421C80ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
As has been indicated, bundle-only can only be = used when one knows that the receiver, and possible intermediaries etc, sup= port it.
 
So, based on that assumption, my question is: w= hy do we need port 0? Why not assign the suggested bundle port to the = bundle-only m- lines from the beginning? As the bundle port is anyway going= to be used (even if the receiver does not want to use bundle), there is no need to reserve additional ports for = bundle-only m- lines.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown (www.nitrodesk.com)
--_000_7594FB04B1934943A5C02806D1A2204B1C421C80ESESSMB209erics_-- From hadriel.kaplan@oracle.com Thu Aug 8 05:21:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C47321F9635 for ; Thu, 8 Aug 2013 05:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XUt-onGoZIB for ; Thu, 8 Aug 2013 05:21:22 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5B521F8FAC for ; Thu, 8 Aug 2013 05:21:22 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78CLINO024049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 12:21:19 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78CLGn2007799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 12:21:17 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78CLFPu012753; Thu, 8 Aug 2013 12:21:16 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 05:21:15 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> Date: Thu, 8 Aug 2013 08:21:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 12:21:27 -0000 If I understand your question, you're asking why bundle-only m-lines = would use a port number of 0 in the offer, instead of using the same = port number as the regular bundle m-line they're going to = transport-bundle with? I believe the rationale was basically argued about before, either in = IETF 86 Orlando or IETF 85 Atlanta. It gets back to the original debate = about whether a BUNDLE offer should use the same port numbers or = different ones, for bundle m-lines (what was called "BUNDLE vs. CRUNDLE" = if I recall correctly). One WG participant argued against using the same port numbers for bundle = lines. His argument was that since it was never described in an RFC, = and he knew of one implementation that didn't handle it well, that = therefore we couldn't send an offer using the same port numbers until we = found out if the far-end supported BUNDLE or not. That's what drove the decision to use different port numbers even in = regular bundle cases, afaik. Therefore, even for bundle-only lines, we can't use the same non-0 port = number for them, because the same theoretical issue will exist. Also, from a purely protocol perspective, it seems quite logical to me = to use a port number of 0 for an m-line you literally don't want to use = if the far-end doesn't support BUNDLE - a port number of 0 effectively = means "disabled" today, and that's basically what you want. What I = don't think is right, is (1) having the far-end send an SDP answer back = that sets a real port number for those same "disabled" m-lines, and (2) = not requiring another offer/answer exchange that then uses the correct = (same) port numbers for the previously-disabled m-lines. What I think should happen is the UAS should send an SDP answer using = port=3D0 for those same m-lines, and the UAC should then send a new = offer with those m-lines having the real port number of the bundle = transport, and the far-end should answer that in the same fashion. -hadriel On Aug 8, 2013, at 2:18 AM, Christer Holmberg = wrote: > Hi, > =20 > As has been indicated, bundle-only can only be used when one knows = that the receiver, and possible intermediaries etc, support it. > =20 > So, based on that assumption, my question is: why do we need port 0? = Why not assign the suggested bundle port to the bundle-only m- lines = from the beginning? As the bundle port is anyway going to be used (even = if the receiver does not want to use bundle), there is no need to = reserve additional ports for bundle-only m- lines. > =20 > Regards, > =20 > Christer > =20 >=20 >=20 > Sent from Windows using TouchDown (www.nitrodesk.com) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Thu Aug 8 06:04:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471E411E8131 for ; Thu, 8 Aug 2013 06:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx76EjRCGsNb for ; Thu, 8 Aug 2013 06:04:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA1411E80F5 for ; Thu, 8 Aug 2013 06:04:30 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-15-5203975d33cc Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9D.AF.05990.D5793025; Thu, 8 Aug 2013 15:04:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 15:04:29 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLRGsw Date: Thu, 8 Aug 2013 13:04:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> In-Reply-To: <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrW7sdOYgg7fzVS0+bfrEbDF1+WMW ByaPJUt+Mnl8fHqLJYApissmJTUnsyy1SN8ugSvj7skHjAVNihVL2ruYGxgnSnUxcnJICJhI fNzxgwXCFpO4cG89WxcjF4eQwGFGiX1tc5kgnMWMEu8OrmftYuTgYBOwkOj+pw1iigjoSRy9 xwnSyywgIzHjbCMTSFhYIExi/8sIkLCIQLjE4Q/bmCBsI4nbDxeD2SwCKhLPP25gBLF5BXwl fh7ayQ6xqZFR4urUGawgCU4BO4nFbYvZQGxGoNu+n1rDBLFLXOLDwevMEDcLSCzZcx7KFpV4 +fgfK4StJPFjwyUWiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoW MLKsYmTPTczMSS832sQIjJCDW36r7mC8c07kEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF8UWl OanFhxiZODilGhjVpl+5P1niO8syvskNpQ12CSybnrGYzdYzm2g5R/TS3lLXFWyxe+cnf40o OWDt8u9eiFlG7pwrLUKHNe4tPHBovqBQRWvoruX6tscK0r7Mq7qjOKFpzoMTeZ/Cans83Ow+ nPF9vmFWmGpVwaGHpzz1VtVP/rPv3fs30xprF4f/nh/6euXtzkB5JZbijERDLeai4kQAbIGn BF4CAAA= Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:04:36 -0000 Hi, > If I understand your question, you're asking why bundle-only m-lines woul= d use a port number of 0 in the offer, instead of using the same port numbe= r as the regular bundle m-line they're going to transport-bundle with? Yes. > I believe the rationale was basically argued about before, either in IETF= 86 Orlando or IETF 85 Atlanta. It gets back to the original debate about = whether a BUNDLE offer should=20 > use the same port numbers or different ones, for bundle m-lines (what was= called "BUNDLE vs. CRUNDLE" if I recall correctly). > > One WG participant argued against using the same port numbers for bundle = lines. His argument was that since it was never described in an RFC, and h= e knew of one implementation=20 > that didn't handle it well, that therefore we couldn't send an offer usin= g the same port numbers until we found out if the far-end supported BUNDLE = or not. > > That's what drove the decision to use different port numbers even in regu= lar bundle cases, afaik. Correct.=20 Another advantage of using different port numbers is that it provides a fal= lback in case the remote endpoint does not support, or does not want to use= BUNDLE. However, for bundle-only m- lines such fallback is not needed - they are ON= LY going to be used IF the remote endpoint chooses to use BUNDLE. ...and, based on the agreed scope, the Offerer KNOWS that the remote endpoi= nt supports BUNDLE, so the "one implementation that doesn't handle it" will= not be there :)=20 > Therefore, even for bundle-only lines, we can't use the same non-0 port n= umber for them, because the same theoretical issue will exist. Well, I think there will be some cases where we will have to allow the same= port number. Bundle-only is one case, trickle ICE another (where one can a= ssign port 9 for multiple m- lines). > Also, from a purely protocol perspective, it seems quite logical to me to= use a port number of 0 for an m-line you literally don't want to use if th= e far-end doesn't support=20 > BUNDLE - a port number of 0 effectively means "disabled" today, and that'= s basically what you want. =20 Well, one could also say that it means "Here are some m- lines I want to b= undle, with this port, but only if you (the remote endpoint) wants to use b= undle." :) > What I don't think is right, is (1) having the far-end send an SDP answer= back that sets a real port number for those same "disabled" m-lines, and (= 2) not requiring=20 > another offer/answer exchange that then uses the correct (same) port numb= ers for the previously-disabled m-lines. So far I agree with you on this one :) > What I think should happen is the UAS should send an SDP answer using por= t=3D0 for those same m-lines, and the UAC should then send a new offer with= those m-lines having the real port number of the bundle transport, and the= far-end should answer that in the same fashion. The problem is that the grouping framework does not allow, in SDP Answers, = usage of port=3D0 in grouped m- lines. It would require an update of the RF= C, and I think we want to avoid that. Also, if the Answerer chooses to use BUNDLE, as it DOES include its bundle = port for all other m- lines, I think it should also do it for the bundle-on= ly m- lines. Regards, Christer On Aug 8, 2013, at 2:18 AM, Christer Holmberg wrote: > Hi, > =20 > As has been indicated, bundle-only can only be used when one knows that t= he receiver, and possible intermediaries etc, support it. > =20 > So, based on that assumption, my question is: why do we need port 0? Why = not assign the suggested bundle port to the bundle-only m- lines from the b= eginning? As the bundle port is anyway going to be used (even if the receiv= er does not want to use bundle), there is no need to reserve additional por= ts for bundle-only m- lines. > =20 > Regards, > =20 > Christer > =20 >=20 >=20 > Sent from Windows using TouchDown (www.nitrodesk.com)=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From hadriel.kaplan@oracle.com Thu Aug 8 07:15:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0C111E812A for ; Thu, 8 Aug 2013 07:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3NFRJeNOjBB for ; Thu, 8 Aug 2013 07:15:52 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8794911E81B1 for ; Thu, 8 Aug 2013 07:15:52 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78EFmio015127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 14:15:49 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78EFlVe016360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 14:15:48 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78EFlJ7014728; Thu, 8 Aug 2013 14:15:47 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 07:15:47 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> Date: Thu, 8 Aug 2013 10:15:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 14:15:59 -0000 On Aug 8, 2013, at 9:04 AM, Christer Holmberg = wrote: > Another advantage of using different port numbers is that it provides = a fallback in case the remote endpoint does not support, or does not = want to use BUNDLE. Yes, except as far as I can tell all devices (and even intermediaries) = handle an offer with the same port number just fine. But that's just a = personal observation, and dangerous to assume ALL of them handle it = fine; that's why I didn't argue for long that we should use the same = port number in the offer - because it concerned me that someone knew of = at least one implementation that didn't handle it well. (not that we can = truly accommodate ALL implementations anyway, but it's got to be a heck = of a lot higher than simple majority, and as close to 100% as we can = get) > However, for bundle-only m- lines such fallback is not needed - they = are ONLY going to be used IF the remote endpoint chooses to use BUNDLE. > ...and, based on the agreed scope, the Offerer KNOWS that the remote = endpoint supports BUNDLE, so the "one implementation that doesn't handle = it" will not be there :)=20 For WebRTC sure - but we were talking about using BUNDLE generically. = Or at least that's what I thought you were asking about. If we're only = talking about using BUNDLE for WebRTC, then not only do you not need to = use a port=3D0, but you also don't need a second offer/answer, etc. >> Also, from a purely protocol perspective, it seems quite logical to = me to use a port number of 0 for an m-line you literally don't want to = use if the far-end doesn't support=20 >> BUNDLE - a port number of 0 effectively means "disabled" today, and = that's basically what you want. =20 >=20 > Well, one could also say that it means "Here are some m- lines I want = to bundle, with this port, but only if you (the remote endpoint) wants = to use bundle." :) We can certainly change the semantics of SDP offers with port=3D0 for = WebRTC, but I think it would be really dangerous to change its semantics = for general use. >> What I think should happen is the UAS should send an SDP answer using = port=3D0 for those same m-lines, and the UAC should then send a new = offer with those m-lines having the real port number of the bundle = transport, and the far-end should answer that in the same fashion. >=20 > The problem is that the grouping framework does not allow, in SDP = Answers, usage of port=3D0 in grouped m- lines. It would require an = update of the RFC, and I think we want to avoid that. Considering the number of docs the Unified-Plan proposes to either = create, change, update or whatever... methinks having BUNDLE update the = grouping framework RFC is rather a minor nit. :) -hadriel From adam@nostrum.com Thu Aug 8 10:12:14 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16C821F9E8B for ; Thu, 8 Aug 2013 10:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPEX8aZ+Yk0g for ; Thu, 8 Aug 2013 10:12:14 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 513F321F9E9D for ; Thu, 8 Aug 2013 10:12:11 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r78HC43n083119 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 12:12:05 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5203D15F.7090005@nostrum.com> Date: Thu, 08 Aug 2013 12:11:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------080906070500040606030809" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:12:14 -0000 This is a multi-part message in MIME format. --------------080906070500040606030809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/8/13 01:18, Christer Holmberg wrote: > As has been indicated, bundle-only can only be used when one knows > that the receiver, and possible intermediaries etc, support it. That's not quite right. Bundle-only can be sent in any offer. Even if you don't know anything about the remote endpoint or other devices along the path. The bundle-only lines are designed to succeed only when the remote endpoint supports bundle. They are designed to fail in a very graceful, predictable, backwards-compatible, and well-defined way under other circumstances. > So, based on that assumption, my question is: why do we need port 0? > Why not assign the suggested bundle port to the bundle-only m- lines > from the beginning? As the bundle port is anyway going to be used > (even if the receiver does not want to use bundle), there is no need > to reserve additional ports for bundle-only m- lines. The point of the port-0 mechanism is that it will cause that m-line line to fail if you hit a non-bundle endpoint. If we put a valid port there that matches other m-lines, then legacy implementations behave in odd, unpredictable, and (most importantly) widely varying ways. The reaction to port 0 is better defined, and more consistent. /a --------------080906070500040606030809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/8/13 01:18, Christer Holmberg wrote:
As has been indicated, bundle-only can only be used when one knows that the receiver, and possible intermediaries etc, support it.

That's not quite right.

Bundle-only can be sent in any offer. Even if you don't know anything about the remote endpoint or other devices along the path.

The bundle-only lines are designed to succeed only when the remote endpoint supports bundle. They are designed to fail in a very graceful, predictable, backwards-compatible, and well-defined way under other circumstances.

 So, based on that assumption, my question is: why do we need port 0? Why not assign the suggested bundle port to the bundle-only m- lines from the beginning? As the bundle port is anyway going to be used (even if the receiver does not want to use bundle), there is no need to reserve additional ports for bundle-only m- lines.

The point of the port-0 mechanism is that it will cause that m-line line to fail if you hit a non-bundle endpoint. If we put a valid port there that matches other m-lines, then legacy implementations behave in odd, unpredictable, and (most importantly) widely varying ways. The reaction to port 0 is better defined, and more consistent.

/a
--------------080906070500040606030809-- From partha@parthasarathi.co.in Thu Aug 8 10:30:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A1211E8153 for ; Thu, 8 Aug 2013 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0+Ofe+asSSU for ; Thu, 8 Aug 2013 10:30:25 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id 8D41811E8142 for ; Thu, 8 Aug 2013 10:30:17 -0700 (PDT) Received: from userPC (unknown [122.166.142.138]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id E37931908118; Thu, 8 Aug 2013 17:30:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1375983016; bh=kgl/CGrHXag5qtUspfDxVeJVM7kCO2GdyANso1dAkZ8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mGKNWOoUL/gIj7VkAsnRwobN+Kiu9Ac3KUNNAa6R2b9BrI19HfS1vK73JiaRhOvZB g7ahEeh6TVOFBZ8EoaQWPNL7CzOc/ykdH8rhnaQlPDERAQvxrf/IgP+o4FVtRWd6iH i8EQFHrQATNLBY9rMhh+MX5madAvuN0/x8yR3X4g= From: "Parthasarathi R" To: "'Hadriel Kaplan'" , "'Christer Holmberg'" References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> In-Reply-To: Date: Thu, 8 Aug 2013 23:00:04 +0530 Message-ID: <001601ce945c$ef7509d0$ce5f1d70$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6UQdUj0TOgZHxvRHKiPXqxA0uMkgAGUhYQ Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.5203D5A8.0114, 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: 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 70.87.28.138 Cc: 'mmusic' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:30:30 -0000 Hi Hadriel/Christer, My understanding is that the initial offer with same port breaks more than one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft indicates one of the possible interop issue with existing mobile networks. So, I don't agree with Hadriel claim of 99% system works with same port. The current BUNDLE draft mechanism interop in the better way. In case it is known to offerer that answerer supports BUNDLE before sending offer, it is fine to send the same port in the offer using bundle-only attribute. I'm not seeing any issue there. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Thursday, August 08, 2013 7:46 PM > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle- > only m- lines? > > > On Aug 8, 2013, at 9:04 AM, Christer Holmberg > wrote: > > > Another advantage of using different port numbers is that it provides > a fallback in case the remote endpoint does not support, or does not > want to use BUNDLE. > > Yes, except as far as I can tell all devices (and even intermediaries) > handle an offer with the same port number just fine. But that's just a > personal observation, and dangerous to assume ALL of them handle it > fine; that's why I didn't argue for long that we should use the same > port number in the offer - because it concerned me that someone knew of > at least one implementation that didn't handle it well. (not that we > can truly accommodate ALL implementations anyway, but it's got to be a > heck of a lot higher than simple majority, and as close to 100% as we > can get) > > > > However, for bundle-only m- lines such fallback is not needed - they > are ONLY going to be used IF the remote endpoint chooses to use BUNDLE. > > ...and, based on the agreed scope, the Offerer KNOWS that the remote > endpoint supports BUNDLE, so the "one implementation that doesn't > handle it" will not be there :) > > For WebRTC sure - but we were talking about using BUNDLE generically. > Or at least that's what I thought you were asking about. If we're only > talking about using BUNDLE for WebRTC, then not only do you not need to > use a port=0, but you also don't need a second offer/answer, etc. > > > >> Also, from a purely protocol perspective, it seems quite logical to > me to use a port number of 0 for an m-line you literally don't want to > use if the far-end doesn't support > >> BUNDLE - a port number of 0 effectively means "disabled" today, and > that's basically what you want. > > > > Well, one could also say that it means "Here are some m- lines I > want to bundle, with this port, but only if you (the remote endpoint) > wants to use bundle." :) > > We can certainly change the semantics of SDP offers with port=0 for > WebRTC, but I think it would be really dangerous to change its > semantics for general use. > > > >> What I think should happen is the UAS should send an SDP answer > using port=0 for those same m-lines, and the UAC should then send a new > offer with those m-lines having the real port number of the bundle > transport, and the far-end should answer that in the same fashion. > > > > The problem is that the grouping framework does not allow, in SDP > Answers, usage of port=0 in grouped m- lines. It would require an > update of the RFC, and I think we want to avoid that. > > Considering the number of docs the Unified-Plan proposes to either > create, change, update or whatever... methinks having BUNDLE update the > grouping framework RFC is rather a minor nit. :) > > -hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From adam@nostrum.com Thu Aug 8 10:40:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E156511E8142 for ; Thu, 8 Aug 2013 10:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7iXEvABpLIu for ; Thu, 8 Aug 2013 10:40:17 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C226211E8200 for ; Thu, 8 Aug 2013 10:40:00 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r78HdvwD086082 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 12:39:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5203D7E7.4070207@nostrum.com> Date: Thu, 08 Aug 2013 12:39:51 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> In-Reply-To: <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:40:18 -0000 On 8/8/13 07:21, Hadriel Kaplan wrote: > What I think should happen is the UAS should send an SDP answer using port=0 for those same m-lines Why? You're proposing that we remove the mechanism for rejecting media streams. Consider the example I put up during the meeting: you have a regular audio m-line and a bundle-only video m-line. The other end wants to decline the video. You've just taken away the tool for doing so. There'd better be a heck of an upside to removing this critical protocol mechanism. So far, the upside you've described is "Hadriel thinks it's not aesthetically pleasing," which doesn't seem to be a very practical consideration. Is there a technically compelling argument for your position? /a From christer.holmberg@ericsson.com Thu Aug 8 11:19:28 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1786511E81F7 for ; Thu, 8 Aug 2013 11:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.08 X-Spam-Level: X-Spam-Status: No, score=-4.08 tagged_above=-999 required=5 tests=[AWL=-1.482, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dq6AWeLahXa for ; Thu, 8 Aug 2013 11:19:23 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C05D121F95A6 for ; Thu, 8 Aug 2013 11:19:17 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-97-5203e1241ba4 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 0C.C1.02664.421E3025; Thu, 8 Aug 2013 20:19:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 20:19:16 +0200 From: Christer Holmberg To: Parthasarathi R , 'Hadriel Kaplan' Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlFzzTHFUEWnKxkeE8bnrSX+BlpmLntot Date: Thu, 8 Aug 2013 18:19:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4224FF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> , <001601ce945c$ef7509d0$ce5f1d70$@co.in> In-Reply-To: <001601ce945c$ef7509d0$ce5f1d70$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4224FFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvra7KQ+Ygg9NtUhafNn1itpi6/DGL xeRPfawOzB5Llvxk8vj49BaLx4f5X9gDmKO4bFJSczLLUov07RK4Mha9ec5U0B5TMXPLItYG xj/eXYycHBICJhJTX7ezQthiEhfurWfrYuTiEBI4yigxZ8pvdghnMaPElJZrjF2MHBxsAhYS 3f+0QRpEBBIk7l1byAZiMwvISWyY/BLMFhYIk3h+5yAzRE24xPk3p5kgbCOJxx+usYPYLAIq Ektaz4HZvAK+ErdffwM7QkhgIZPE5EcJIDYn0HFvJj4Am8MIdNz3U2uYIHaJS9x6Mp8J4mgB iSV7zjND2KISLx//Y4WoyZe4sa+PGWK+oMTJmU9YJjCKzELSPgtJ2SwkZRBxHYkFuz+xQdja EssWvmaGsc8ceMyELL6AkX0VI0dxanFSbrqRwSZGYEQd3PLbYgfj5b82hxilOViUxHm36J0J FBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4KZcp43Tw6SZzU7m+owr+pXz7L7v8z+dzcksy zFDeVhD1861IpFHYypPL9rr+ncm/eZ9KXanxsi/a9aem3BJktvHnml76t6codV+Ni+bXN/of tp962/Ll1g9TnYrTMc175wkrveidy5o7R81U6cm2giNFAY4C5xfH+jY2rPri9lW0SZ4vVU6J pTgj0VCLuag4EQAYILwBdgIAAA== Cc: 'mmusic' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:19:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4224FFESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Some people suggested that it should be allowed to send the same ports in t= he first offer, IF it is known that the answerer supports BUNDLE. However, that is currently not described in the draft, and there were also = objections to such approach. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Parthasarathi R [partha@parthasarathi.co.in] To: 'Hadriel Kaplan' [hadriel.kaplan@oracle.com]; Christer Holmbe= rg [christer.holmberg@ericsson.com] CC: 'mmusic' [mmusic@ietf.org] Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? Hi Hadriel/Christer, My understanding is that the initial offer with same port breaks more than one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft indicates one of the possible interop issue with existing mobile networks. So, I don't agree with Hadriel claim of 99% system works with same port. Th= e current BUNDLE draft mechanism interop in the better way. In case it is known to offerer that answerer supports BUNDLE before sending offer, it is fine to send the same port in the offer using bundle-only attribute. I'm not seeing any issue there. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Thursday, August 08, 2013 7:46 PM > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle- > only m- lines? > > > On Aug 8, 2013, at 9:04 AM, Christer Holmberg > wrote: > > > Another advantage of using different port numbers is that it provides > a fallback in case the remote endpoint does not support, or does not > want to use BUNDLE. > > Yes, except as far as I can tell all devices (and even intermediaries) > handle an offer with the same port number just fine. But that's just a > personal observation, and dangerous to assume ALL of them handle it > fine; that's why I didn't argue for long that we should use the same > port number in the offer - because it concerned me that someone knew of > at least one implementation that didn't handle it well. (not that we > can truly accommodate ALL implementations anyway, but it's got to be a > heck of a lot higher than simple majority, and as close to 100% as we > can get) > > > > However, for bundle-only m- lines such fallback is not needed - they > are ONLY going to be used IF the remote endpoint chooses to use BUNDLE. > > ...and, based on the agreed scope, the Offerer KNOWS that the remote > endpoint supports BUNDLE, so the "one implementation that doesn't > handle it" will not be there :) > > For WebRTC sure - but we were talking about using BUNDLE generically. > Or at least that's what I thought you were asking about. If we're only > talking about using BUNDLE for WebRTC, then not only do you not need to > use a port=3D0, but you also don't need a second offer/answer, etc. > > > >> Also, from a purely protocol perspective, it seems quite logical to > me to use a port number of 0 for an m-line you literally don't want to > use if the far-end doesn't support > >> BUNDLE - a port number of 0 effectively means "disabled" today, and > that's basically what you want. > > > > Well, one could also say that it means "Here are some m- lines I > want to bundle, with this port, but only if you (the remote endpoint) > wants to use bundle." :) > > We can certainly change the semantics of SDP offers with port=3D0 for > WebRTC, but I think it would be really dangerous to change its > semantics for general use. > > > >> What I think should happen is the UAS should send an SDP answer > using port=3D0 for those same m-lines, and the UAC should then send a new > offer with those m-lines having the real port number of the bundle > transport, and the far-end should answer that in the same fashion. > > > > The problem is that the grouping framework does not allow, in SDP > Answers, usage of port=3D0 in grouped m- lines. It would require an > update of the RFC, and I think we want to avoid that. > > Considering the number of docs the Unified-Plan proposes to either > create, change, update or whatever... methinks having BUNDLE update the > grouping framework RFC is rather a minor nit. :) > > -hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C4224FFESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Some people suggested that it should be allowed= to send the same ports in the first offer, IF it is known that the answere= r supports BUNDLE.
 
However, that is currently not described in the= draft, and there were also objections to such approach.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: &apos;Hadriel Kaplan&apos; [hadriel.kaplan@oracle.com]; = Christer Holmberg [christer.holmberg@ericsson.com]
CC: &apos;mmusic&apos; [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?
Hi Hadriel/Christer,

My understanding is that the initial offer with same port breaks more than<= br> one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft
indicates one of the possible interop issue with existing mobile networks.<= br> So, I don't agree with Hadriel claim of 99% system works with same port. Th= e
current BUNDLE draft mechanism interop in the better way.

In case it is known to offerer that answerer supports BUNDLE before sending=
offer, it is fine to send the same port in the offer using bundle-only
attribute. I'm not seeing any issue there.

Thanks
Partha





> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Thursday, August 08, 2013 7:46 PM
> To: Christer Holmberg
> Cc: mmusic
> Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-=
> only m- lines?
>
>
> On Aug 8, 2013, at 9:04 AM, Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
>
> > Another advantage of using different port numbers is that it prov= ides
> a fallback in case the remote endpoint does not support, or does not > want to use BUNDLE.
>
> Yes, except as far as I can tell all devices (and even intermediaries)=
> handle an offer with the same port number just fine.  But that's = just a
> personal observation, and dangerous to assume ALL of them handle it > fine; that's why I didn't argue for long that we should use the same > port number in the offer - because it concerned me that someone knew o= f
> at least one implementation that didn't handle it well. (not that we > can truly accommodate ALL implementations anyway, but it's got to be a=
> heck of a lot higher than simple majority, and as close to 100% as we<= br> > can get)
>
>
> > However, for bundle-only m- lines such fallback is not needed - t= hey
> are ONLY going to be used IF the remote endpoint chooses to use BUNDLE= .
> > ...and, based on the agreed scope, the Offerer KNOWS that the rem= ote
> endpoint supports BUNDLE, so the "one implementation that doesn't=
> handle it" will not be there :)
>
> For WebRTC sure - but we were talking about using BUNDLE generically.<= br> > Or at least that's what I thought you were asking about.  If we'r= e only
> talking about using BUNDLE for WebRTC, then not only do you not need t= o
> use a port=3D0, but you also don't need a second offer/answer, etc. >
>
> >> Also, from a purely protocol perspective, it seems quite logi= cal to
> me to use a port number of 0 for an m-line you literally don't want to=
> use if the far-end doesn't support
> >> BUNDLE - a port number of 0 effectively means "disabled&= quot; today, and
> that's basically what you want.
> >
> > Well, one could also say that it means "Here are some m- lin= es  I
> want to bundle, with this port, but only if you (the remote endpoint)<= br> > wants to use bundle." :)
>
> We can certainly change the semantics of SDP offers with port=3D0 for<= br> > WebRTC, but I think it would be really dangerous to change its
> semantics for general use.
>
>
> >> What I think should happen is the UAS should send an SDP answ= er
> using port=3D0 for those same m-lines, and the UAC should then send a = new
> offer with those m-lines having the real port number of the bundle
> transport, and the far-end should answer that in the same fashion.
> >
> > The problem is that the grouping framework does not allow, in SDP=
> Answers, usage of port=3D0 in grouped m- lines. It would require an > update of the RFC, and I think we want to avoid that.
>
> Considering the number of docs the Unified-Plan proposes to either
> create, change, update or whatever... methinks having BUNDLE update th= e
> grouping framework RFC is rather a minor nit. :)
>
> -hadriel
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

 --_000_7594FB04B1934943A5C02806D1A2204B1C4224FFESESSMB209erics_-- From hadriel.kaplan@oracle.com Thu Aug 8 11:22:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2788E21F9CD9 for ; Thu, 8 Aug 2013 11:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBsgr1TMz9VW for ; Thu, 8 Aug 2013 11:21:58 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 88C3021F8528 for ; Thu, 8 Aug 2013 11:21:58 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78ILueL027115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 18:21:57 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78ILrKO027894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 18:21:55 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78ILr46009023; Thu, 8 Aug 2013 18:21:53 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 11:21:53 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5203D7E7.4070207@nostrum.com> Date: Thu, 8 Aug 2013 14:21:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:22:11 -0000 On Aug 8, 2013, at 1:39 PM, Adam Roach wrote: > On 8/8/13 07:21, Hadriel Kaplan wrote: >> What I think should happen is the UAS should send an SDP answer using = port=3D0 for those same m-lines >=20 > Why? You're proposing that we remove the mechanism for rejecting media = streams. Consider the example I put up during the meeting: you have a = regular audio m-line and a bundle-only video m-line. The other end wants = to decline the video. You've just taken away the tool for doing so. >=20 > There'd better be a heck of an upside to removing this critical = protocol mechanism. So far, the upside you've described is "Hadriel = thinks it's not aesthetically pleasing," which doesn't seem to be a very = practical consideration. Is there a technically compelling argument for = your position? Huh? You either misunderstood my email, or I'm not following your = statement above. I don't believe I'm proposing we remove the mechanism = of rejecting media streams. How/where/when did I propose that? You = lost me. And I don't think what I'm suggesting is to be "aesthetically pleasing" = either... although SDP-based ascii art might be kinda cool. -hadriel From christer.holmberg@ericsson.com Thu Aug 8 11:24:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DE211E8149 for ; Thu, 8 Aug 2013 11:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HUe8rHPseWA for ; Thu, 8 Aug 2013 11:24:06 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2252121F9E37 for ; Thu, 8 Aug 2013 11:24:05 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-8a-5203e2438333 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 60.B6.19388.342E3025; Thu, 8 Aug 2013 20:24:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 20:24:03 +0200 From: Christer Holmberg To: Adam Roach , Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U0= Date: Thu, 8 Aug 2013 18:24:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> In-Reply-To: <5203D7E7.4070207@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C422522ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvra7zI+Ygg84GWYs9fxexW3za9InZ YuryxywOzB5Llvxk8pi18wmLx8ent1gCmKO4bFJSczLLUov07RK4Mg7+mMRYsE2hYtuzQ8wN jLekuxg5OCQETCQWH87pYuQEMsUkLtxbz9bFyMUhJHCYUeLJxresEM5iRonJZ++ygzSwCVhI dP/TBmkQEfCVuHhxJjOIzSwgIzHjbCMTSImwQJjE1JcpECXhEoc/bAMLiwhYSax94gsSZhFQ kfjRO50JxOYFmtI15TgzxKYFjBIrDj5lA0lwCmhLTL6yih3EZgS67fupNUwQq8Qlbj2ZzwRx s4DEkj3nmSFsUYmXj/+xQtTkS6xf8YIRYoGgxMmZT1gmMIrMQtI+C0nZLCRlEHE9iRtTp7BB 2NoSyxa+ZoawdSVm/DvEgiy+gJF9FSN7bmJmTnq5+SZGYCwd3PLbYAfjpvtihxilOViUxHk3 650JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4q+a7yqoj70/dv7if20ym/UH4vbvBpqnW P8wSHhk+TDxefPjokbn3DtYyfmYQ/F748UX0n4nlv+be4Uu5dzbcJk3P1Pfqpqiv0VJbn/xm Xvj1fZ0aX1n2haryzDMmFh3pMxiu5hn8OX015+t9noMO3EdOKmexTFXeL2f16INZr/eX1bZ3 fuy7q8RSnJFoqMVcVJwIAPicbdJzAgAA Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:24:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C422522ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I agree with Adam on this one. Port zero is used in answers to reject a str= eam, and I don't think we should change that. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Adam Roach [adam@nostrum.com] To: Hadriel Kaplan [hadriel.kaplan@oracle.com] CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmusic@ietf= .org] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On 8/8/13 07:21, Hadriel Kaplan wrote: > What I think should happen is the UAS should send an SDP answer using por= t=3D0 for those same m-lines Why? You're proposing that we remove the mechanism for rejecting media streams. Consider the example I put up during the meeting: you have a regular audio m-line and a bundle-only video m-line. The other end wants to decline the video. You've just taken away the tool for doing so. There'd better be a heck of an upside to removing this critical protocol mechanism. So far, the upside you've described is "Hadriel thinks it's not aesthetically pleasing," which doesn't seem to be a very practical consideration. Is there a technically compelling argument for your position= ? /a --_000_7594FB04B1934943A5C02806D1A2204B1C422522ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I agree with Adam on this one. Port zero is use= d in answers to reject a stream, and I don't think we should change that.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Adam Roach [adam@nostrum.com]
To: Hadriel Kaplan [hadriel.kaplan@oracle.com]
CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmus= ic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?
On 8/8/13 07:21, Hadriel Kaplan wrote:
> What I think should happen is the UAS should send an SDP answer using = port=3D0 for those same m-lines

Why? You're proposing that we remove the mechanism for rejecting media
streams. Consider the example I put up during the meeting: you have a
regular audio m-line and a bundle-only video m-line. The other end wants to decline the video. You've just taken away the tool for doing so.

There'd better be a heck of an upside to removing this critical protocol mechanism. So far, the upside you've described is "Hadriel thinks it's=
not aesthetically pleasing," which doesn't seem to be a very practical=
consideration. Is there a technically compelling argument for your position= ?

/a
 --_000_7594FB04B1934943A5C02806D1A2204B1C422522ESESSMB209erics_-- From christer.holmberg@ericsson.com Thu Aug 8 11:32:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AF611E8149 for ; Thu, 8 Aug 2013 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.067 X-Spam-Level: X-Spam-Status: No, score=-4.067 tagged_above=-999 required=5 tests=[AWL=-1.469, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZLIXiOdVnQj for ; Thu, 8 Aug 2013 11:32:51 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 71C1911E80F4 for ; Thu, 8 Aug 2013 11:32:50 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-a8-5203e451487c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CB.72.02664.154E3025; Thu, 8 Aug 2013 20:32:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 20:32:49 +0200 From: Christer Holmberg To: Adam Roach Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlFprBnOgSvDKakySvPl07qCSvZmLoqjt Date: Thu, 8 Aug 2013 18:32:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422564@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se>, <5203D15F.7090005@nostrum.com> In-Reply-To: <5203D15F.7090005@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C422564ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvrW7gE+Yggz+NahZ7/i5it5i6/DGL A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWx79MzpoKFehWtRzaxNjD+Veti5OSQEDCR +PZzFxOELSZx4d56ti5GLg4hgaOMEqvOHYJyFjNKbF34H8jh4GATsJDo/qcN0iAioCjRdvgm M4jNLCAjMeNsIxNIibBAmMTUlykQJeEShz9sY4KwjSSuPDrCCmKzCKhIvJ88ASzOK+ArsWLT JUYQW0ggR6Lh0SsWEJtTQFtiQsN5MJsR6Lbvp9YwQawSl7j1ZD7UzQISS/acZ4awRSVePv7H ClGTL/Fo63JWiPmCEidnPmGZwCgyC0n7LCRls5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8Q C7L4Akb2VYwcxanFSbnpRgabGIGxc3DLb4sdjJf/2hxilOZgURLn3aJ3JlBIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QD4zyJ32eeBVVcrv+VVcQfrC5rELrf0Op9h9jzWmOVTz936efPP/dX yLtIJstT7qn3lLmxat+eW8o2+f4oM7l8XmtSLkcTZ9Wj7OBtKU/sBR0erpHoVzh+M+NQ988C yezCiIYZYS4vSxL2bxD1+M6tuaz1m9MKuZked0JLtm8qefywoNzo+6UDSizFGYmGWsxFxYkA Z5WZ3msCAAA= Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:32:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C422564ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Adam, Ok, so if we make no assumptions about the receiver, I understand the reaso= ning for port zero. However, even if both endpoints support bundle-only, what if there are inte= rmediaries that don't? They may pass the SDP, but unless you send a second = offer, with the bundle port, I doubt they will forward any media associated= with the bundle-only m- lines towards the Offerer, as they only see a port= zero value. Or, do you assume that intermediaries that don't support bundle-only will r= eject the first offer? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Adam Roach [adam@nostrum.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: mmusic [mmusic@ietf.org] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On 8/8/13 01:18, Christer Holmberg wrote: As has been indicated, bundle-only can only be used when one knows that the= receiver, and possible intermediaries etc, support it. That's not quite right. Bundle-only can be sent in any offer. Even if you don't know anything about= the remote endpoint or other devices along the path. The bundle-only lines are designed to succeed only when the remote endpoint= supports bundle. They are designed to fail in a very graceful, predictable= , backwards-compatible, and well-defined way under other circumstances. So, based on that assumption, my question is: why do we need port 0? Why n= ot assign the suggested bundle port to the bundle-only m- lines from the be= ginning? As the bundle port is anyway going to be used (even if the receive= r does not want to use bundle), there is no need to reserve additional port= s for bundle-only m- lines. The point of the port-0 mechanism is that it will cause that m-line line to= fail if you hit a non-bundle endpoint. If we put a valid port there that m= atches other m-lines, then legacy implementations behave in odd, unpredicta= ble, and (most importantly) widely varying ways. The reaction to port 0 is = better defined, and more consistent. /a --_000_7594FB04B1934943A5C02806D1A2204B1C422564ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Adam,
 
Ok, so if we make no assumptions about the rece= iver, I understand the reasoning for port zero.
 
However, even if both endpoints support bundle-= only, what if there are intermediaries that don't? They may pass the SDP, b= ut unless you send a second offer, with the bundle port, I doubt they will = forward any media associated with the bundle-only m- lines towards the Offerer, as they only see a port zero val= ue.
 
Or, do you assume that intermediaries that don'= t support bundle-only will reject the first offer?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Adam Roach [adam@nostrum.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: mmusic [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?
On 8/8/13 01:18, Christer Holmberg wrote:
As has been indicated, bun= dle-only can only be used when one knows that the receiver, and possible in= termediaries etc, support it.

That's not quite right.

Bundle-only can be sent in any offer. Even if you don't know anything about= the remote endpoint or other devices along the path.

The bundle-only lines are designed to succeed only when the remote endpoint= supports bundle. They are designed to fail in a very graceful, predictable= , backwards-compatible, and well-defined way under other circumstances.

 So, based on that assumption, my question= is: why do we need port 0? Why not assign the suggested bundle port t= o the bundle-only m- lines from the beginning? As the bundle port is anyway= going to be used (even if the receiver does not want to use bundle), there is no need to reserve additional ports for = bundle-only m- lines.

The point of the port-0 mechanism is that it will cause that m-line line to= fail if you hit a non-bundle endpoint. If we put a valid port there that m= atches other m-lines, then legacy implementations behave in odd, unpredicta= ble, and (most importantly) widely varying ways. The reaction to port 0 is better defined, and more consisten= t.

/a
--_000_7594FB04B1934943A5C02806D1A2204B1C422564ESESSMB209erics_-- From christer.holmberg@ericsson.com Thu Aug 8 11:41:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BACB11E8150 for ; Thu, 8 Aug 2013 11:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.049 X-Spam-Level: X-Spam-Status: No, score=-4.049 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoqSseGYPFr5 for ; Thu, 8 Aug 2013 11:41:06 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 62F3211E8208 for ; Thu, 8 Aug 2013 11:40:58 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-59-5203e639353e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 23.D2.02664.936E3025; Thu, 8 Aug 2013 20:40:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 20:40:57 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLRGsw///1NYCAAGufzQ== Date: Thu, 8 Aug 2013 18:40:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C42259A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C42259AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvra7lM+Ygg58/FS0+bfrEbDF1+WMW ByaPJUt+Mnl8fHqLJYApissmJTUnsyy1SN8ugSvjT9cH5oIZHhV/Zok0MK6x7mLk4JAQMJG4 cDC2i5ETyBSTuHBvPVsXIxeHkMBRRoktlzqYIJzFjBLtJ1YwgTSwCVhIdP/TBjFFBPQkjt7j BOllFpCRmHG2EaxCWCBMYurLFJCwiEC4xOEP25ggbCeJ1su9jCA2i4CKxJ3ze8DivAK+EhMu dLBAbPrOKDFvwj52kASngJ3EjHmtYEWMQLd9P7WGCWKXuMStJ/OZIG4WkFiy5zwzhC0q8fLx P1aImnyJ83Nms0EsEJQ4OfMJywRGkVlI2mchKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+Z kMUXMLKvYuQoTi1Oyk03MtjECIybg1t+W+xgvPzX5hCjNAeLkjjvFr0zgUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYeR12/qgtmbvseMM/A67VP3jq45YcWvctaXWHzq1Cds9J6lMd8jQy Z946FLs5tqFj8YpVUaZfM93lP4s/bGLhtzvbc+nFrD1n55upPnI5LXPvTWdCm8vxFm2DX0v8 5G8fftJ5P2xqorXnFZsrzNqhy2xDeiVkJySHxvb/uqvz2cqJ3/7wszMHlFiKMxINtZiLihMB 57+vR2kCAAA= Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:41:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C42259AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hadriel, My opinion is also that intermediaries will handle offers with the same por= t value. But, there were other opinions, so we agreed on the two-O/A mechan= ism. Regarding the modified semantics of port zero in bundle-only m- lines, if w= e want to change the semantics only for WebRTC, it means we can only allow = bundle-only for WebRTC. Because, I don't think we want to have different se= mantics for port zero bundle-only m- lines depending on whether they are us= ed in WebRTC or not... Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hadriel Kaplan [hadriel.kaplan@oracle.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: mmusic [mmusic@ietf.org] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On Aug 8, 2013, at 9:04 AM, Christer Holmberg wrote: > Another advantage of using different port numbers is that it provides a f= allback in case the remote endpoint does not support, or does not want to u= se BUNDLE. Yes, except as far as I can tell all devices (and even intermediaries) hand= le an offer with the same port number just fine. But that's just a persona= l observation, and dangerous to assume ALL of them handle it fine; that's w= hy I didn't argue for long that we should use the same port number in the o= ffer - because it concerned me that someone knew of at least one implementa= tion that didn't handle it well. (not that we can truly accommodate ALL imp= lementations anyway, but it's got to be a heck of a lot higher than simple = majority, and as close to 100% as we can get) > However, for bundle-only m- lines such fallback is not needed - they are = ONLY going to be used IF the remote endpoint chooses to use BUNDLE. > ...and, based on the agreed scope, the Offerer KNOWS that the remote endp= oint supports BUNDLE, so the "one implementation that doesn't handle it" wi= ll not be there :) For WebRTC sure - but we were talking about using BUNDLE generically. Or a= t least that's what I thought you were asking about. If we're only talking= about using BUNDLE for WebRTC, then not only do you not need to use a port= =3D0, but you also don't need a second offer/answer, etc. >> Also, from a purely protocol perspective, it seems quite logical to me t= o use a port number of 0 for an m-line you literally don't want to use if t= he far-end doesn't support >> BUNDLE - a port number of 0 effectively means "disabled" today, and that= 's basically what you want. > > Well, one could also say that it means "Here are some m- lines I want to= bundle, with this port, but only if you (the remote endpoint) wants to use= bundle." :) We can certainly change the semantics of SDP offers with port=3D0 for WebRT= C, but I think it would be really dangerous to change its semantics for gen= eral use. >> What I think should happen is the UAS should send an SDP answer using po= rt=3D0 for those same m-lines, and the UAC should then send a new offer wit= h those m-lines having the real port number of the bundle transport, and th= e far-end should answer that in the same fashion. > > The problem is that the grouping framework does not allow, in SDP Answers= , usage of port=3D0 in grouped m- lines. It would require an update of the = RFC, and I think we want to avoid that. Considering the number of docs the Unified-Plan proposes to either create, = change, update or whatever... methinks having BUNDLE update the grouping fr= amework RFC is rather a minor nit. :) -hadriel --_000_7594FB04B1934943A5C02806D1A2204B1C42259AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Hadriel,
 
My opinion is also that intermediaries will han= dle offers with the same port value. But, there were other opinions, so we = agreed on the two-O/A mechanism.
 
Regarding the modified semantics of port z= ero in bundle-only m- lines, if we want to change the semantics only for We= bRTC, it means we can only allow bundle-only for WebRTC. Because, I don't t= hink we want to have different semantics for port zero bundle-only m- lines depending on whether they are used= in WebRTC or not...
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: mmusic [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

On Aug 8, 2013, at 9:04 AM, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:

> Another advantage of using different port numbers is that it provides = a fallback in case the remote endpoint does not support, or does not want t= o use BUNDLE.

Yes, except as far as I can tell all devices (and even intermediaries) hand= le an offer with the same port number just fine.  But that's just a pe= rsonal observation, and dangerous to assume ALL of them handle it fine; tha= t's why I didn't argue for long that we should use the same port number in the offer - because it concerned me = that someone knew of at least one implementation that didn't handle it well= . (not that we can truly accommodate ALL implementations anyway, but it's g= ot to be a heck of a lot higher than simple majority, and as close to 100% as we can get)


> However, for bundle-only m- lines such fallback is not needed - they a= re ONLY going to be used IF the remote endpoint chooses to use BUNDLE.
> ...and, based on the agreed scope, the Offerer KNOWS that the remote e= ndpoint supports BUNDLE, so the "one implementation that doesn't handl= e it" will not be there :)

For WebRTC sure - but we were talking about using BUNDLE generically. = Or at least that's what I thought you were asking about.  If we're on= ly talking about using BUNDLE for WebRTC, then not only do you not need to = use a port=3D0, but you also don't need a second offer/answer, etc.


>> Also, from a purely protocol perspective, it seems quite logical t= o me to use a port number of 0 for an m-line you literally don't want to us= e if the far-end doesn't support
>> BUNDLE - a port number of 0 effectively means "disabled"= today, and that's basically what you want. 
>
> Well, one could also say that it means "Here are some m- lines&nb= sp; I want to bundle, with this port, but only if you (the remote endpoint)= wants to use bundle." :)

We can certainly change the semantics of SDP offers with port=3D0 for WebRT= C, but I think it would be really dangerous to change its semantics for gen= eral use.


>> What I think should happen is the UAS should send an SDP answer us= ing port=3D0 for those same m-lines, and the UAC should then send a new off= er with those m-lines having the real port number of the bundle transport, = and the far-end should answer that in the same fashion.
>
> The problem is that the grouping framework does not allow, in SDP Answ= ers, usage of port=3D0 in grouped m- lines. It would require an update of t= he RFC, and I think we want to avoid that.

Considering the number of docs the Unified-Plan proposes to either create, = change, update or whatever... methinks having BUNDLE update the grouping fr= amework RFC is rather a minor nit. :)

-hadriel


 --_000_7594FB04B1934943A5C02806D1A2204B1C42259AESESSMB209erics_-- From hadriel.kaplan@oracle.com Thu Aug 8 11:42:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C204321F9F9D for ; Thu, 8 Aug 2013 11:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ABnbEl-kyOz for ; Thu, 8 Aug 2013 11:42:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5651311E8150 for ; Thu, 8 Aug 2013 11:42:42 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78IgeB2015688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 18:42:40 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78IgdV2022410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 18:42:39 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78IgcGK013557; Thu, 8 Aug 2013 18:42:38 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 11:42:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <001601ce945c$ef7509d0$ce5f1d70$@co.in> Date: Thu, 8 Aug 2013 14:42:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6C8CDE49-3C14-49EB-861F-2B3B0B108D6E@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> <001601ce945c$ef7509d0$ce5f1d70$@co.in> To: Parthasarathi R X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:42:54 -0000 On Aug 8, 2013, at 1:30 PM, Parthasarathi R = wrote: > My understanding is that the initial offer with same port breaks more = than > one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft > indicates one of the possible interop issue with existing mobile = networks. I've only skimmed the draft, but I don't see the problem. I know = there's an issue with multiplexing all the RTP on one 5-tuple, but = that's actually an orthogonal issue. I was talking about whether an SDP = offer with multiple m-lines using the same port number would have issues = or not. Am I missing something in the draft? > So, I don't agree with Hadriel claim of 99% system works with same = port. The > current BUNDLE draft mechanism interop in the better way. Please don't misrepresent what I said - I think if you read my = paragraph, it's pretty clear I am not claiming 99% of them work with the = same port; nor am I suggesting we go back to using the same port again. = It was in the context of the debates we had back when the issue was = debated a couple IETF meetings ago, and I said as far as I knew they can = handle an *SDP offer* with it... and I then *immediately* said I didn't = argue it for long, because someone else stated they knew of a device = which had a problem, and that concerned me. Since most people generally = try not to contradict themselves in the span of a dozen words, I think = it's reasonable to assume I no longer believe all devices work. I mean = I may not be smart, but I'm not a complete idiot. (well... not generally = an idiot anyway) -hadriel From christer.holmberg@ericsson.com Thu Aug 8 11:45:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B1F11E8204 for ; Thu, 8 Aug 2013 11:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.032 X-Spam-Level: X-Spam-Status: No, score=-4.032 tagged_above=-999 required=5 tests=[AWL=-1.434, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-Jdp92Lln82 for ; Thu, 8 Aug 2013 11:45:29 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id F102711E8209 for ; Thu, 8 Aug 2013 11:45:27 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-d6-5203e7463cac Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 95.03.02664.647E3025; Thu, 8 Aug 2013 20:45:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 20:45:26 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLpoDN Date: Thu, 8 Aug 2013 18:45:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4225D0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se>, <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> In-Reply-To: <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4225D0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvra77c+Ygg4kfOS0+bfrEbDF1+WMW ByaPJUt+Mnl8fHqLJYApissmJTUnsyy1SN8ugSvj6t95LAWLXCpWrX/A0sD40qKLkZNDQsBE Yv6NW2wQtpjEhXvrgWwuDiGBo4wS75bdZYRwFjNKbGvezdLFyMHBJmAh0f1PG8QUEdCTOHqP E6SXWUBGYsbZRiaQsLBAmMTUlykgYRGBcInDH7YxQdhGEn+3L2IBsVkEVCSObj4EFucV8JXY 9PcfO4gtJFAv0b3gBSOIzSlgJ7G4bTHYaYxAp30/tYYJYpW4xK0n85kgThaQWLLnPDOELSrx 8vE/VoiafIlFx3dCzReUODnzCcsERpFZSNpnISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSM f4dYkMUXMLKvYuQoTi1Oyk03MtjECIycg1t+W+xgvPzX5hCjNAeLkjjvFr0zgUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoY1fyXGv5RrEgLP2YoNv3nxPvJ/mx3j8obdZ9nrXq7KsX1yN8L WX67SowZMl4o2d//ZLt58pdi00Jj/yhLW8HiFxffNy6Z9bNqveKCMk9xrp/a/bcN3Z7uLWxZ 8slh7fUV/ELeS+wqhH0zC5YtEb5jO20z545jes+lyhacOfPsjwhvxP1vVfKzlViKMxINtZiL ihMBzjRt1GoCAAA= Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:45:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4225D0ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When both Hadriel and Adam think pot zero in bundle-only m- lines is good, = I'll rest my case :) However, I do still think we need the second offer also for bundle-only m- = lines. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hadriel Kaplan [hadriel.kaplan@oracle.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: mmusic [mmusic@ietf.org] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? If I understand your question, you're asking why bundle-only m-lines would = use a port number of 0 in the offer, instead of using the same port number = as the regular bundle m-line they're going to transport-bundle with? I believe the rationale was basically argued about before, either in IETF 8= 6 Orlando or IETF 85 Atlanta. It gets back to the original debate about wh= ether a BUNDLE offer should use the same port numbers or different ones, fo= r bundle m-lines (what was called "BUNDLE vs. CRUNDLE" if I recall correctl= y). One WG participant argued against using the same port numbers for bundle li= nes. His argument was that since it was never described in an RFC, and he = knew of one implementation that didn't handle it well, that therefore we co= uldn't send an offer using the same port numbers until we found out if the = far-end supported BUNDLE or not. That's what drove the decision to use different port numbers even in regula= r bundle cases, afaik. Therefore, even for bundle-only lines, we can't use the same non-0 port num= ber for them, because the same theoretical issue will exist. Also, from a purely protocol perspective, it seems quite logical to me to u= se a port number of 0 for an m-line you literally don't want to use if the = far-end doesn't support BUNDLE - a port number of 0 effectively means "disa= bled" today, and that's basically what you want. What I don't think is rig= ht, is (1) having the far-end send an SDP answer back that sets a real port= number for those same "disabled" m-lines, and (2) not requiring another of= fer/answer exchange that then uses the correct (same) port numbers for the = previously-disabled m-lines. What I think should happen is the UAS should send an SDP answer using port= =3D0 for those same m-lines, and the UAC should then send a new offer with = those m-lines having the real port number of the bundle transport, and the = far-end should answer that in the same fashion. -hadriel On Aug 8, 2013, at 2:18 AM, Christer Holmberg wrote: > Hi, > > As has been indicated, bundle-only can only be used when one knows that t= he receiver, and possible intermediaries etc, support it. > > So, based on that assumption, my question is: why do we need port 0? Why = not assign the suggested bundle port to the bundle-only m- lines from the b= eginning? As the bundle port is anyway going to be used (even if the receiv= er does not want to use bundle), there is no need to reserve additional por= ts for bundle-only m- lines. > > Regards, > > Christer > > > > Sent from Windows using TouchDown (www.nitrodesk.com) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C4225D0ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When both Hadriel and Adam think pot zero in bun= dle-only m- lines is good, I'll rest my case :)
 
However, I do still think we need the second of= fer also for bundle-only m- lines.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: mmusic [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

If I understand your question, you're asking why bundle-only m-lines would = use a port number of 0 in the offer, instead of using the same port number = as the regular bundle m-line they're going to transport-bundle with?

I believe the rationale was basically argued about before, either in IETF 8= 6 Orlando or IETF 85 Atlanta.  It gets back to the original debate abo= ut whether a BUNDLE offer should use the same port numbers or different one= s, for bundle m-lines (what was called "BUNDLE vs. CRUNDLE" if I recall correctly).

One WG participant argued against using the same port numbers for bundle li= nes.  His argument was that since it was never described in an RFC, an= d he knew of one implementation that didn't handle it well, that therefore = we couldn't send an offer using the same port numbers until we found out if the far-end supported BUNDLE or not.
That's what drove the decision to use different port numbers even in regula= r bundle cases, afaik.

Therefore, even for bundle-only lines, we can't use the same non-0 port num= ber for them, because the same theoretical issue will exist.

Also, from a purely protocol perspective, it seems quite logical to me to u= se a port number of 0 for an m-line you literally don't want to use if the = far-end doesn't support BUNDLE - a port number of 0 effectively means "= ;disabled" today, and that's basically what you want.  What I don't think is right, is (1) having the far-en= d send an SDP answer back that sets a real port number for those same "= ;disabled" m-lines, and (2) not requiring another offer/answer exchang= e that then uses the correct (same) port numbers for the previously-disabled m-lines.

What I think should happen is the UAS should send an SDP answer using port= =3D0 for those same m-lines, and the UAC should then send a new offer with = those m-lines having the real port number of the bundle transport, and the = far-end should answer that in the same fashion.

-hadriel


On Aug 8, 2013, at 2:18 AM, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:

> Hi,
> 
> As has been indicated, bundle-only can only be used when one knows tha= t the receiver, and possible intermediaries etc, support it.
> 
> So, based on that assumption, my question is: why do we need port 0? W= hy not assign the suggested bundle port to the bundle-only m- lines from th= e beginning? As the bundle port is anyway going to be used (even if the rec= eiver does not want to use bundle), there is no need to reserve additional ports for bundle-only m- lines.
> 
> Regards,
> 
> Christer
> 
>
>
> Sent from Windows using TouchDown (www.nitrodesk.com)
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

 --_000_7594FB04B1934943A5C02806D1A2204B1C4225D0ESESSMB209erics_-- From kase.saylor@swri.org Thu Aug 8 11:50:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229FA21F9DBD for ; Thu, 8 Aug 2013 11:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jKOo2zDHVhb for ; Thu, 8 Aug 2013 11:50:09 -0700 (PDT) Received: from esg256-2.itc.swri.edu (esg256-2.itc.swri.edu [129.162.243.101]) by ietfa.amsl.com (Postfix) with ESMTP id 9341311E80DE for ; Thu, 8 Aug 2013 11:49:49 -0700 (PDT) Received: from exchmail.swri.org (casht256-1.adm.swri.edu [129.162.243.120]) by esg256-2.itc.swri.edu (8.14.5/8.14.5) with ESMTP id r78IoJqi025919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 8 Aug 2013 13:50:19 -0500 Received: from MBX260-1.adm.swri.edu ([169.254.2.13]) by CASHT256-1.adm.swri.edu ([129.162.243.120]) with mapi id 14.03.0146.000; Thu, 8 Aug 2013 13:49:48 -0500 From: "Saylor, Kase J." To: "mmusic@ietf.org" Thread-Topic: RTSP for data recorder design Thread-Index: AQHOlGgO7GiKkfk/MkW7mFNV3B7HCQ== Date: Thu, 8 Aug 2013 18:49:47 +0000 Message-ID: <862F245D-0795-48E1-8D5A-FEA6A0792D44@swri.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.162.109.47] Content-Type: multipart/alternative; boundary="_000_862F245D079548E18D5AFEA6A0792D44swriorg_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-08_06:2013-08-08, 2013-08-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_policy_notspam policy=inbound_policy score=0 kscore.is_bulkscore=2.27790253326532e-09 kscore.compositescore=0 circleOfTrustscore=0.432 compositescore=0.750652114695471 urlsuspect_oldscore=0.999790213242723 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=54 rbsscore=0.750652114695471 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=-40 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308080166 Subject: [MMUSIC] RTSP for data recorder design X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:50:16 -0000 --_000_862F245D079548E18D5AFEA6A0792D44swriorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To Whom it may concern, I am helping the US Army develop standards for a network recorder on US Arm= y vehicles. We like to use available standards when at all possible, and my= research seems to indicate that RTSP would be a great candidate standard. = I've been poring over the RTSP specification (along with the SDP standard) = and I have your douce code for LiveMedia. However, I still have a few quest= ions concerning the RTSP standard and its use for our particular need. It s= eems like there is plenty of examples on the Internet for the PLAY method, = but not much for RECORD. I really hope that someone may be able to provide = some insight that will get me moving in the right direction. On to the ques= tions! Our recorder requires the ability to "nominate" data streams for recording,= so I believe the correct RTSP method is ANNOUNCE. My first question is whe= n I was to add a stream using ANNOUNCE, if I use the same Session number fo= r multiple streams, does this basically create a presentation? For example: C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 3 Date: 7 Aug 2013 15:35:06 GMT Session: 47112344 Content-Type: application/sdp Content-Length: 332 v=3D0 o=3D- 2890844526 2890845468 IN IP4 192.168.0.123 s=3DThreat Stream 1 i=3DThreat stream from threat service on the Boomerang c=3DIN IP4 239.192.0.123/127 t=3D0 0 a=3Dunique_id:threat1 a=3Ddata_type:threat m=3Dmessage 12345 (some response back from server) C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 4 Date: 7 Aug 2013 15:35:07 GMT Session: 47112344 Content-Type: application/sdp Content-Length: 332 v=3D0 o=3D- 2890844527 2890845471 IN IP4 192.168.0.123 s=3DPosition Stream 1 i=3DPosition stream from position service c=3DIN IP4 239.192.0.124/127 t=3D0 0 a=3Dunique_id:pos1 a=3Ddata_type:position m=3Dmessage 12346 (some response back from server) Based upon these two announce messages, is it safe to assume that the follo= wing command would cause the recorder to start recording those two data str= eams (assuming the current date/time is 8/4/2013 1530 GMT)? C->S: RECORD rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP= /1.0 CSeq: 5 Content-Type: text/parameters Session: 47112344 Range: clock=3D20130804T153000Z- Furthermore, would the following command stop the recorder (assuming the cu= rrent date/time is 8/4/2013 1532 GMT)? I didn't see anywhere in the RFC for= stopping a recording. C->S: RECORD rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP= /1.0 CSeq: 6 Content-Type: text/parameters Session: 47112344 Range: clock=3D- 20130804T153200Z I apologize but I have at least one or two more questions ;-) After tearing= down a session, how would one go back and playback recorded data? From my = RECORD example I've assumed that providing a URI with a "path" based upon r= ecord start time, could be one way to mark recording events. Do you think t= his is an acceptable approach? Then the play command would something like: C->S: PLAY rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1= .0 CSeq: 6 Content-Type: text/parameters Session: 1234567 I suppose I could specify unique parameters and use the GET_PARAMETER metho= d to list the available recordings. Perhaps something like: C->S: SETUP rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 1 Transport: unicast;client_port=3D4588-4589 S->C: RTSP/1.0 200 OK CSeq: 1 Date: 5 Aug 2013 11:15:07 GMT Session: 1234567 Transport: unicast;client_port=3D4588-4589;server_port=3D6256-62= 57 C->S: GET_PARAMETER rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 7 Content-Type: text/parameters Session: 1234567 Content-Length: 15 list_recorded_data S->C: RTSP/1.0 200 OK CSeq: 7 Date: 5 Aug 2013 11:15:10 GMT Content-Length: 46 Content-Type: text/parameters list_recorded_data:20130804T153000Z,20130804T213000Z C->S: TEARDOWN rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 8 Session: 1234567 S->C: RTSP/1.0 200 OK CSeq: 8 Then we'd specify the proper way to interpret the response from the server = and open up a new RTSP session to playback the recorded data. For example: C->S: SETUP rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/= 1.0 CSeq: 1 Transport: multicast;client_port=3D4588-4589 S->C: RTSP/1.0 200 OK CSeq: 1 Date: 6 Aug 2013 11:15:07 GMT Session: 7654321 Transport: multicast;client_port=3D4588-4589;server_port=3D6256-= 6257 C->S: PLAY rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1= .0 CSeq: 2 Content-Type: text/parameters Session: 7654321 S->C: RTSP/1.0 200 OK CSeq: 2 Date: 6 Aug 2013 11:15:10 GMT Okay, last question, would the DESCRIBE method for rtsp://192.168.0.1/missi= on_recorder/20130804T153000Z be expected to describe the "streams" that wer= e recorded? In other words could the following be expected? C->S: DESCRIBE rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.= 0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg S->C: RTSP/1.0 200 OK CSeq: 312 Date: 7 Aug 2013 15:35:07 GMT Content-Type: application/sdp Content-Length: 332 v=3D0 o=3D- 2890844527 2890845471 IN IP4 192.168.0.123 s=3DPosition Stream 1 i=3DThreat stream from threat service on the Boomerang c=3DIN IP4 239.192.0.124/127 t=3D0 0 a=3Dunique_id:pos1 a=3Ddata_type:position m=3Dmessage 12346 s=3DPosition Stream 1 i=3DPosition stream from position service c=3DIN IP4 239.192.0.124/127 t=3D0 0 a=3Dunique_id:pos1 a=3Ddata_type:position m=3Dmessage 12346 I really have no idea how multiple streams would be described! Thanks in advance for any help! -- Regards, Kase Saylor Southwest Research Institute --_000_862F245D079548E18D5AFEA6A0792D44swriorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <58BAFAE5CFD3624FB4C52808F9C1EDE7@sw.pvt> Content-Transfer-Encoding: quoted-printable To Whom it may concern,

I am helping the US Army develop standards for a network recorder on U= S Army vehicles. We like to use available standards when at all possible, a= nd my research seems to indicate that RTSP would be a great candidate stand= ard. I've been poring over the RTSP specification (along with the SDP standard) and I have your douce code for= LiveMedia. However, I still have a few questions concerning the RTSP stand= ard and its use for our particular need. It seems like there is plenty of e= xamples on the Internet for the PLAY method, but not much for RECORD. I really hope that someone may be ab= le to provide some insight that will get me moving in the right direction. = On to the questions!

Our recorder requires the ability to "nominate" data streams= for recording, so I believe the correct RTSP method is ANNOUNCE. My first = question is when I was to add a stream using ANNOUNCE, if I use the same Se= ssion number for multiple streams, does this basically create a presentation? For example:

C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0
           CSeq: 3
           Date: 7 Aug 2013 15:35:06 GMT
           Session: 47112344
           Content-Type: application/sdp
           Content-Length: 332

           v=3D0
           o=3D- 2890844526 2890845468 IN IP4= 192.168.0.123
           s=3DThreat Stream 1
           i=3DThreat stream from threat serv= ice on the Boomerang
           c=3DIN IP4 239.192.0.123/127
           t=3D0 0
           a=3Dunique_id:threat1
  &= nbsp;a=3Ddata_type:threat
           m=3Dmessage 12345

(some response back from server)

C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0
           CSeq: 4
           Date: 7 Aug 2013 15:35:07 GMT
           Session: 47112344
           Content-Type: application/sdp
           Content-Length: 332

           v=3D0
           o=3D- 2890844527 2890845471 IN IP4= 192.168.0.123
           s=3DPosition Stream 1
           i=3DPosition stream from position = service
           c=3DIN IP4 239.192.0.124/127
           t=3D0 0
           a=3Dunique_id:pos1
  &= nbsp;a=3Ddata_type:position
           m=3Dmessage 12346
(some response back from server)

Based upon these two announce messages, is it safe to assume that the = following command would cause the recorder to start recording those two dat= a streams (assuming the current date/time is 8/4/2013 1530 GMT)?

     C->S: RECORD rtsp://192.168.0.1/mission_recorder/20130804T153000= Z RTSP/1.0
           CSeq: 5
           Content-Type: text/parameters
           Session: 47112344
  &= nbsp;Range: clock=3D20130804T153000Z-

Furthermore, would the following command stop the recorder (assum= ing the current date/time is 8/4/2013 1532 GMT)? I didn't see anywhere in t= he RFC for stopping a recording.

     C->S: RECORD rtsp://192.168.0.1/mission_recorder/20130804T153000= Z RTSP/1.0
           CSeq: 6
           Content-Type: text/parameters
           Session: 47112344
  &= nbsp;Range: clock=3D- 20130804T153200Z


I apologize but I have at least one or two more questions ;-) After te= aring down a session, how would one go back and playback recorded data? Fro= m my RECORD example I've assumed that providing a URI with a "path&quo= t; based upon record start time, could be one way to mark recording events. Do you think this is an acceptable appro= ach? Then the play command would something like:

           CSeq: 6
           Content-Type: text/parameters
           Session: 1234567

I suppose I could specify unique parameters and use the GET_PARAMETER = method to list the available recordings. Perhaps something like:

     C->S: SETUP rtsp://192.168.0.1/mission_recorder RTSP/1.0
           CSeq: 1
&nb= sp;  Transport: unicast;client_port=3D4588-4589

     S->C: RTSP/1.0 200 OK
           CSeq: 1
&nb= sp;  Date: 5 Aug 2013 11:15:07 GMT
           Session: 1234567
           Transport: unicast;client_port=3D4= 588-4589;server_port=3D6256-6257

     C->S: GET_PARAMETER rtsp://192.168.0.1/mission_recorder RTSP= /1.0
           CSeq: 7
           Content-Type: text/parameters
           Session: 1234567
           Content-Length: 15

&nb= sp;  list_recorded_data


     S->C: RTSP/1.0 200 OK
           CSeq: 7
&nb= sp;  Date: 5 Aug 2013 11:15:10 GMT
           Content-Length: 46
           Content-Type: text/parameters

           list_recorded_data:20130804T153000= Z,20130804T213000Z

     C->S: TEARDOWN rtsp://192.168.0.1/mission_recorder RTSP/1.0<= br>            CSeq: 8
  &= nbsp;Session: 1234567

     S->C: RTSP/1.0 200 OK
           CSeq: 8


Then we'd specify the proper way to interpret the response from the se= rver and open up a new RTSP session to playback the recorded data. For exam= ple:

     C->S: SETUP rtsp://192.168.0.1/mission_recorder/20130804T153000Z=  RTSP/1.0
           CSeq: 1
&nb= sp;  Transport: multicast;client_port=3D4588-4589

     S->C: RTSP/1.0 200 OK
           CSeq: 1
&nb= sp;  Date: 6 Aug 2013 11:15:07 GMT
           Session: 7654321
           Transport: multicast;client_port= =3D4588-4589;server_port=3D6256-6257

     C->S: PLAY rtsp://192.168.0.1/mission_recorder/20130= 804T153000Z RTSP/1.0
           CSeq: 2
           Content-Type: text/parameters
           Session: 7654321

     S->C: RTSP/1.0 200 OK
           CSeq: 2
&nb= sp;  Date: 6 Aug 2013 11:15:10 GMT

Okay, last question, would the DESCRIBE method for rtsp://192.168.0.1/missi= on_recorder/20130804T153000Z be expected to describe the "str= eams" that were recorded? In other words could the following be expected?

C->S: DESCRIBE rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
           CSeq: 312
           Accept: application/sdp, appl= ication/rtsl, application/mheg

S->C: RTSP/1.0 200 OK<= /span>
           CSeq: 312
           Date: 7 Aug 2013 15:35:07 GMT
           Content-Type: application/sdp
           Content-Length: 332

           v=3D0
           o=3D- 2890844527 2890845471 IN IP4= 192.168.0.123
           s=3DPosition Stream 1
           i=3DThreat stream from threat serv= ice on the Boomerang
           c=3DIN IP4 239.192.0.124/127
           t=3D0 0
           a=3Dunique_id:pos1
  &= nbsp;a=3Ddata_type:position
           m=3Dmessage 12346
&nb= sp;  s=3DPosition Stream 1
           i=3DPosition stream from posi= tion service
           c=3DIN IP4 239.192.0.124/127
           t=3D0 0
           a=3Dunique_id:pos1
  &= nbsp;a=3Ddata_type:position
           m=3Dmessage 12346

I really have no idea how multiple streams would be described!

Thanks in advance for any help!
--
Regards,

Kase Saylor
Southwest Research Institute

--_000_862F245D079548E18D5AFEA6A0792D44swriorg_-- From adam@nostrum.com Thu Aug 8 11:54:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7247A11E8210 for ; Thu, 8 Aug 2013 11:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhA3bsC2kH2P for ; Thu, 8 Aug 2013 11:53:56 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 18A4C11E8204 for ; Thu, 8 Aug 2013 11:53:38 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r78IrZEI094157 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 13:53:36 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5203E92A.4000509@nostrum.com> Date: Thu, 08 Aug 2013 13:53:30 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080100090603010806000606" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:54:01 -0000 This is a multi-part message in MIME format. --------------080100090603010806000606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/8/13 13:21, Hadriel Kaplan wrote: > On Aug 8, 2013, at 1:39 PM, Adam Roach wrote: > >> On 8/8/13 07:21, Hadriel Kaplan wrote: >>> What I think should happen is the UAS should send an SDP answer using port=0 for those same m-lines >> Why? You're proposing that we remove the mechanism for rejecting media streams. > Huh? You either misunderstood my email, or I'm not following your statement above. I don't believe I'm proposing we remove the mechanism of rejecting media streams. How/where/when did I propose that? You lost me. You're proposing that "the UAS should send an SDP answer using port=0 for [bundle-only] m-lines", even if it wants to accept those m-lines. In other words: * If the answerer wants to accept the m-lines, it does so by setting the port to 0 * If the answerer wants to reject the m-lines, it does so by setting the port to 0 I'm having a hard time understanding how the recipient of the answer distinguishes between port=0 and port=0. /a --------------080100090603010806000606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/8/13 13:21, Hadriel Kaplan wrote:
On Aug 8, 2013, at 1:39 PM, Adam Roach <adam@nostrum.com> wrote:


On 8/8/13 07:21, Hadriel Kaplan wrote:

What I think should happen is the UAS should send an SDP answer using port=0 for those same m-lines

Why? You're proposing that we remove the mechanism for rejecting media streams.

Huh?  You either misunderstood my email, or I'm not following your statement above.  I don't believe I'm proposing we remove the mechanism of rejecting media streams.  How/where/when did I propose that?  You lost me.

You're proposing that "the UAS should send an SDP answer using port=0 for [bundle-only] m-lines", even if it wants to accept those m-lines. In other words:

  • If the answerer wants to accept the m-lines, it does so by setting the port to 0
  • If the answerer wants to reject the m-lines, it does so by setting the port to 0


I'm having a hard time understanding how the recipient of the answer distinguishes between port=0 and port=0.

/a

--------------080100090603010806000606-- From partha@parthasarathi.co.in Thu Aug 8 11:56:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C496721F9E6D for ; Thu, 8 Aug 2013 11:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af7QNBltndqk for ; Thu, 8 Aug 2013 11:56:42 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9D80A21F8DDD for ; Thu, 8 Aug 2013 11:56:42 -0700 (PDT) Received: from userPC (unknown [122.166.142.138]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 7904C1908231; Thu, 8 Aug 2013 18:56:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1375988202; bh=tkSDsaBEe1UQSW1hMPUfF1J1cE5s27nQW/otgPTRPaw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=jh2n4yT44o0i2jErk/LjGJz2SAFbdL/o9QH6G5LB95pilpgV5tt0q1p9aGTikh+8U 1+SCm2pl/ZFfcNqS76D6NqcgQeaktz5JvcvPAWzajEStdCC7+ZODcfgHkRceYCRKCt NKzdsW2aEHzSeMaa9kfYWwQvKuRZvQ73O6gTBvRY= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Hadriel Kaplan'" References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> , <001601ce945c$ef7509d0$ce5f1d70$@co.in> <7594FB04B1934943A5C02806D1A2204B1C4224FF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4224FF@ESESSMB209.ericsson.se> Date: Fri, 9 Aug 2013 00:26:29 +0530 Message-ID: <003301ce9469$01dd2470$05976d50$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01CE9497.1B956070" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOlFzzTHFUEWnKxkeE8bnrSX+BlpmLntotgAAIhlA= Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0201.5203E9EA.0023, 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: 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 70.87.28.138 Cc: 'mmusic' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:56:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0034_01CE9497.1B956070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christer, Thanks for the clarification that it is a new requirement for BUNDLE. In case it should be allowed to send the BUNDLE in the first offer, the mechanism for understanding answerer support for BUNDLE has to be standardized as well like in Sec 9 of RFC 3264 (Indicating capabilities). Thanks Partha From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, August 08, 2013 11:49 PM To: Parthasarathi R; 'Hadriel Kaplan' Cc: 'mmusic' Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Hi, Some people suggested that it should be allowed to send the same ports in the first offer, IF it is known that the answerer supports BUNDLE. However, that is currently not described in the draft, and there were also objections to such approach. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Parthasarathi R [partha@parthasarathi.co.in] To: 'Hadriel Kaplan' [hadriel.kaplan@oracle.com]; Christer Holmberg [christer.holmberg@ericsson.com] CC: 'mmusic' [mmusic@ietf.org] Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Hi Hadriel/Christer, My understanding is that the initial offer with same port breaks more than one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft indicates one of the possible interop issue with existing mobile networks. So, I don't agree with Hadriel claim of 99% system works with same port. The current BUNDLE draft mechanism interop in the better way. In case it is known to offerer that answerer supports BUNDLE before sending offer, it is fine to send the same port in the offer using bundle-only attribute. I'm not seeing any issue there. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Thursday, August 08, 2013 7:46 PM > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle- > only m- lines? > > > On Aug 8, 2013, at 9:04 AM, Christer Holmberg > wrote: > > > Another advantage of using different port numbers is that it provides > a fallback in case the remote endpoint does not support, or does not > want to use BUNDLE. > > Yes, except as far as I can tell all devices (and even intermediaries) > handle an offer with the same port number just fine. But that's just a > personal observation, and dangerous to assume ALL of them handle it > fine; that's why I didn't argue for long that we should use the same > port number in the offer - because it concerned me that someone knew of > at least one implementation that didn't handle it well. (not that we > can truly accommodate ALL implementations anyway, but it's got to be a > heck of a lot higher than simple majority, and as close to 100% as we > can get) > > > > However, for bundle-only m- lines such fallback is not needed - they > are ONLY going to be used IF the remote endpoint chooses to use BUNDLE. > > ...and, based on the agreed scope, the Offerer KNOWS that the remote > endpoint supports BUNDLE, so the "one implementation that doesn't > handle it" will not be there :) > > For WebRTC sure - but we were talking about using BUNDLE generically. > Or at least that's what I thought you were asking about. If we're only > talking about using BUNDLE for WebRTC, then not only do you not need to > use a port=0, but you also don't need a second offer/answer, etc. > > > >> Also, from a purely protocol perspective, it seems quite logical to > me to use a port number of 0 for an m-line you literally don't want to > use if the far-end doesn't support > >> BUNDLE - a port number of 0 effectively means "disabled" today, and > that's basically what you want. > > > > Well, one could also say that it means "Here are some m- lines I > want to bundle, with this port, but only if you (the remote endpoint) > wants to use bundle." :) > > We can certainly change the semantics of SDP offers with port=0 for > WebRTC, but I think it would be really dangerous to change its > semantics for general use. > > > >> What I think should happen is the UAS should send an SDP answer > using port=0 for those same m-lines, and the UAC should then send a new > offer with those m-lines having the real port number of the bundle > transport, and the far-end should answer that in the same fashion. > > > > The problem is that the grouping framework does not allow, in SDP > Answers, usage of port=0 in grouped m- lines. It would require an > update of the RFC, and I think we want to avoid that. > > Considering the number of docs the Unified-Plan proposes to either > create, change, update or whatever... methinks having BUNDLE update the > grouping framework RFC is rather a minor nit. :) > > -hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_0034_01CE9497.1B956070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

Thanks for the clarification that it is a new requirement = for BUNDLE.

 

In case it should be allowed to send the BUNDLE in the = first offer, the mechanism for understanding answerer support for BUNDLE has = to be standardized as well like in Sec 9 of RFC 3264 (Indicating = capabilities).

 

Thanks

Partha

 

From:= Christer = Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Thursday, August 08, 2013 11:49 PM
To: Parthasarathi R; 'Hadriel Kaplan'
Cc: 'mmusic'
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

 

Hi,

 

Some people suggested that it should be allowed to send the = same ports in the first offer, IF it is known that the answerer supports = BUNDLE.

 

However, that is currently not described in the draft, and = there were also objections to such approach.

 

Regards,

 

Christer

 



Sent from Windows using TouchDown (www.nitrodesk.com)


-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: &apos;Hadriel Kaplan&apos; = [hadriel.kaplan@oracle.com]; Christer Holmberg [christer.holmberg@ericsson.com]
CC: &apos;mmusic&apos; [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

Hi Hadriel/Christer,

My understanding is that the initial offer with same port breaks more = than
one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft
indicates one of the possible interop issue with existing mobile = networks.
So, I don't agree with Hadriel claim of 99% system works with same port. = The
current BUNDLE draft mechanism interop in the better way.

In case it is known to offerer that answerer supports BUNDLE before = sending
offer, it is fine to send the same port in the offer using = bundle-only
attribute. I'm not seeing any issue there.

Thanks
Partha





> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Thursday, August 08, 2013 7:46 PM
> To: Christer Holmberg
> Cc: mmusic
> Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for = bundle-
> only m- lines?
>
>
> On Aug 8, 2013, at 9:04 AM, Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
>
> > Another advantage of using different port numbers is that it = provides
> a fallback in case the remote endpoint does not support, or does = not
> want to use BUNDLE.
>
> Yes, except as far as I can tell all devices (and even = intermediaries)
> handle an offer with the same port number just fine.  But = that's just a
> personal observation, and dangerous to assume ALL of them handle = it
> fine; that's why I didn't argue for long that we should use the = same
> port number in the offer - because it concerned me that someone = knew of
> at least one implementation that didn't handle it well. (not that = we
> can truly accommodate ALL implementations anyway, but it's got to = be a
> heck of a lot higher than simple majority, and as close to 100% as = we
> can get)
>
>
> > However, for bundle-only m- lines such fallback is not needed = - they
> are ONLY going to be used IF the remote endpoint chooses to use = BUNDLE.
> > ...and, based on the agreed scope, the Offerer KNOWS that the = remote
> endpoint supports BUNDLE, so the "one implementation that = doesn't
> handle it" will not be there :)
>
> For WebRTC sure - but we were talking about using BUNDLE = generically.
> Or at least that's what I thought you were asking about.  If = we're only
> talking about using BUNDLE for WebRTC, then not only do you not = need to
> use a port=3D0, but you also don't need a second offer/answer, = etc.
>
>
> >> Also, from a purely protocol perspective, it seems quite = logical to
> me to use a port number of 0 for an m-line you literally don't want = to
> use if the far-end doesn't support
> >> BUNDLE - a port number of 0 effectively means "disabled" today, and
> that's basically what you want.
> >
> > Well, one could also say that it means "Here are some m- lines  I
> want to bundle, with this port, but only if you (the remote = endpoint)
> wants to use bundle." :)
>
> We can certainly change the semantics of SDP offers with port=3D0 = for
> WebRTC, but I think it would be really dangerous to change its
> semantics for general use.
>
>
> >> What I think should happen is the UAS should send an SDP = answer
> using port=3D0 for those same m-lines, and the UAC should then send = a new
> offer with those m-lines having the real port number of the = bundle
> transport, and the far-end should answer that in the same = fashion.
> >
> > The problem is that the grouping framework does not allow, in = SDP
> Answers, usage of port=3D0 in grouped m- lines. It would require = an
> update of the RFC, and I think we want to avoid that.
>
> Considering the number of docs the Unified-Plan proposes to = either
> create, change, update or whatever... methinks having BUNDLE update = the
> grouping framework RFC is rather a minor nit. :)
>
> -hadriel
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.or= g/mailman/listinfo/mmusic

------=_NextPart_000_0034_01CE9497.1B956070-- From hadriel.kaplan@oracle.com Thu Aug 8 11:59:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4CC11E81F5 for ; Thu, 8 Aug 2013 11:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah-erY+5x6Jz for ; Thu, 8 Aug 2013 11:58:54 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFD911E8149 for ; Thu, 8 Aug 2013 11:58:54 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78IwnYF030342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 18:58:50 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78Iwm9a016245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 18:58:49 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78Iwm11024799; Thu, 8 Aug 2013 18:58:48 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 11:58:48 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> Date: Thu, 8 Aug 2013 14:58:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 18:59:00 -0000 On Aug 8, 2013, at 2:24 PM, Christer Holmberg = wrote: > Hi, > =20 > I agree with Adam on this one. Port zero is used in answers to reject = a stream, and I don't think we should change that.=20 Ahhh - now I think I understand what Adam's angst was. (maybe) You're = thinking that if the UAS' answer keeps the port=3D0, then that = contradicts using port=3D0 meaning it was rejected? Well, hate to tell y'all, but a port number of zero means that in the = offer TOO. =46rom RFC 3264: A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. What I'm proposing is we don't break/change that whatsoever. We have = the UAC send port=3D0 and "a=3Dbundle-only" in the Offer, and UAS send = an SDP answer with port=3D0 too, and ALSO "a=3Dbundle-only" for the = m-lines it is ok with using. Or "a=3Dbundle-only:use" or whatever. The = UAC sees that in the answer, and can send a new Offer with the bundle = port number, likewise the UAS in its answer. -hadriel From pkyzivat@alum.mit.edu Thu Aug 8 12:00:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5356811E823C for ; Thu, 8 Aug 2013 12:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iaibsMUBMLD for ; Thu, 8 Aug 2013 12:00:45 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id D281811E8225 for ; Thu, 8 Aug 2013 12:00:26 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id ADgH1m0041vXlb858K0Hvi; Thu, 08 Aug 2013 19:00:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id AK0G1m01C3ZTu2S3dK0G5h; Thu, 08 Aug 2013 19:00:17 +0000 Message-ID: <5203EABF.2080907@alum.mit.edu> Date: Thu, 08 Aug 2013 21:00:15 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <862F245D-0795-48E1-8D5A-FEA6A0792D44@swri.org> In-Reply-To: <862F245D-0795-48E1-8D5A-FEA6A0792D44@swri.org> 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=q20121106; t=1375988417; bh=yIiblsx0zUUsTAEzBIOwnCjl03MtpLEi1vFFt6712Jg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=L01lbBapLE9IKGsNFrafts1rnyS77vJvfAi3G1Dyw17rXlXt5PtXeIm0BiUnfE84b J6PRgbAbB49+RdLe+2zhnmMyMrcRdaYB6em8EgnFWAAVbPGhmAXHHqr369fRhEk6lJ GDP2JptErs395xYQx1ew+dBpklB3AkIQI6Vod8kaLDbV350ZPkuS8e2DRIidRJdHIQ IpxeDMaM/5RIUAoTJwYf61d/0UtcCQqtSR9TjGBZUvuIgnlyvDLWRDBEvkP+ZFBAkv kNUgButwH2XVljAssUJIjfQPb5CD1WsRuk6tltdW4XqyfD+JRwAAyugq8W+B4pUkbj TsUK4EvKzBD4A== Subject: Re: [MMUSIC] RTSP for data recorder design X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:00:50 -0000 Kase, Its hard to discern your exact requirements. But you should at least look at the work in progress by the siprec workgroup. You can find the relevant drafts at: http://datatracker.ietf.org/wg/siprec/ This may not be what you need, but is worth a look. Thanks, Paul On 8/8/13 8:49 PM, Saylor, Kase J. wrote: > To Whom it may concern, > > I am helping the US Army develop standards for a network recorder on US > Army vehicles. We like to use available standards when at all possible, > and my research seems to indicate that RTSP would be a great candidate > standard. I've been poring over the RTSP specification (along with the > SDP standard) and I have your douce code for LiveMedia. However, I still > have a few questions concerning the RTSP standard and its use for our > particular need. It seems like there is plenty of examples on the > Internet for the PLAY method, but not much for RECORD. I really hope > that someone may be able to provide some insight that will get me moving > in the right direction. On to the questions! > > Our recorder requires the ability to "nominate" data streams for > recording, so I believe the correct RTSP method is ANNOUNCE. My first > question is when I was to add a stream using ANNOUNCE, if I use the same > Session number for multiple streams, does this basically create a > presentation? For example: > > C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0 > CSeq: 3 > Date: 7 Aug 2013 15:35:06 GMT > Session: 47112344 > Content-Type: application/sdp > Content-Length: 332 > > v=0 > o=- 2890844526 2890845468 IN IP4 192.168.0.123 > s=Threat Stream 1 > i=Threat stream from threat service on the Boomerang > c=IN IP4 239.192.0.123/127 > t=0 0 > a=unique_id:threat1 > a=data_type:threat > m=message 12345 > > (some response back from server) > > C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0 > CSeq: 4 > Date: 7 Aug 2013 15:35:07 GMT > Session: 47112344 > Content-Type: application/sdp > Content-Length: 332 > > v=0 > o=- 2890844527 2890845471 IN IP4 192.168.0.123 > s=Position Stream 1 > i=Position stream from position service > c=IN IP4 239.192.0.124/127 > t=0 0 > a=unique_id:pos1 > a=data_type:position > m=message 12346 > (some response back from server) > > Based upon these two announce messages, is it safe to assume that the > following command would cause the recorder to start recording those two > data streams (assuming the current date/time is 8/4/2013 1530 GMT)? > > C->S: RECORD > rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 > CSeq: 5 > Content-Type: text/parameters > Session: 47112344 > Range: clock=20130804T153000Z- > > Furthermore, would the following command stop the recorder (assuming the > current date/time is 8/4/2013 1532 GMT)? I didn't see anywhere in the > RFC for stopping a recording. > > C->S: RECORD > rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 > CSeq: 6 > Content-Type: text/parameters > Session: 47112344 > Range: clock=- 20130804T153200Z > > > I apologize but I have at least one or two more questions ;-) After > tearing down a session, how would one go back and playback recorded > data? From my RECORD example I've assumed that providing a URI with a > "path" based upon record start time, could be one way to mark recording > events. Do you think this is an acceptable approach? Then the play > command would something like: > > C->S: PLAY > rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 > CSeq: 6 > Content-Type: text/parameters > Session: 1234567 > > I suppose I could specify unique parameters and use the GET_PARAMETER > method to list the available recordings. Perhaps something like: > > C->S: SETUP rtsp://192.168.0.1/mission_recorder RTSP/1.0 > CSeq: 1 > Transport: unicast;client_port=4588-4589 > > S->C: RTSP/1.0 200 OK > CSeq: 1 > Date: 5 Aug 2013 11:15:07 GMT > Session: 1234567 > Transport: unicast;client_port=4588-4589;server_port=6256-6257 > > C->S: GET_PARAMETER rtsp://192.168.0.1/mission_recorder RTSP/1.0 > CSeq: 7 > Content-Type: text/parameters > Session: 1234567 > Content-Length: 15 > > list_recorded_data > > > S->C: RTSP/1.0 200 OK > CSeq: 7 > Date: 5 Aug 2013 11:15:10 GMT > Content-Length: 46 > Content-Type: text/parameters > > list_recorded_data:20130804T153000Z,20130804T213000Z > > C->S: TEARDOWN rtsp://192.168.0.1/mission_recorder RTSP/1.0 > CSeq: 8 > Session: 1234567 > > S->C: RTSP/1.0 200 OK > CSeq: 8 > > > Then we'd specify the proper way to interpret the response from the > server and open up a new RTSP session to playback the recorded data. For > example: > > C->S: SETUP > rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 > CSeq: 1 > Transport: multicast;client_port=4588-4589 > > S->C: RTSP/1.0 200 OK > CSeq: 1 > Date: 6 Aug 2013 11:15:07 GMT > Session: 7654321 > Transport: multicast;client_port=4588-4589;server_port=6256-6257 > > C->S: PLAY > rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 > CSeq: 2 > Content-Type: text/parameters > Session: 7654321 > > S->C: RTSP/1.0 200 OK > CSeq: 2 > Date: 6 Aug 2013 11:15:10 GMT > > Okay, last question, would the DESCRIBE method for > rtsp://192.168.0.1/mission_recorder/20130804T153000Z be expected to > describe the "streams" that were recorded? In other words could the > following be expected? > > C->S: DESCRIBE rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 > CSeq: 312 > Accept: application/sdp, application/rtsl, application/mheg > > S->C: RTSP/1.0 200 OK > CSeq: 312 > Date: 7 Aug 2013 15:35:07 GMT > Content-Type: application/sdp > Content-Length: 332 > > v=0 > o=- 2890844527 2890845471 IN IP4 192.168.0.123 > s=Position Stream 1 > i=Threat stream from threat service on the Boomerang > c=IN IP4 239.192.0.124/127 > t=0 0 > a=unique_id:pos1 > a=data_type:position > m=message 12346 > s=Position Stream 1 > i=Position stream from position service > c=IN IP4 239.192.0.124/127 > t=0 0 > a=unique_id:pos1 > a=data_type:position > m=message 12346 > > I really have no idea how multiple streams would be described! > > Thanks in advance for any help! > -- > Regards, > > Kase Saylor > Southwest Research Institute > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From hadriel.kaplan@oracle.com Thu Aug 8 12:01:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB4411E8251 for ; Thu, 8 Aug 2013 12:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0McAnlsSiE6u for ; Thu, 8 Aug 2013 12:01:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED5911E8227 for ; Thu, 8 Aug 2013 12:00:42 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78J0f7w010000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 19:00:41 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78J0ekO012022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 19:00:40 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78J0eZJ021208; Thu, 8 Aug 2013 19:00:40 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 12:00:40 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5203E92A.4000509@nostrum.com> Date: Thu, 8 Aug 2013 15:00:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <5203E92A.4000509@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:01:12 -0000 On Aug 8, 2013, at 2:53 PM, Adam Roach wrote: > You're proposing that "the UAS should send an SDP answer using port=3D0 = for [bundle-only] m-lines", even if it wants to accept those m-lines. In = other words: >=20 > =95 If the answerer wants to accept the m-lines, it does so by = setting the port to 0 > =95 If the answerer wants to reject the m-lines, it does so by = setting the port to 0 >=20 > I'm having a hard time understanding how the recipient of the answer = distinguishes between port=3D0 and port=3D0. > /a Sorry, yeah I figured out what you meant a few minutes later after = reading Christer's email. I just responded to that in my reply to him. -hadriel p.s. isn't email a fun medium for real-time chat? :) From christer.holmberg@ericsson.com Thu Aug 8 12:01:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1A21F918C for ; Thu, 8 Aug 2013 12:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU0dtPzsonOt for ; Thu, 8 Aug 2013 12:01:17 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4E911E823C for ; Thu, 8 Aug 2013 12:01:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-65-5203eaebc0d3 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 20.11.05990.BEAE3025; Thu, 8 Aug 2013 21:01:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 21:00:59 +0200 From: Christer Holmberg To: Parthasarathi R , 'Hadriel Kaplan' Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlFzzTHFUEWnKxkeE8bnrSX+BlpmLntotgAAIhlCAAAMirQ== Date: Thu, 8 Aug 2013 19:00:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C42271C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> , <001601ce945c$ef7509d0$ce5f1d70$@co.in> <7594FB04B1934943A5C02806D1A2204B1C4224FF@ESESSMB209.ericsson.se>, <003301ce9469$01dd2470$05976d50$@co.in> In-Reply-To: <003301ce9469$01dd2470$05976d50$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C42271CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvre6bV8xBBksvsll82vSJ2WLq8scs FpM/9bE6MHssWfKTyePj01ssHh/mf2EPYI7isklJzcksSy3St0vgynh59StrwZ3JjBUdyy8z NzBuqu1i5OSQEDCROHNtCTOELSZx4d56ti5GLg4hgcOMEvtP9TFBOIsZJZZ8esvexcjBwSZg IdH9TxukQUQgQeLetYVsIDazgJzEhskvwWxhgTCJ53cOMkPUhEucf3OaCaRVRMBJYvYkZZAw i4CKRGPfTbASXgFfiUW31jJCrOpllpi+cD87SIIT6LhbNx6DzWQEOu77qTVMELvEJW49mc8E cbSAxJI956EeEJV4+fgfK0RNvsS6nilMEAsEJU7OfMIygVFkFpL2WUjKZiEpg4jrSCzY/YkN wtaWWLbwNTOMfebAYyZk8QWM7KsY2XMTM3PSy402MQIj6uCW36o7GO+cEznEKM3BoiTOu1nv TKCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxgjJNfa9vTujZwm9+/x7+i6rQ5cTjut3n9KQ Pvz97l/xOYunbi993vtUgH1DAWv6ShNO8T/Ll0YndqR3/urgWv+YS26XRUR7st50AdfDJx8p Nt7bt/2OK2/msZzdLNF88ewC4S6Tkt5tVal8/f335ZN16TPfX+GIPxCXP/VZLofnzKSuw3HL ViqxFGckGmoxFxUnAgAdRefVdgIAAA== Cc: 'mmusic' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:01:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C42271CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I don't think the answerer needs a feature tag to indicate BUNDLE support. = If it doesn't support BUNDLE, it won't include the BUNDLE group in the answ= er, nor will it assign a single port value to multiple m- lines. Or, did I misunderstand your issue? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Parthasarathi R [partha@parthasarathi.co.in] To: Christer Holmberg [christer.holmberg@ericsson.com]; 'Hadriel Kapla= n' [hadriel.kaplan@oracle.com] CC: 'mmusic' [mmusic@ietf.org] Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? Hi Christer, Thanks for the clarification that it is a new requirement for BUNDLE. In case it should be allowed to send the BUNDLE in the first offer, the mec= hanism for understanding answerer support for BUNDLE has to be standardized= as well like in Sec 9 of RFC 3264 (Indicating capabilities). Thanks Partha From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, August 08, 2013 11:49 PM To: Parthasarathi R; 'Hadriel Kaplan' Cc: 'mmusic' Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? Hi, Some people suggested that it should be allowed to send the same ports in t= he first offer, IF it is known that the answerer supports BUNDLE. However, that is currently not described in the draft, and there were also = objections to such approach. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Parthasarathi R [partha@parthasarathi.co.in] To: 'Hadriel Kaplan' [hadriel.kaplan@oracle.com]; Christer Holmbe= rg [christer.holmberg@ericsson.com] CC: 'mmusic' [mmusic@ietf.org] Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? Hi Hadriel/Christer, My understanding is that the initial offer with same port breaks more than one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft indicates one of the possible interop issue with existing mobile networks. So, I don't agree with Hadriel claim of 99% system works with same port. Th= e current BUNDLE draft mechanism interop in the better way. In case it is known to offerer that answerer supports BUNDLE before sending offer, it is fine to send the same port in the offer using bundle-only attribute. I'm not seeing any issue there. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Thursday, August 08, 2013 7:46 PM > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle- > only m- lines? > > > On Aug 8, 2013, at 9:04 AM, Christer Holmberg > wrote: > > > Another advantage of using different port numbers is that it provides > a fallback in case the remote endpoint does not support, or does not > want to use BUNDLE. > > Yes, except as far as I can tell all devices (and even intermediaries) > handle an offer with the same port number just fine. But that's just a > personal observation, and dangerous to assume ALL of them handle it > fine; that's why I didn't argue for long that we should use the same > port number in the offer - because it concerned me that someone knew of > at least one implementation that didn't handle it well. (not that we > can truly accommodate ALL implementations anyway, but it's got to be a > heck of a lot higher than simple majority, and as close to 100% as we > can get) > > > > However, for bundle-only m- lines such fallback is not needed - they > are ONLY going to be used IF the remote endpoint chooses to use BUNDLE. > > ...and, based on the agreed scope, the Offerer KNOWS that the remote > endpoint supports BUNDLE, so the "one implementation that doesn't > handle it" will not be there :) > > For WebRTC sure - but we were talking about using BUNDLE generically. > Or at least that's what I thought you were asking about. If we're only > talking about using BUNDLE for WebRTC, then not only do you not need to > use a port=3D0, but you also don't need a second offer/answer, etc. > > > >> Also, from a purely protocol perspective, it seems quite logical to > me to use a port number of 0 for an m-line you literally don't want to > use if the far-end doesn't support > >> BUNDLE - a port number of 0 effectively means "disabled" today, and > that's basically what you want. > > > > Well, one could also say that it means "Here are some m- lines I > want to bundle, with this port, but only if you (the remote endpoint) > wants to use bundle." :) > > We can certainly change the semantics of SDP offers with port=3D0 for > WebRTC, but I think it would be really dangerous to change its > semantics for general use. > > > >> What I think should happen is the UAS should send an SDP answer > using port=3D0 for those same m-lines, and the UAC should then send a new > offer with those m-lines having the real port number of the bundle > transport, and the far-end should answer that in the same fashion. > > > > The problem is that the grouping framework does not allow, in SDP > Answers, usage of port=3D0 in grouped m- lines. It would require an > update of the RFC, and I think we want to avoid that. > > Considering the number of docs the Unified-Plan proposes to either > create, change, update or whatever... methinks having BUNDLE update the > grouping framework RFC is rather a minor nit. :) > > -hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C42271CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I don't think the answerer needs a feature tag = to indicate BUNDLE support. If it doesn't support BUNDLE, it won't include = the BUNDLE group in the answer, nor will it assign a single port value to m= ultiple m- lines.
 
Or, did I misunderstand your issue?
 
Regards,
 
Christer 
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: Christer Holmberg [christer.holmberg@ericsson.com]; &apos;Ha= driel Kaplan&apos; [hadriel.kaplan@oracle.com]
CC: &apos;mmusic&apos; [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

Hi Christer,

 

Thanks for the clarific= ation that it is a new requirement for BUNDLE.

 

In case it should be al= lowed to send the BUNDLE in the first offer, the mechanism for understandin= g answerer support for BUNDLE has to be standardized as well like in Sec 9 of RFC 3264 (Indicating capabilities).

 

Thanks

Partha

 

From: Christ= er Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Thursday, August 08, 2013 11:49 PM
To: Parthasarathi R; 'Hadriel Kaplan'
Cc: 'mmusic'
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

 

Hi,

 

Some people suggested tha= t it should be allowed to send the same ports in the first offer, IF it is = known that the answerer supports BUNDLE.

 

However, that is currentl= y not described in the draft, and there were also objections to such approa= ch.

 

Regards,

 

Christer

 



Sent from Windows using T= ouchDown (www.nitrodesk.com)


-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: &apos;Hadriel Kaplan&apos; [hadriel.kaplan@oracle.com]; = Christer Holmberg [christer.holmberg@ericsson.com]
CC: &apos;mmusic&apos; [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

Hi Hadriel/Christer,

My understanding is that the initial offer with same port breaks more than<= br> one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft
indicates one of the possible interop issue with existing mobile networks.<= br> So, I don't agree with Hadriel claim of 99% system works with same port. Th= e
current BUNDLE draft mechanism interop in the better way.

In case it is known to offerer that answerer supports BUNDLE before sending=
offer, it is fine to send the same port in the offer using bundle-only
attribute. I'm not seeing any issue there.

Thanks
Partha





> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Thursday, August 08, 2013 7:46 PM
> To: Christer Holmberg
> Cc: mmusic
> Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-=
> only m- lines?
>
>
> On Aug 8, 2013, at 9:04 AM, Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
>
> > Another advantage of using different port numbers is that it prov= ides
> a fallback in case the remote endpoint does not support, or does not > want to use BUNDLE.
>
> Yes, except as far as I can tell all devices (and even intermediaries)=
> handle an offer with the same port number just fine.  But that's = just a
> personal observation, and dangerous to assume ALL of them handle it > fine; that's why I didn't argue for long that we should use the same > port number in the offer - because it concerned me that someone knew o= f
> at least one implementation that didn't handle it well. (not that we > can truly accommodate ALL implementations anyway, but it's got to be a=
> heck of a lot higher than simple majority, and as close to 100% as we<= br> > can get)
>
>
> > However, for bundle-only m- lines such fallback is not needed - t= hey
> are ONLY going to be used IF the remote endpoint chooses to use BUNDLE= .
> > ...and, based on the agreed scope, the Offerer KNOWS that the rem= ote
> endpoint supports BUNDLE, so the "one implementation that doesn't=
> handle it" will not be there :)
>
> For WebRTC sure - but we were talking about using BUNDLE generically.<= br> > Or at least that's what I thought you were asking about.  If we'r= e only
> talking about using BUNDLE for WebRTC, then not only do you not need t= o
> use a port=3D0, but you also don't need a second offer/answer, etc. >
>
> >> Also, from a purely protocol perspective, it seems quite logi= cal to
> me to use a port number of 0 for an m-line you literally don't want to=
> use if the far-end doesn't support
> >> BUNDLE - a port number of 0 effectively means "disabled&= quot; today, and
> that's basically what you want.
> >
> > Well, one could also say that it means "Here are some m- lin= es  I
> want to bundle, with this port, but only if you (the remote endpoint)<= br> > wants to use bundle." :)
>
> We can certainly change the semantics of SDP offers with port=3D0 for<= br> > WebRTC, but I think it would be really dangerous to change its
> semantics for general use.
>
>
> >> What I think should happen is the UAS should send an SDP answ= er
> using port=3D0 for those same m-lines, and the UAC should then send a = new
> offer with those m-lines having the real port number of the bundle
> transport, and the far-end should answer that in the same fashion.
> >
> > The problem is that the grouping framework does not allow, in SDP=
> Answers, usage of port=3D0 in grouped m- lines. It would require an > update of the RFC, and I think we want to avoid that.
>
> Considering the number of docs the Unified-Plan proposes to either
> create, change, update or whatever... methinks having BUNDLE update th= e
> grouping framework RFC is rather a minor nit. :)
>
> -hadriel
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

--_000_7594FB04B1934943A5C02806D1A2204B1C42271CESESSMB209erics_-- From adam@nostrum.com Thu Aug 8 12:03:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF50111E81F9 for ; Thu, 8 Aug 2013 12:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e58e0n+clwXv for ; Thu, 8 Aug 2013 12:03:40 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4456921F92B8 for ; Thu, 8 Aug 2013 12:03:10 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r78J35Oi095164 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 14:03:06 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5203EB64.70605@nostrum.com> Date: Thu, 08 Aug 2013 14:03:00 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> In-Reply-To: <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:03:41 -0000 On 8/8/13 13:58, Hadriel Kaplan wrote: > What I'm proposing is we don't break/change that whatsoever. We have > the UAC send port=0 and "a=bundle-only" in the Offer, and UAS send an > SDP answer with port=0 too, and ALSO "a=bundle-only" for the m-lines > it is ok with using. Or "a=bundle-only:use" or whatever. But why? You're introducing additional mechanism (and hence complexity) for no technical advantage. /a From christer.holmberg@ericsson.com Thu Aug 8 12:09:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26A321E8056 for ; Thu, 8 Aug 2013 12:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.02 X-Spam-Level: X-Spam-Status: No, score=-4.02 tagged_above=-999 required=5 tests=[AWL=-1.422, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYdVuXOB8qyA for ; Thu, 8 Aug 2013 12:09:24 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0895111E81F5 for ; Thu, 8 Aug 2013 12:09:22 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-60-5203ece1e5ea Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C7.24.02664.1ECE3025; Thu, 8 Aug 2013 21:09:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 21:09:21 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAJHpN Date: Thu, 8 Aug 2013 19:09:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422753@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se>, <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> In-Reply-To: <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C422753ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre7DN8xBBqeu21js+buI3eLTpk/M FlOXP2ZxYPZYsuQnk8esnU9YPD4+vcUSwBzFZZOSmpNZllqkb5fAlTHv9iL2gnm6FVfb/zA3 MLaqdTFyckgImEg8WveOHcIWk7hwbz1bFyMXh5DAUUaJv/cfsEI4ixklOrYfYuxi5OBgE7CQ 6P6nDWKKCOhJHL3HCdLLLGAtsfDKFLAKYYEwiakvU0DCIgLhEoc/bGOCsN0kVlxZxAJiswio SLxf8YgVxOYV8JX4uuEyM4gtJDCNSaL/ZQyIzSlgJ3Fz52mwOCPQad9PrWGCWCUucevJfCaI kwUkluw5zwxhi0q8fPyPFaImX2LVuucsEPMFJU7OfMIygVFkFpL2WUjKZiEpg4jrSdyYOoUN wtaWWLbwNTOErSsx498hFmTxBYzsqxg5ilOLk3LTjQw2MQKj6eCW3xY7GC//tTnEKM3BoiTO u0XvTKCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxm4zfWUz7vlX5y2/aZ9c8cqx9Pahgp6v HQV/ZDnzblonH32g2dTsEvmiNXGxcfZa1sNOC/5ySa76l3Bh8QLmXxoeJWUCbw7MEmF747Xw iOZEi7tHk7LZbVMvLo31WJz+1G5d6W/Wsx/efyv7wfjY5/2cjC8i5xSW/J1lH9/02Pvw06nL XGeZMCixFGckGmoxFxUnAgCCqIzFdAIAAA== Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:09:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C422753ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, So, you suggest that port zero means reject, and port-zero + a=3Dbundle-onl= y means something else - in Offers AND Answers? Even if that might be doable, my main issue is still that since the Answere= r assign the bundle port to all other bundled m- lines, it should also assi= gn it to the bundle-only m- lines. Also, we need to study whether we need to indicate bundle-only in answers t= o begin with, as the purpose of the indicator only applies to offers... Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hadriel Kaplan [hadriel.kaplan@oracle.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Adam Roach [adam@nostrum.com]; mmusic [mmusic@ietf.org] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On Aug 8, 2013, at 2:24 PM, Christer Holmberg wrote: > Hi, > > I agree with Adam on this one. Port zero is used in answers to reject a s= tream, and I don't think we should change that. Ahhh - now I think I understand what Adam's angst was. (maybe) You're thin= king that if the UAS' answer keeps the port=3D0, then that contradicts usin= g port=3D0 meaning it was rejected? Well, hate to tell y'all, but a port number of zero means that in the offer= TOO. >From RFC 3264: A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. What I'm proposing is we don't break/change that whatsoever. We have the U= AC send port=3D0 and "a=3Dbundle-only" in the Offer, and UAS send an SDP an= swer with port=3D0 too, and ALSO "a=3Dbundle-only" for the m-lines it is ok= with using. Or "a=3Dbundle-only:use" or whatever. The UAC sees that in t= he answer, and can send a new Offer with the bundle port number, likewise t= he UAS in its answer. -hadriel --_000_7594FB04B1934943A5C02806D1A2204B1C422753ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
So, you suggest that port zero means reject, an= d port-zero + a=3Dbundle-only means something else - in Offers AND Answ= ers?
 
Even if that might be doable, my main issue is = still that since the Answerer assign the bundle port to all other bundled m= - lines, it should also assign it to the bundle-only m- lines.
 
Also, we need to study whether we need to indic= ate bundle-only in answers to begin with, as the purpose of the indicator o= nly applies to offers...
 
Regards,
 
Christer
 
 
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: Adam Roach [adam@nostrum.com]; mmusic [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

On Aug 8, 2013, at 2:24 PM, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:

> Hi,
> 
> I agree with Adam on this one. Port zero is used in answers to reject = a stream, and I don't think we should change that.

Ahhh - now I think I understand what Adam's angst was. (maybe)  You're= thinking that if the UAS' answer keeps the port=3D0, then that contradicts= using port=3D0 meaning it was rejected?

Well, hate to tell y'all, but a port number of zero means that in the offer= TOO.

>From RFC 3264:
   A port number of zero in the offer indicates that the
   stream is offered but MUST NOT be used.

What I'm proposing is we don't break/change that whatsoever.  We have = the UAC send port=3D0 and "a=3Dbundle-only" in the Offer, and UAS= send an SDP answer with port=3D0 too, and ALSO "a=3Dbundle-only"= for the m-lines it is ok with using.  Or "a=3Dbundle-only:use&qu= ot; or whatever.  The UAC sees that in the answer, and can send a new Offer = with the bundle port number, likewise the UAS in its answer.

-hadriel

 --_000_7594FB04B1934943A5C02806D1A2204B1C422753ESESSMB209erics_-- From hadriel.kaplan@oracle.com Thu Aug 8 12:11:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FAF21F9C76 for ; Thu, 8 Aug 2013 12:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGrLBkaMaD1o for ; Thu, 8 Aug 2013 12:11:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A7A4021F9BF1 for ; Thu, 8 Aug 2013 12:11:35 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78JBVSv021063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 19:11:31 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78JBUiH009151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 19:11:30 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78JBUJa023596; Thu, 8 Aug 2013 19:11:30 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 12:11:29 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5203EB64.70605@nostrum.com> Date: Thu, 8 Aug 2013 15:11:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:11:42 -0000 On Aug 8, 2013, at 3:03 PM, Adam Roach wrote: > On 8/8/13 13:58, Hadriel Kaplan wrote: >> What I'm proposing is we don't break/change that whatsoever. We have = the UAC send port=3D0 and "a=3Dbundle-only" in the Offer, and UAS send = an SDP answer with port=3D0 too, and ALSO "a=3Dbundle-only" for the = m-lines it is ok with using. Or "a=3Dbundle-only:use" or whatever. >=20 > But why? You're introducing additional mechanism (and hence = complexity) for no technical advantage. 1) To avoid confusing the things that go bump in the night. 2) To avoid updating RFC 3264. 3) Because it's the right thing to do. If I send a new SDP Offer 10 = minutes later during the session, and I set an existing m-line to port 0 = in that Offer, does it mean I want to disable the media, or restart = bundling, or what? We're talking about SDP here, and a port=3D0 means = "disabled", or "unwanted", or whatever word you want to use. It means = that in an offer, and it means that in an answer. It doesn't matter = when you got the offer, or when you got the answer. It's stateless. I = don't see how that adds complexity - seems simpler to me. -hadriel From hadriel.kaplan@oracle.com Thu Aug 8 12:32:16 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC281F0D5C for ; Thu, 8 Aug 2013 12:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IbBCsHgEJT4 for ; Thu, 8 Aug 2013 12:32:09 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 93C5F21E805A for ; Thu, 8 Aug 2013 12:32:09 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78JW4LU029615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 19:32:04 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78JW3KZ024555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 19:32:03 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78JW2Rq027079; Thu, 8 Aug 2013 19:32:02 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 12:32:02 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422753@ESESSMB209.ericsson.se> Date: Thu, 8 Aug 2013 15:32:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se>, <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422753@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:32:16 -0000 General question: Are we talking about this for WebRTC only, or for = general SDP applications? I'm worried I'm not in the same context as = you guys. I'm talking about this stuff in terms of using it for SIP. = If you're only talking about it for WebRTC, please let me know. On Aug 8, 2013, at 3:09 PM, Christer Holmberg = wrote: > So, you suggest that port zero means reject, and port-zero + = a=3Dbundle-only means something else - in Offers AND Answers? I'm suggesting that if we want to use this for SIP, instead of only = WebRTC, that RFC 3264 be followed: A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness, since the answer can contain a zero port indicating a rejected stream (Section 6). Furthermore, existing streams can be terminated by setting the port to zero (Section 8). In general, a port number of zero indicates that the media stream is not wanted. BUNDLE would have an attribute it defines of "a=3Dbundle-only" or = whatever, which has a defined semantic of "I am willing to use this = media, but only in a BUNDLE RFC multiplex transport thingamajig". It = has that meaning in SDP, period... what does it matter if it's in an = offer or answer? Why have different meanings for it? (I'm not following = you on the concern - I must be missing something) > Even if that might be doable, my main issue is still that since the = Answerer assign the bundle port to all other bundled m- lines, it should = also assign it to the bundle-only m- lines. If we're talking about using this for SIP, I think the safest thing to = do is have both the initial Offer and initial Answer keep to 3264, and = have the Answer use port=3D0 for any m-lines it received as port=3D0 in = an Offer. Obviously it's going to take another O/A round, and I hate = that... but that's life. (...for SIP - we can optimize WebRTC if we = think its necessary) -hadriel From partha@parthasarathi.co.in Thu Aug 8 12:32:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0E821E8089 for ; Thu, 8 Aug 2013 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvNq0Xj0mQl9 for ; Thu, 8 Aug 2013 12:32:17 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8977321E8064 for ; Thu, 8 Aug 2013 12:32:17 -0700 (PDT) Received: from userPC (unknown [122.166.142.138]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 1FFA88684DB; Thu, 8 Aug 2013 19:32:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1375990336; bh=uE2kgr/xIoQC6OurBZ+lZzwro6idLLVflrpfPQ+cC0k=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ZD2oalpMI2rhLtZbWoX2JEmTpkeuVzs9MolC7ej3TXCuiiNxzn2vNRRuEbSJjfiKp rB15mKIuX/7THcH240RFETn+Bdn2eCfvUbpWCqdd3ko6hy628fzNHj0IGs0UBIeGR0 O75gaX0PlhRBwhjIaqi2TBcI74zPvDFsyqDYr0Bs= From: "Parthasarathi R" To: "'Christer Holmberg'" , "'Hadriel Kaplan'" References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C422263@ESESSMB209.ericsson.se> , <001601ce945c$ef7509d0$ce5f1d70$@co.in> <7594FB04B1934943A5C02806D1A2204B1C4224FF@ESESSMB209.ericsson.se>, <003301ce9469$01dd2470$05976d50$@co.in> <7594FB04B1934943A5C02806D1A2204B1C42271C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C42271C@ESESSMB209.ericsson.se> Date: Fri, 9 Aug 2013 01:02:04 +0530 Message-ID: <005d01ce946d$fa177330$ee465990$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CE949C.13CFAF30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOlFzzTHFUEWnKxkeE8bnrSX+BlpmLntotgAAIhlCAAAMirYAAA+1Q Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0201.5203F240.00E1, 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: 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 70.87.28.153 Cc: 'mmusic' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:32:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005E_01CE949C.13CFAF30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christer, Some people suggested that it should be allowed to send the same ports in the first offer, IF it is known that the answerer supports BUNDLE. My question is how offerer will get to know about answerer capabilities in the first offer? In case it should be allowed to send the BUNDLE in the first offer, the mechanism for understanding answerer's BUNDLE capabilities has to be standardized as well like in Sec 9 of RFC 3264 (Indicating capabilities). Let us discuss separately how the answerer will indicate BUNDLE capabilities (BUNDLE group attributes missing,"bundle-only" attribute) which is not a concern as of now. Hope this clarifies. Thanks Partha From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, August 09, 2013 12:31 AM To: Parthasarathi R; 'Hadriel Kaplan' Cc: 'mmusic' Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Hi, I don't think the answerer needs a feature tag to indicate BUNDLE support. If it doesn't support BUNDLE, it won't include the BUNDLE group in the answer, nor will it assign a single port value to multiple m- lines. Or, did I misunderstand your issue? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Parthasarathi R [partha@parthasarathi.co.in] To: Christer Holmberg [christer.holmberg@ericsson.com]; 'Hadriel Kaplan' [hadriel.kaplan@oracle.com] CC: 'mmusic' [mmusic@ietf.org] Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Hi Christer, Thanks for the clarification that it is a new requirement for BUNDLE. In case it should be allowed to send the BUNDLE in the first offer, the mechanism for understanding answerer support for BUNDLE has to be standardized as well like in Sec 9 of RFC 3264 (Indicating capabilities). Thanks Partha From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, August 08, 2013 11:49 PM To: Parthasarathi R; 'Hadriel Kaplan' Cc: 'mmusic' Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Hi, Some people suggested that it should be allowed to send the same ports in the first offer, IF it is known that the answerer supports BUNDLE. However, that is currently not described in the draft, and there were also objections to such approach. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Parthasarathi R [partha@parthasarathi.co.in] To: 'Hadriel Kaplan' [hadriel.kaplan@oracle.com]; Christer Holmberg [christer.holmberg@ericsson.com] CC: 'mmusic' [mmusic@ietf.org] Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Hi Hadriel/Christer, My understanding is that the initial offer with same port breaks more than one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft indicates one of the possible interop issue with existing mobile networks. So, I don't agree with Hadriel claim of 99% system works with same port. The current BUNDLE draft mechanism interop in the better way. In case it is known to offerer that answerer supports BUNDLE before sending offer, it is fine to send the same port in the offer using bundle-only attribute. I'm not seeing any issue there. Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Thursday, August 08, 2013 7:46 PM > To: Christer Holmberg > Cc: mmusic > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle- > only m- lines? > > > On Aug 8, 2013, at 9:04 AM, Christer Holmberg > wrote: > > > Another advantage of using different port numbers is that it provides > a fallback in case the remote endpoint does not support, or does not > want to use BUNDLE. > > Yes, except as far as I can tell all devices (and even intermediaries) > handle an offer with the same port number just fine. But that's just a > personal observation, and dangerous to assume ALL of them handle it > fine; that's why I didn't argue for long that we should use the same > port number in the offer - because it concerned me that someone knew of > at least one implementation that didn't handle it well. (not that we > can truly accommodate ALL implementations anyway, but it's got to be a > heck of a lot higher than simple majority, and as close to 100% as we > can get) > > > > However, for bundle-only m- lines such fallback is not needed - they > are ONLY going to be used IF the remote endpoint chooses to use BUNDLE. > > ...and, based on the agreed scope, the Offerer KNOWS that the remote > endpoint supports BUNDLE, so the "one implementation that doesn't > handle it" will not be there :) > > For WebRTC sure - but we were talking about using BUNDLE generically. > Or at least that's what I thought you were asking about. If we're only > talking about using BUNDLE for WebRTC, then not only do you not need to > use a port=0, but you also don't need a second offer/answer, etc. > > > >> Also, from a purely protocol perspective, it seems quite logical to > me to use a port number of 0 for an m-line you literally don't want to > use if the far-end doesn't support > >> BUNDLE - a port number of 0 effectively means "disabled" today, and > that's basically what you want. > > > > Well, one could also say that it means "Here are some m- lines I > want to bundle, with this port, but only if you (the remote endpoint) > wants to use bundle." :) > > We can certainly change the semantics of SDP offers with port=0 for > WebRTC, but I think it would be really dangerous to change its > semantics for general use. > > > >> What I think should happen is the UAS should send an SDP answer > using port=0 for those same m-lines, and the UAC should then send a new > offer with those m-lines having the real port number of the bundle > transport, and the far-end should answer that in the same fashion. > > > > The problem is that the grouping framework does not allow, in SDP > Answers, usage of port=0 in grouped m- lines. It would require an > update of the RFC, and I think we want to avoid that. > > Considering the number of docs the Unified-Plan proposes to either > create, change, update or whatever... methinks having BUNDLE update the > grouping framework RFC is rather a minor nit. :) > > -hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic ------=_NextPart_000_005E_01CE949C.13CFAF30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

<snip>

Some people suggested that it should be allowed to send the = same ports in the first offer, IF it is known that the answerer supports = BUNDLE.

</snip>

 

My question is how offerer will get to know about = answerer capabilities in the first offer?  In case it should be = allowed to send the BUNDLE in the first offer, the mechanism for understanding = answerer’s BUNDLE capabilities has to be standardized as well like in Sec 9 of RFC = 3264 (Indicating capabilities). Let us discuss separately how the answerer = will indicate BUNDLE capabilities (BUNDLE group attributes = missing,”bundle-only” attribute) which is not a concern as of now. Hope this = clarifies.

 

Thanks

Partha

 

From:= Christer = Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Friday, August 09, 2013 12:31 AM
To: Parthasarathi R; 'Hadriel Kaplan'
Cc: 'mmusic'
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

 

Hi,

 

I don't think the answerer needs a feature tag to indicate BUNDLE support.

 

 If it doesn't support BUNDLE, it won't include the BUNDLE group in the answer, = nor will it assign a single port value to multiple m- = lines.

 

Or, did I misunderstand your issue?

 

Regards,

 

Christer 

 



Sent from Windows using TouchDown (www.nitrodesk.com)


-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: Christer Holmberg [christer.holmberg@ericsson.com]; = &apos;Hadriel Kaplan&apos; [hadriel.kaplan@oracle.com]
CC: &apos;mmusic&apos; [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

Hi Christer,

 

Thanks for the clarification that it is a new requirement = for BUNDLE.

 

In case it should be allowed to send the BUNDLE in the = first offer, the mechanism for understanding answerer support for BUNDLE has = to be standardized as well like in Sec 9 of RFC 3264 (Indicating = capabilities).

 

Thanks

Partha

 

From:= Christer = Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Thursday, August 08, 2013 11:49 PM
To: Parthasarathi R; 'Hadriel Kaplan'
Cc: 'mmusic'
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

 

Hi,

 

Some people suggested that it should be allowed to send the = same ports in the first offer, IF it is known that the answerer supports = BUNDLE.

 

However, that is currently not described in the draft, and = there were also objections to such approach.

 

Regards,

 

Christer

 



Sent from Windows using TouchDown (www.nitrodesk.com)


-----Original Message-----
From: Parthasarathi R [partha@parthasarathi.co.in]
To: &apos;Hadriel Kaplan&apos; = [hadriel.kaplan@oracle.com]; Christer Holmberg [christer.holmberg@ericsson.com]
CC: &apos;mmusic&apos; [mmusic@ietf.org]
Subject: RE: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

Hi Hadriel/Christer,

My understanding is that the initial offer with same port breaks more = than
one existing system. Sec 4.1.1 of draft-reddy-rtcweb-mobile-03 draft
indicates one of the possible interop issue with existing mobile = networks.
So, I don't agree with Hadriel claim of 99% system works with same port. = The
current BUNDLE draft mechanism interop in the better way.

In case it is known to offerer that answerer supports BUNDLE before = sending
offer, it is fine to send the same port in the offer using = bundle-only
attribute. I'm not seeing any issue there.

Thanks
Partha





> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Thursday, August 08, 2013 7:46 PM
> To: Christer Holmberg
> Cc: mmusic
> Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for = bundle-
> only m- lines?
>
>
> On Aug 8, 2013, at 9:04 AM, Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
>
> > Another advantage of using different port numbers is that it = provides
> a fallback in case the remote endpoint does not support, or does = not
> want to use BUNDLE.
>
> Yes, except as far as I can tell all devices (and even = intermediaries)
> handle an offer with the same port number just fine.  But = that's just a
> personal observation, and dangerous to assume ALL of them handle = it
> fine; that's why I didn't argue for long that we should use the = same
> port number in the offer - because it concerned me that someone = knew of
> at least one implementation that didn't handle it well. (not that = we
> can truly accommodate ALL implementations anyway, but it's got to = be a
> heck of a lot higher than simple majority, and as close to 100% as = we
> can get)
>
>
> > However, for bundle-only m- lines such fallback is not needed = - they
> are ONLY going to be used IF the remote endpoint chooses to use = BUNDLE.
> > ...and, based on the agreed scope, the Offerer KNOWS that the = remote
> endpoint supports BUNDLE, so the "one implementation that = doesn't
> handle it" will not be there :)
>
> For WebRTC sure - but we were talking about using BUNDLE = generically.
> Or at least that's what I thought you were asking about.  If = we're only
> talking about using BUNDLE for WebRTC, then not only do you not = need to
> use a port=3D0, but you also don't need a second offer/answer, = etc.
>
>
> >> Also, from a purely protocol perspective, it seems quite = logical to
> me to use a port number of 0 for an m-line you literally don't want = to
> use if the far-end doesn't support
> >> BUNDLE - a port number of 0 effectively means "disabled" today, and
> that's basically what you want.
> >
> > Well, one could also say that it means "Here are some m- lines  I
> want to bundle, with this port, but only if you (the remote = endpoint)
> wants to use bundle." :)
>
> We can certainly change the semantics of SDP offers with port=3D0 = for
> WebRTC, but I think it would be really dangerous to change its
> semantics for general use.
>
>
> >> What I think should happen is the UAS should send an SDP = answer
> using port=3D0 for those same m-lines, and the UAC should then send = a new
> offer with those m-lines having the real port number of the = bundle
> transport, and the far-end should answer that in the same = fashion.
> >
> > The problem is that the grouping framework does not allow, in = SDP
> Answers, usage of port=3D0 in grouped m- lines. It would require = an
> update of the RFC, and I think we want to avoid that.
>
> Considering the number of docs the Unified-Plan proposes to = either
> create, change, update or whatever... methinks having BUNDLE update = the
> grouping framework RFC is rather a minor nit. :)
>
> -hadriel
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.or= g/mailman/listinfo/mmusic

------=_NextPart_000_005E_01CE949C.13CFAF30-- From adam@nostrum.com Thu Aug 8 12:37:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A54311E8211 for ; Thu, 8 Aug 2013 12:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUNJi9LYeWCE for ; Thu, 8 Aug 2013 12:37:39 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6505B21F9AA8 for ; Thu, 8 Aug 2013 12:37:39 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r78JbZMA098968 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 14:37:36 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5203F37A.8030204@nostrum.com> Date: Thu, 08 Aug 2013 14:37:30 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> In-Reply-To: <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:37:40 -0000 On 8/8/13 14:11, Hadriel Kaplan wrote: > If I send a new SDP Offer 10 minutes later during the session, and I set an existing m-line to port 0 in that Offer, does it mean I want to disable the media, or restart bundling, or what? We already talked about that in Berlin: it means you want to disable the line. We're assigning special semantics to port=0 in the **FIRST** offer of a session. Only. Basically, it's a secret handshake that allows you to negotiate bundle at the same time as using it without confusing those implementations that have no idea what all this bundle stuff means. Once you've established that the other end can understand bundle, you don't need the port-0 indication. /a From hadriel.kaplan@oracle.com Thu Aug 8 12:42:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4943E21E8088 for ; Thu, 8 Aug 2013 12:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li5o20BfEIGW for ; Thu, 8 Aug 2013 12:42:07 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id D0AE811E80E4 for ; Thu, 8 Aug 2013 12:42:06 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78Jg2P8007793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 19:42:03 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78Jg1ve021332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 19:42:02 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78Jg1Tu028325; Thu, 8 Aug 2013 19:42:01 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 12:42:01 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5203F37A.8030204@nostrum.com> Date: Thu, 8 Aug 2013 15:41:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:42:22 -0000 On Aug 8, 2013, at 3:37 PM, Adam Roach wrote: > On 8/8/13 14:11, Hadriel Kaplan wrote: >> If I send a new SDP Offer 10 minutes later during the session, and I = set an existing m-line to port 0 in that Offer, does it mean I want to = disable the media, or restart bundling, or what? >=20 > We already talked about that in Berlin: it means you want to disable = the line. We're assigning special semantics to port=3D0 in the **FIRST** = offer of a session. Only. Basically, it's a secret handshake that allows = you to negotiate bundle at the same time as using it without confusing = those implementations that have no idea what all this bundle stuff = means. Once you've established that the other end can understand bundle, = you don't need the port-0 indication. Figured... so you're treating it different. "But why? You're introducing = additional mechanism (and hence complexity) for no technical advantage." :) -hadriel From adam@nostrum.com Thu Aug 8 12:43:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBB121F9FF9 for ; Thu, 8 Aug 2013 12:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjlCPWRegMsk for ; Thu, 8 Aug 2013 12:43:33 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B74A111E820D for ; Thu, 8 Aug 2013 12:43:30 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r78JhQDn099603 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 14:43:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5203F4D8.9040904@nostrum.com> Date: Thu, 08 Aug 2013 14:43:20 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> In-Reply-To: <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:43:34 -0000 On 8/8/13 14:41, Hadriel Kaplan wrote: > On Aug 8, 2013, at 3:37 PM, Adam Roach wrote: > >> On 8/8/13 14:11, Hadriel Kaplan wrote: >>> If I send a new SDP Offer 10 minutes later during the session, and I set an existing m-line to port 0 in that Offer, does it mean I want to disable the media, or restart bundling, or what? >> We already talked about that in Berlin: it means you want to disable the line. We're assigning special semantics to port=0 in the **FIRST** offer of a session. Only. Basically, it's a secret handshake that allows you to negotiate bundle at the same time as using it without confusing those implementations that have no idea what all this bundle stuff means. Once you've established that the other end can understand bundle, you don't need the port-0 indication. > Figured... so you're treating it different. "But why? You're introducing additional mechanism (and hence complexity) for no technical advantage." > The technical advantage is exactly the property I just mentioned: it "allows you to negotiate bundle at the same time as using it without confusing those implementations that have no idea what all this bundle stuff means." That's a pretty important property. /a From kase.saylor@swri.org Thu Aug 8 12:44:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019EE21F9FF9 for ; Thu, 8 Aug 2013 12:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCMddxzFo6GE for ; Thu, 8 Aug 2013 12:44:22 -0700 (PDT) Received: from esg260-1.itc.swri.edu (esg260-1.itc.swri.edu [129.162.252.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8D711E820D for ; Thu, 8 Aug 2013 12:44:18 -0700 (PDT) Received: from exchmail.swri.org (casht260-1.adm.swri.edu [129.162.243.128]) by esg260-1.itc.swri.edu (8.14.5/8.14.5) with ESMTP id r78JiGsq030906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 8 Aug 2013 14:44:16 -0500 Received: from MBX256-1.adm.swri.edu ([169.254.1.28]) by casht260-1.adm.swri.edu ([129.162.243.128]) with mapi id 14.03.0146.000; Thu, 8 Aug 2013 14:44:16 -0500 From: "Saylor, Kase J." To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] RTSP for data recorder design Thread-Index: AQHOlGgO7GiKkfk/MkW7mFNV3B7HCZmL/gmAgAAH4wCAAARogA== Date: Thu, 8 Aug 2013 19:44:15 +0000 Message-ID: <5D319E1E-0055-408A-8973-E110DFBC9BBD@swri.org> References: <862F245D-0795-48E1-8D5A-FEA6A0792D44@swri.org> <5203EABF.2080907@alum.mit.edu> <1383B2A3-D18B-4EC7-87EC-9AE93AE492DA@swri.org> In-Reply-To: <1383B2A3-D18B-4EC7-87EC-9AE93AE492DA@swri.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.162.109.47] Content-Type: multipart/alternative; boundary="_000_5D319E1E0055408A8973E110DFBC9BBDswriorg_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-08_06:2013-08-08, 2013-08-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_policy_notspam policy=inbound_policy score=0 kscore.is_bulkscore=5.80360759450116e-11 kscore.compositescore=0 circleOfTrustscore=0.456 compositescore=0.745211387263969 urlsuspect_oldscore=0.999790211371166 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=57 rbsscore=0.745211387263969 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=-40 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308080176 Subject: Re: [MMUSIC] RTSP for data recorder design X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:44:27 -0000 --_000_5D319E1E0055408A8973E110DFBC9BBDswriorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, Thanks for the link for siprec, unfortunately I am looking for a current IE= TF RFC that could be used. As siprec is informational at this time, it's no= t really an option. I think I'm pretty close with RTSP, but there's just a = few things that I haven't sorted out. Perhaps I'll try to condense my confu= sing email into something a little bit more concise. Here we go: 1. I have data sources that provide data primarily as "streams" of multicas= t datagrams. We have specified the format of those datagrams, and we now ne= ed a way to record them so that they can be retrieved at a later time. 2. We have created a SOAP-based (role you own) interface that would provide= the needed functionality, but if I could accomplish that functionality wit= h RTSP, that would be better for the overall community. 3. I need the following functionality: a. Nominate certain (or all) multicast streams for recording (I assume ANNO= UNCE would be the way to do that) b. Record said streams whenever needed c. Allow a client to find out what streams are available d. Allow the client to playback those streams So my first questions was about "adding" streams to a session. After much r= ambling and attempts to provide example RTSP communications between client = and server, my last question was about how, using DESCRIBE, would I be able= to show all the streams that were in a single session (based upon the assu= mption that multiple data streams could be group under one session). Does this at all help clear up my original post? Thanks again for your time= and help. -- Regards, Kase Saylor Southwest Research Institute On Aug 8, 2013, at 2:28 PM, Kase Saylor > wrote: Paul, Thanks for the link for siprec, unfortunately I am looking for a current IE= TF RFC that could be used. As siprec is informational at this time, it's no= t really an option. I think I'm pretty close with RTSP, but there's just a = few things that I haven't sorted out. Perhaps I'll try to condense my confu= sing email into something a little bit more concise. Here we go: 1. I have data sources that provide data primarily as "streams" of multicas= t datagrams. We have specified the format of those datagrams, and we now ne= ed a way to record them so that they can be retrieved at a later time. 2. We have created a SOAP-based (role you own) interface that would provide= the needed functionality, but if I could accomplish that functionality wit= h RTSP, that would be better for the overall community. 3. I need the following functionality: a. Nominate certain (or all) multicast streams for recording (I assume ANNO= UNCE would be the way to do that) b. Record said streams whenever needed c. Allow a client to find out what streams are available d. Allow the client to playback those streams So my first questions was about "adding" streams to a session. After much r= ambling and attempts to provide example RTSP communications between client = and server, my last question was about how, using DESCRIBE, would I be able= to show all the streams that were in a single session (based upon the assu= mption that multiple data streams could be group under one session). Does this at all help clear up my original post? Thanks again for your time= and help. -- Regards, Kase Saylor Southwest Research Institute On Aug 8, 2013, at 2:00 PM, Paul Kyzivat > wrote: Kase, Its hard to discern your exact requirements. But you should at least look a= t the work in progress by the siprec workgroup. You can find the relevant d= rafts at: http://datatracker.ietf.org/wg/siprec/ This may not be what you need, but is worth a look. Thanks, Paul On 8/8/13 8:49 PM, Saylor, Kase J. wrote: To Whom it may concern, I am helping the US Army develop standards for a network recorder on US Army vehicles. We like to use available standards when at all possible, and my research seems to indicate that RTSP would be a great candidate standard. I've been poring over the RTSP specification (along with the SDP standard) and I have your douce code for LiveMedia. However, I still have a few questions concerning the RTSP standard and its use for our particular need. It seems like there is plenty of examples on the Internet for the PLAY method, but not much for RECORD. I really hope that someone may be able to provide some insight that will get me moving in the right direction. On to the questions! Our recorder requires the ability to "nominate" data streams for recording, so I believe the correct RTSP method is ANNOUNCE. My first question is when I was to add a stream using ANNOUNCE, if I use the same Session number for multiple streams, does this basically create a presentation? For example: C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 3 Date: 7 Aug 2013 15:35:06 GMT Session: 47112344 Content-Type: application/sdp Content-Length: 332 v=3D0 o=3D- 2890844526 2890845468 IN IP4 192.168.0.123 s=3DThreat Stream 1 i=3DThreat stream from threat service on the Boomerang c=3DIN IP4 239.192.0.123/127 t=3D0 0 a=3Dunique_id:threat1 a=3Ddata_type:threat m=3Dmessage 12345 (some response back from server) C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 4 Date: 7 Aug 2013 15:35:07 GMT Session: 47112344 Content-Type: application/sdp Content-Length: 332 v=3D0 o=3D- 2890844527 2890845471 IN IP4 192.168.0.123 s=3DPosition Stream 1 i=3DPosition stream from position service c=3DIN IP4 239.192.0.124/127 t=3D0 0 a=3Dunique_id:pos1 a=3Ddata_type:position m=3Dmessage 12346 (some response back from server) Based upon these two announce messages, is it safe to assume that the following command would cause the recorder to start recording those two data streams (assuming the current date/time is 8/4/2013 1530 GMT)? C->S: RECORD rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 CSeq: 5 Content-Type: text/parameters Session: 47112344 Range: clock=3D20130804T153000Z- Furthermore, would the following command stop the recorder (assuming the current date/time is 8/4/2013 1532 GMT)? I didn't see anywhere in the RFC for stopping a recording. C->S: RECORD rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 CSeq: 6 Content-Type: text/parameters Session: 47112344 Range: clock=3D- 20130804T153200Z I apologize but I have at least one or two more questions ;-) After tearing down a session, how would one go back and playback recorded data? From my RECORD example I've assumed that providing a URI with a "path" based upon record start time, could be one way to mark recording events. Do you think this is an acceptable approach? Then the play command would something like: C->S: PLAY rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 CSeq: 6 Content-Type: text/parameters Session: 1234567 I suppose I could specify unique parameters and use the GET_PARAMETER method to list the available recordings. Perhaps something like: C->S: SETUP rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 1 Transport: unicast;client_port=3D4588-4589 S->C: RTSP/1.0 200 OK CSeq: 1 Date: 5 Aug 2013 11:15:07 GMT Session: 1234567 Transport: unicast;client_port=3D4588-4589;server_port=3D6256-625= 7 C->S: GET_PARAMETER rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 7 Content-Type: text/parameters Session: 1234567 Content-Length: 15 list_recorded_data S->C: RTSP/1.0 200 OK CSeq: 7 Date: 5 Aug 2013 11:15:10 GMT Content-Length: 46 Content-Type: text/parameters list_recorded_data:20130804T153000Z,20130804T213000Z C->S: TEARDOWN rtsp://192.168.0.1/mission_recorder RTSP/1.0 CSeq: 8 Session: 1234567 S->C: RTSP/1.0 200 OK CSeq: 8 Then we'd specify the proper way to interpret the response from the server and open up a new RTSP session to playback the recorded data. For example: C->S: SETUP rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 CSeq: 1 Transport: multicast;client_port=3D4588-4589 S->C: RTSP/1.0 200 OK CSeq: 1 Date: 6 Aug 2013 11:15:07 GMT Session: 7654321 Transport: multicast;client_port=3D4588-4589;server_port=3D6256-6= 257 C->S: PLAY rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 CSeq: 2 Content-Type: text/parameters Session: 7654321 S->C: RTSP/1.0 200 OK CSeq: 2 Date: 6 Aug 2013 11:15:10 GMT Okay, last question, would the DESCRIBE method for rtsp://192.168.0.1/mission_recorder/20130804T153000Z be expected to describe the "streams" that were recorded? In other words could the following be expected? C->S: DESCRIBE rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.= 0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg S->C: RTSP/1.0 200 OK CSeq: 312 Date: 7 Aug 2013 15:35:07 GMT Content-Type: application/sdp Content-Length: 332 v=3D0 o=3D- 2890844527 2890845471 IN IP4 192.168.0.123 s=3DPosition Stream 1 i=3DThreat stream from threat service on the Boomerang c=3DIN IP4 239.192.0.124/127 t=3D0 0 a=3Dunique_id:pos1 a=3Ddata_type:position m=3Dmessage 12346 s=3DPosition Stream 1 i=3DPosition stream from position service c=3DIN IP4 239.192.0.124/127 t=3D0 0 a=3Dunique_id:pos1 a=3Ddata_type:position m=3Dmessage 12346 I really have no idea how multiple streams would be described! Thanks in advance for any help! -- Regards, Kase Saylor Southwest Research Institute _______________________________________________ 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 --_000_5D319E1E0055408A8973E110DFBC9BBDswriorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Paul,

Thanks for the link for siprec, un= fortunately I am looking for a current IETF RFC that could be used. As sipr= ec is informational at this time, it's not really an option. I think I'm pr= etty close with RTSP, but there's just a few things that I haven't sorted out. Perhaps I'll try to condense = my confusing email into something a little bit more concise. Here we go:

1. I have data sources that provid= e data primarily as "streams" of multicast datagrams. We have spe= cified the format of those datagrams, and we now need a way to record them = so that they can be retrieved at a later time.

2. We have created a SOAP-based (r= ole you own) interface that would provide the needed functionality, but if = I could accomplish that functionality with RTSP, that would be better for t= he overall community.

3. I need the following functional= ity:
a. Nominate certain (or all) multi= cast streams for recording (I assume ANNOUNCE would be the way to do that)<= /span>
b. Record said streams whenever ne= eded
c. Allow a client to find out what= streams are available
d. Allow the client to playback th= ose streams

So my first questions was about &q= uot;adding" streams to a session. After much rambling and attempts to = provide example RTSP communications between client and server, my last ques= tion was about how, using DESCRIBE, would I be able to show all the streams that were in a single session (based upon = the assumption that multiple data streams could be group under one session)= .

Does this at all help clear up my = original post? Thanks again for your time and help.

--
Regards,

Kase Saylor
Southwest Research Institute

On Aug 8, 2013, at 2:28 PM, Kase Saylor <ksaylor@swri.org> wrote:

Paul,

Thanks for the link for siprec, unfortunately I am looking for a current IE= TF RFC that could be used. As siprec is informational at this time, it's no= t really an option. I think I'm pretty close with RTSP, but there's just a = few things that I haven't sorted out. Perhaps I'll try to condense my confusing email into something a litt= le bit more concise. Here we go:

1. I have data sources that provide data primarily as "streams" o= f multicast datagrams. We have specified the format of those datagrams, and= we now need a way to record them so that they can be retrieved at a later = time.

2. We have created a SOAP-based (role you own) interface that would provide= the needed functionality, but if I could accomplish that functionality wit= h RTSP, that would be better for the overall community.

3. I need the following functionality:
a. Nominate certain (or all) multicast streams for recording (I assume ANNO= UNCE would be the way to do that)
b. Record said streams whenever needed
c. Allow a client to find out what streams are available
d. Allow the client to playback those streams

So my first questions was about "adding" streams to a session. Af= ter much rambling and attempts to provide example RTSP communications betwe= en client and server, my last question was about how, using DESCRIBE, would= I be able to show all the streams that were in a single session (based upon the assumption that multiple data streams = could be group under one session).

Does this at all help clear up my original post? Thanks again for your time= and help.

--
Regards,

Kase Saylor
Southwest Research Institute


On Aug 8, 2013, at 2:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>
wrote:

Kase,

Its hard to discern your exact requirements. But you should at least look a= t the work in progress by the siprec workgroup. You can find the relevant d= rafts at:

http://datatracker.ietf.= org/wg/siprec/

This may not be what you need, but is worth a look.

Thanks,
Paul

On 8/8/13 8:49 PM, Saylor, Kase J. wrote:
To Whom it may concern,

I am helping the US Army develop standards for a network recorder on US
Army vehicles. We like to use available standards when at all possible,
and my research seems to indicate that RTSP would be a great candidate
standard. I've been poring over the RTSP specification (along with the
SDP standard) and I have your douce code for LiveMedia. However, I still have a few questions concerning the RTSP standard and its use for our
particular need. It seems like there is plenty of examples on the
Internet for the PLAY method, but not much for RECORD. I really hope
that someone may be able to provide some insight that will get me moving in the right direction. On to the questions!

Our recorder requires the ability to "nominate" data streams for<= br> recording, so I believe the correct RTSP method is ANNOUNCE. My first
question is when I was to add a stream using ANNOUNCE, if I use the same Session number for multiple streams, does this basically create a
presentation? For example:

C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0
          CSeq: 3
          Date: 7 Aug 201= 3 15:35:06 GMT
          Session: 471123= 44
          Content-Type: a= pplication/sdp
          Content-Length:= 332

          v=3D0
          o=3D- 289084452= 6 2890845468 IN IP4 192.168.0.123
          s=3DThreat Stre= am 1
          i=3DThreat stre= am from threat service on the Boomerang
          c=3DIN IP4 239.= 192.0.123/127
          t=3D0 0
          a=3Dunique_id:t= hreat1
  a=3Ddata_type:threat
          m=3Dmessage 123= 45

(some response back from server)

C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0
          CSeq: 4
          Date: 7 Aug 201= 3 15:35:07 GMT
          Session: 471123= 44
          Content-Type: a= pplication/sdp
          Content-Length:= 332

          v=3D0
          o=3D- 289084452= 7 2890845471 IN IP4 192.168.0.123
          s=3DPosition St= ream 1
          i=3DPosition st= ream from position service
          c=3DIN IP4 239.= 192.0.124/127
          t=3D0 0
          a=3Dunique_id:p= os1
  a=3Ddata_type:position
          m=3Dmessage 123= 46
(some response back from server)

Based upon these two announce messages, is it safe to assume that the
following command would cause the recorder to start recording those two
data streams (assuming the current date/time is 8/4/2013 1530 GMT)?

    C->S: RECORD
rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
          CSeq: 5
          Content-Type: t= ext/parameters
          Session: 471123= 44
  Range: clock=3D20130804T153000Z-

Furthermore, would the following command stop the recorder (assuming the current date/time is 8/4/2013 1532 GMT)? I didn't see anywhere in the
RFC for stopping a recording.

    C->S: RECORD
rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
          CSeq: 6
          Content-Type: t= ext/parameters
          Session: 471123= 44
  Range: clock=3D- 20130804T153200Z


I apologize but I have at least one or two more questions ;-) After
tearing down a session, how would one go back and playback recorded
data? From my RECORD example I've assumed that providing a URI with a
"path" based upon record start time, could be one way to mark rec= ording
events. Do you think this is an acceptable approach? Then the play
command would something like:

    C->S: PLAY
rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
          CSeq: 6
          Content-Type: t= ext/parameters
          Session: 123456= 7

I suppose I could specify unique parameters and use the GET_PARAMETER
method to list the available recordings. Perhaps something like:

    C->S: SETUP rtsp://192.168.0.1/mission_recorder = RTSP/1.0
          CSeq: 1
  Transport: unicast;client_port=3D4588-4589

    S->C: RTSP/1.0 200 OK
          CSeq: 1
  Date: 5 Aug 2013 11:15:07 GMT
          Session: 123456= 7
          Transport: unic= ast;client_port=3D4588-4589;server_port=3D6256-6257

    C->S: GET_PARAMETER rtsp://192.168.0.1/mission_r= ecorder RTSP/1.0
          CSeq: 7
          Content-Type: t= ext/parameters
          Session: 123456= 7
          Content-Length:= 15

  list_recorded_data


    S->C: RTSP/1.0 200 OK
          CSeq: 7
  Date: 5 Aug 2013 11:15:10 GMT
          Content-Length:= 46
          Content-Type: t= ext/parameters

          list_recorded_d= ata:20130804T153000Z,20130804T213000Z

    C->S: TEARDOWN rtsp://192.168.0.1/mission_record= er RTSP/1.0
          CSeq: 8
  Session: 1234567

    S->C: RTSP/1.0 200 OK
          CSeq: 8


Then we'd specify the proper way to interpret the response from the
server and open up a new RTSP session to playback the recorded data. For example:

    C->S: SETUP
rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
          CSeq: 1
  Transport: multicast;client_port=3D4588-4589

    S->C: RTSP/1.0 200 OK
          CSeq: 1
  Date: 6 Aug 2013 11:15:07 GMT
          Session: 765432= 1
          Transport: mult= icast;client_port=3D4588-4589;server_port=3D6256-6257

    C->S: PLAY
rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
          CSeq: 2
          Content-Type: t= ext/parameters
          Session: 765432= 1

    S->C: RTSP/1.0 200 OK
          CSeq: 2
  Date: 6 Aug 2013 11:15:10 GMT

Okay, last question, would the DESCRIBE method for
rtsp://192.168.0.1/mission_recorder/20130804T153000Z be expected to
describe the "streams" that were recorded? In other words could t= he
following be expected?

C->S: DESCRIBE rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP= /1.0
          CSeq: 312
          Accept: applica= tion/sdp, application/rtsl, application/mheg

S->C: RTSP/1.0 200 OK
          CSeq: 312
          Date: 7 Aug 201= 3 15:35:07 GMT
          Content-Type: a= pplication/sdp
          Content-Length:= 332

          v=3D0
          o=3D- 289084452= 7 2890845471 IN IP4 192.168.0.123
          s=3DPosition St= ream 1
          i=3DThreat stre= am from threat service on the Boomerang
          c=3DIN IP4 239.= 192.0.124/127
          t=3D0 0
          a=3Dunique_id:p= os1
  a=3Ddata_type:position
          m=3Dmessage 123= 46
  s=3DPosition Stream 1
          i=3DPosition st= ream from position service
          c=3DIN IP4 239.= 192.0.124/127
          t=3D0 0
          a=3Dunique_id:p= os1
  a=3Ddata_type:position
          m=3Dmessage 123= 46

I really have no idea how multiple streams would be described!

Thanks in advance for any help!
--
Regards,

Kase Saylor
Southwest Research Institute



_______________________________________________
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


--_000_5D319E1E0055408A8973E110DFBC9BBDswriorg_-- From pkyzivat@alum.mit.edu Thu Aug 8 13:10:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24611E820D for ; Thu, 8 Aug 2013 13:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.886 X-Spam-Level: X-Spam-Status: No, score=0.886 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzBUxMzPsRHd for ; Thu, 8 Aug 2013 13:10:16 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4B711E8200 for ; Thu, 8 Aug 2013 13:10:15 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id ABgd1m0021ei1Bg59LAE4d; Thu, 08 Aug 2013 20:10:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id ALAE1m00g3ZTu2S3kLAE4y; Thu, 08 Aug 2013 20:10:14 +0000 Message-ID: <5203FB26.6040803@alum.mit.edu> Date: Thu, 08 Aug 2013 22:10:14 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <862F245D-0795-48E1-8D5A-FEA6A0792D44@swri.org> <5203EABF.2080907@alum.mit.edu> <1383B2A3-D18B-4EC7-87EC-9AE93AE492DA@swri.org> <5D319E1E-0055-408A-8973-E110DFBC9BBD@swri.org> In-Reply-To: <5D319E1E-0055-408A-8973-E110DFBC9BBD@swri.org> 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=q20121106; t=1375992614; bh=2Ul0TVRsM4rT33O0oXh8rF+E7ltWz6x0vckWOsQUAHo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SItUmXpUUctPNUn/JR/7dGSEtZiuJolWBcPhGrLc8Q2QkgW84OWC0EwZQPagihpnN EuAJuWSsBOYq3Cuz0MmQLxRHehjI6gHVIhFGaM/eRcrPuGpa9aY5S1l05XUTpjjvbL qbUVh8rEPGKY3yrXHUVggq3ulbXP03mJ7zOoDC4F4dcjJ6wc5XZt6lJS9tqcnEIkj0 YbrjSPDSPZ3OAa8vXzXBtc3jXjL8PnOc4x6CYF7iUGh2C+Vu04UZcECMDmJ3GFzCh5 SPdkNTlEv3+Tt2lRg+E9sycY5fjeWXvHDS7W8Oej14iySOhSRzfy2BIp8i+jh3cTqG oUCKkSWPTDlGQ== Subject: Re: [MMUSIC] RTSP for data recorder design X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:10:21 -0000 Kase, Based on the additional info below I don't think siprec would fit your needs anyway. I'm not involved with RTSP, so I can't comment on that. Thanks, Paul On 8/8/13 9:44 PM, Saylor, Kase J. wrote: > Paul, > > Thanks for the link for siprec, unfortunately I am looking for a current > IETF RFC that could be used. As siprec is informational at this time, > it's not really an option. I think I'm pretty close with RTSP, but > there's just a few things that I haven't sorted out. Perhaps I'll try to > condense my confusing email into something a little bit more concise. > Here we go: > > 1. I have data sources that provide data primarily as "streams" of > multicast datagrams. We have specified the format of those datagrams, > and we now need a way to record them so that they can be retrieved at a > later time. > > 2. We have created a SOAP-based (role you own) interface that would > provide the needed functionality, but if I could accomplish that > functionality with RTSP, that would be better for the overall community. > > 3. I need the following functionality: > a. Nominate certain (or all) multicast streams for recording (I assume > ANNOUNCE would be the way to do that) > b. Record said streams whenever needed > c. Allow a client to find out what streams are available > d. Allow the client to playback those streams > > So my first questions was about "adding" streams to a session. After > much rambling and attempts to provide example RTSP communications > between client and server, my last question was about how, using > DESCRIBE, would I be able to show all the streams that were in a single > session (based upon the assumption that multiple data streams could be > group under one session). > > Does this at all help clear up my original post? Thanks again for your > time and help. > > -- > Regards, > > Kase Saylor > Southwest Research Institute > > On Aug 8, 2013, at 2:28 PM, Kase Saylor > wrote: > >> Paul, >> >> Thanks for the link for siprec, unfortunately I am looking for a >> current IETF RFC that could be used. As siprec is informational at >> this time, it's not really an option. I think I'm pretty close with >> RTSP, but there's just a few things that I haven't sorted out. Perhaps >> I'll try to condense my confusing email into something a little bit >> more concise. Here we go: >> >> 1. I have data sources that provide data primarily as "streams" of >> multicast datagrams. We have specified the format of those datagrams, >> and we now need a way to record them so that they can be retrieved at >> a later time. >> >> 2. We have created a SOAP-based (role you own) interface that would >> provide the needed functionality, but if I could accomplish that >> functionality with RTSP, that would be better for the overall community. >> >> 3. I need the following functionality: >> a. Nominate certain (or all) multicast streams for recording (I assume >> ANNOUNCE would be the way to do that) >> b. Record said streams whenever needed >> c. Allow a client to find out what streams are available >> d. Allow the client to playback those streams >> >> So my first questions was about "adding" streams to a session. After >> much rambling and attempts to provide example RTSP communications >> between client and server, my last question was about how, using >> DESCRIBE, would I be able to show all the streams that were in a >> single session (based upon the assumption that multiple data streams >> could be group under one session). >> >> Does this at all help clear up my original post? Thanks again for your >> time and help. >> >> -- >> Regards, >> >> Kase Saylor >> Southwest Research Institute >> >> >> On Aug 8, 2013, at 2:00 PM, Paul Kyzivat > > >> wrote: >> >>> Kase, >>> >>> Its hard to discern your exact requirements. But you should at least >>> look at the work in progress by the siprec workgroup. You can find >>> the relevant drafts at: >>> >>> http://datatracker.ietf.org/wg/siprec/ >>> >>> This may not be what you need, but is worth a look. >>> >>> Thanks, >>> Paul >>> >>> On 8/8/13 8:49 PM, Saylor, Kase J. wrote: >>>> To Whom it may concern, >>>> >>>> I am helping the US Army develop standards for a network recorder on US >>>> Army vehicles. We like to use available standards when at all possible, >>>> and my research seems to indicate that RTSP would be a great candidate >>>> standard. I've been poring over the RTSP specification (along with the >>>> SDP standard) and I have your douce code for LiveMedia. However, I still >>>> have a few questions concerning the RTSP standard and its use for our >>>> particular need. It seems like there is plenty of examples on the >>>> Internet for the PLAY method, but not much for RECORD. I really hope >>>> that someone may be able to provide some insight that will get me moving >>>> in the right direction. On to the questions! >>>> >>>> Our recorder requires the ability to "nominate" data streams for >>>> recording, so I believe the correct RTSP method is ANNOUNCE. My first >>>> question is when I was to add a stream using ANNOUNCE, if I use the same >>>> Session number for multiple streams, does this basically create a >>>> presentation? For example: >>>> >>>> C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0 >>>> CSeq: 3 >>>> Date: 7 Aug 2013 15:35:06 GMT >>>> Session: 47112344 >>>> Content-Type: application/sdp >>>> Content-Length: 332 >>>> >>>> v=0 >>>> o=- 2890844526 2890845468 IN IP4 192.168.0.123 >>>> s=Threat Stream 1 >>>> i=Threat stream from threat service on the Boomerang >>>> c=IN IP4 239.192.0.123/127 >>>> t=0 0 >>>> a=unique_id:threat1 >>>> a=data_type:threat >>>> m=message 12345 >>>> >>>> (some response back from server) >>>> >>>> C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0 >>>> CSeq: 4 >>>> Date: 7 Aug 2013 15:35:07 GMT >>>> Session: 47112344 >>>> Content-Type: application/sdp >>>> Content-Length: 332 >>>> >>>> v=0 >>>> o=- 2890844527 2890845471 IN IP4 192.168.0.123 >>>> s=Position Stream 1 >>>> i=Position stream from position service >>>> c=IN IP4 239.192.0.124/127 >>>> t=0 0 >>>> a=unique_id:pos1 >>>> a=data_type:position >>>> m=message 12346 >>>> (some response back from server) >>>> >>>> Based upon these two announce messages, is it safe to assume that the >>>> following command would cause the recorder to start recording those two >>>> data streams (assuming the current date/time is 8/4/2013 1530 GMT)? >>>> >>>> C->S: RECORD >>>> rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 >>>> CSeq: 5 >>>> Content-Type: text/parameters >>>> Session: 47112344 >>>> Range: clock=20130804T153000Z- >>>> >>>> Furthermore, would the following command stop the recorder (assuming the >>>> current date/time is 8/4/2013 1532 GMT)? I didn't see anywhere in the >>>> RFC for stopping a recording. >>>> >>>> C->S: RECORD >>>> rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 >>>> CSeq: 6 >>>> Content-Type: text/parameters >>>> Session: 47112344 >>>> Range: clock=- 20130804T153200Z >>>> >>>> >>>> I apologize but I have at least one or two more questions ;-) After >>>> tearing down a session, how would one go back and playback recorded >>>> data? From my RECORD example I've assumed that providing a URI with a >>>> "path" based upon record start time, could be one way to mark recording >>>> events. Do you think this is an acceptable approach? Then the play >>>> command would something like: >>>> >>>> C->S: PLAY >>>> rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 >>>> CSeq: 6 >>>> Content-Type: text/parameters >>>> Session: 1234567 >>>> >>>> I suppose I could specify unique parameters and use the GET_PARAMETER >>>> method to list the available recordings. Perhaps something like: >>>> >>>> C->S: SETUP rtsp://192.168.0.1/mission_recorder RTSP/1.0 >>>> CSeq: 1 >>>> Transport: unicast;client_port=4588-4589 >>>> >>>> S->C: RTSP/1.0 200 OK >>>> CSeq: 1 >>>> Date: 5 Aug 2013 11:15:07 GMT >>>> Session: 1234567 >>>> Transport: unicast;client_port=4588-4589;server_port=6256-6257 >>>> >>>> C->S: GET_PARAMETER rtsp://192.168.0.1/mission_recorder RTSP/1.0 >>>> CSeq: 7 >>>> Content-Type: text/parameters >>>> Session: 1234567 >>>> Content-Length: 15 >>>> >>>> list_recorded_data >>>> >>>> >>>> S->C: RTSP/1.0 200 OK >>>> CSeq: 7 >>>> Date: 5 Aug 2013 11:15:10 GMT >>>> Content-Length: 46 >>>> Content-Type: text/parameters >>>> >>>> list_recorded_data:20130804T153000Z,20130804T213000Z >>>> >>>> C->S: TEARDOWN rtsp://192.168.0.1/mission_recorder RTSP/1.0 >>>> CSeq: 8 >>>> Session: 1234567 >>>> >>>> S->C: RTSP/1.0 200 OK >>>> CSeq: 8 >>>> >>>> >>>> Then we'd specify the proper way to interpret the response from the >>>> server and open up a new RTSP session to playback the recorded data. For >>>> example: >>>> >>>> C->S: SETUP >>>> rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 >>>> CSeq: 1 >>>> Transport: multicast;client_port=4588-4589 >>>> >>>> S->C: RTSP/1.0 200 OK >>>> CSeq: 1 >>>> Date: 6 Aug 2013 11:15:07 GMT >>>> Session: 7654321 >>>> Transport: >>>> multicast;client_port=4588-4589;server_port=6256-6257 >>>> >>>> C->S: PLAY >>>> rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0 >>>> CSeq: 2 >>>> Content-Type: text/parameters >>>> Session: 7654321 >>>> >>>> S->C: RTSP/1.0 200 OK >>>> CSeq: 2 >>>> Date: 6 Aug 2013 11:15:10 GMT >>>> >>>> Okay, last question, would the DESCRIBE method for >>>> rtsp://192.168.0.1/mission_recorder/20130804T153000Z be expected to >>>> describe the "streams" that were recorded? In other words could the >>>> following be expected? >>>> >>>> C->S: DESCRIBE rtsp://192.168.0.1/mission_recorder/20130804T153000Z >>>> RTSP/1.0 >>>> CSeq: 312 >>>> Accept: application/sdp, application/rtsl, application/mheg >>>> >>>> S->C: RTSP/1.0 200 OK >>>> CSeq: 312 >>>> Date: 7 Aug 2013 15:35:07 GMT >>>> Content-Type: application/sdp >>>> Content-Length: 332 >>>> >>>> v=0 >>>> o=- 2890844527 2890845471 IN IP4 192.168.0.123 >>>> s=Position Stream 1 >>>> i=Threat stream from threat service on the Boomerang >>>> c=IN IP4 239.192.0.124/127 >>>> t=0 0 >>>> a=unique_id:pos1 >>>> a=data_type:position >>>> m=message 12346 >>>> s=Position Stream 1 >>>> i=Position stream from position service >>>> c=IN IP4 239.192.0.124/127 >>>> t=0 0 >>>> a=unique_id:pos1 >>>> a=data_type:position >>>> m=message 12346 >>>> >>>> I really have no idea how multiple streams would be described! >>>> >>>> Thanks in advance for any help! >>>> -- >>>> Regards, >>>> >>>> Kase Saylor >>>> Southwest Research Institute >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 hadriel.kaplan@oracle.com Thu Aug 8 13:52:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2D11E8220 for ; Thu, 8 Aug 2013 13:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9B4laie5HpG for ; Thu, 8 Aug 2013 13:52:14 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2621F8319 for ; Thu, 8 Aug 2013 13:52:11 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78Kq1eu011470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 20:52:02 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78Kq0hM005248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 20:52:00 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78KpxBI017975; Thu, 8 Aug 2013 20:52:00 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 13:51:59 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5203F4D8.9040904@nostrum.com> Date: Thu, 8 Aug 2013 16:51:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:52:27 -0000 On Aug 8, 2013, at 3:43 PM, Adam Roach wrote: > On 8/8/13 14:41, Hadriel Kaplan wrote: >> On Aug 8, 2013, at 3:37 PM, Adam Roach wrote: >>=20 >>> On 8/8/13 14:11, Hadriel Kaplan wrote: >>>> If I send a new SDP Offer 10 minutes later during the session, and = I set an existing m-line to port 0 in that Offer, does it mean I want to = disable the media, or restart bundling, or what? >>> We already talked about that in Berlin: it means you want to disable = the line. We're assigning special semantics to port=3D0 in the **FIRST** = offer of a session. Only. Basically, it's a secret handshake that allows = you to negotiate bundle at the same time as using it without confusing = those implementations that have no idea what all this bundle stuff = means. Once you've established that the other end can understand bundle, = you don't need the port-0 indication. >> Figured... so you're treating it different. "But why? You're = introducing additional mechanism (and hence complexity) for no technical = advantage." >>=20 >=20 > The technical advantage is exactly the property I just mentioned: it = "allows you to negotiate bundle at the same time as using it without = confusing those implementations that have no idea what all this bundle = stuff means." That's a pretty important property. Yeah, I as being a wise-a$$. But my point is it won't really have that = property, in practice. As much as we'd like it to be otherwise, there = really are things in the middle that will cause this thing to screw up = in weird ways. It's just not as simple as "if they don't understand the = new a=3Dbundle-only attribute, then they'll reject the request".[1] It's not unlike the need to use different port numbers for normal bundle = lines. -hadriel [1] BTW, I'm not speaking about my employer's SBCs in particular - I = actually have no idea what we'll do with an UP bundle-only thing lying = about a port=3D0. We could handle it all correctly, or tear the call = down later, or call WOPR and tell it to play Global Thermonuclear War. = If something's broken in our implementation, we'll fix it... eventually. = I'm more worried about other systems, from vendors who don't attend the = IETF; and I'm worried about the people who have to run SIP networks, for = whom this stuff is not a greenfield. From adam@nostrum.com Thu Aug 8 14:02:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16211E8221 for ; Thu, 8 Aug 2013 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8Jh8EN06CjS for ; Thu, 8 Aug 2013 14:02:29 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A71211E822C for ; Thu, 8 Aug 2013 14:02:28 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r78L2PTe008516 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 16:02:25 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5204075B.1080108@nostrum.com> Date: Thu, 08 Aug 2013 16:02:19 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> In-Reply-To: <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:02:30 -0000 On 8/8/13 15:51, Hadriel Kaplan wrote: > BTW, I'm not speaking about my employer's SBCs in particular - I actually have no idea what we'll do with an UP bundle-only thing lying about a port=0. We could handle it all correctly, or tear the call down later, or call WOPR and tell it to play Global Thermonuclear War. If something's broken in our implementation, we'll fix it... eventually. I'm more worried about other systems, from vendors who don't attend the IETF; and I'm worried about the people who have to run SIP networks, for whom this stuff is not a greenfield. The thing is: no matter what we do here, it's not going to look 100% like the stuff that came before it. All we can do is look at the products we know about, look at the existing published semantics for protocol elements, and make educated guesses about what is likely to cause the fewest problems. We *know* that using the same port numbers for multiple m-lines causes bad behavior in more than a few endpoints, so that's out. On the other hand, the semantics of port=0 are pretty well defined, elicit the exact response we want for remote endpoints, and avoid egregiously large port allocations during call setup (which is an important goal). I think that's a lot more solid set of reasons than the opposing rationale you proffer of "there may or may not be products somewhere in the world that don't really like this approach," not least of all because that statement is true of any approach we come up with. /a From christer.holmberg@ericsson.com Thu Aug 8 14:35:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2836211E812F for ; Thu, 8 Aug 2013 14:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.829 X-Spam-Level: X-Spam-Status: No, score=-5.829 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvZreUvAYuvR for ; Thu, 8 Aug 2013 14:35:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 96AB511E822E for ; Thu, 8 Aug 2013 14:35:05 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-3f-52040f052177 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.48.05990.50F04025; Thu, 8 Aug 2013 23:35:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 23:35:01 +0200 From: Christer Holmberg To: Adam Roach , Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAAqqc0= Date: Thu, 8 Aug 2013 21:35:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422A4F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com>, <5204075B.1080108@nostrum.com> In-Reply-To: <5204075B.1080108@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C422A4FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrS4rP0uQwZdNehZ7/i5it/i06ROz xdTlj1kcmD2WLPnJ5DFr5xMWj49Pb7EEMEdx2aSk5mSWpRbp2yVwZdzsn8tScE6vYsLq1SwN jFPVuxg5OCQETCTuby7vYuQEMsUkLtxbz9bFyMUhJHCYUaJ91glGCGcxo0Tr71vMIA1sAhYS 3f+0QRpEBHwlLl6cyQxiMwvISMw428gEUiIsECYx9WUKREm4xOEP25gg7DKJkwe3sIPYLAIq Ev8WvgWzeYHGXP27mRli1RYWiYUHj7OAJDgFtCUeNd9jA7EZgY77fmoNE8QucYlbT+YzQRwt ILFkz3lmCFtU4uXjf6wgNzAL5EtM7KuGmC8ocXLmE5YJjCKzkHTPQqiahaQKokRP4sbUKWwQ trbEsoWvmSFsXYkZ/w6xIIsvYGRfxciem5iZk15utIkRGEkHt/xW3cF455zIIUZpDhYlcd7N emcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBGOjSvfWQ7L+n5n5tysfu2Wnns5Jrtczy8 QFJSa8+icL4bm/K4XwSt1uWfeHBqbKpdnARnoJbL5QT1yyUOOlOqN9muVfVpZFeUCd0oJ/Hj 5Ln5gbl7F6Ydap0lcVX8QcaE809Em25cEtCe8UJjd+miWfPXzFRYY2Hd8GhprtHWTRUM8Tee 20xRYinOSDTUYi4qTgQA4OiIRnICAAA= Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:35:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C422A4FESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hadriel, I'm a little confused. I thought you wanted port zero in the Answer, but th= e discussion now seems to be around port zero in the Offer. Or, have I missed something? Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Adam Roach [adam@nostrum.com] To: Hadriel Kaplan [hadriel.kaplan@oracle.com] CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmusic@ietf= .org] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On 8/8/13 15:51, Hadriel Kaplan wrote: > BTW, I'm not speaking about my employer's SBCs in particular - I actually= have no idea what we'll do with an UP bundle-only thing lying about a port= =3D0. We could handle it all correctly, or tear the call down later, or ca= ll WOPR and tell it to play Global Thermonuclear War. If something's broke= n in our implementation, we'll fix it... eventually. I'm more worried abou= t other systems, from vendors who don't attend the IETF; and I'm worried ab= out the people who have to run SIP networks, for whom this stuff is not a g= reenfield. The thing is: no matter what we do here, it's not going to look 100% like the stuff that came before it. All we can do is look at the products we know about, look at the existing published semantics for protocol elements, and make educated guesses about what is likely to cause the fewest problems. We *know* that using the same port numbers for multiple m-lines causes bad behavior in more than a few endpoints, so that's out. On the other hand, the semantics of port=3D0 are pretty well defined, elicit the exact response we want for remote endpoints, and avoid egregiously large port allocations during call setup (which is an important goal). I think that's a lot more solid set of reasons than the opposing rationale you proffer of "there may or may not be products somewhere in the world that don't really like this approach," not least of all because that statement is true of any approach we come up with. /a --_000_7594FB04B1934943A5C02806D1A2204B1C422A4FESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hadriel,
 
I'm a little confused. I thought you wanted por= t zero in the Answer, but the discussion now seems to be around port zero i= n the Offer.
 
Or, have I missed something?
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Adam Roach [adam@nostrum.com]
To: Hadriel Kaplan [hadriel.kaplan@oracle.com]
CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmus= ic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?
On 8/8/13 15:51, Hadriel Kaplan wrote:
> BTW, I'm not speaking about my employer's SBCs in particular - I actua= lly have no idea what we'll do with an UP bundle-only thing lying about a p= ort=3D0.  We could handle it all correctly, or tear the call down late= r, or call WOPR and tell it to play Global Thermonuclear War.  If something's broken in our implementation, we'l= l fix it... eventually.  I'm more worried about other systems, from ve= ndors who don't attend the IETF; and I'm worried about the people who have = to run SIP networks, for whom this stuff is not a greenfield.

The thing is: no matter what we do here, it's not going to look 100%
like the stuff that came before it. All we can do is look at the
products we know about, look at the existing published semantics for
protocol elements, and make educated guesses about what is likely to
cause the fewest problems. We *know* that using the same port numbers
for multiple m-lines causes bad behavior in more than a few endpoints,
so that's out. On the other hand, the semantics of port=3D0 are pretty
well defined, elicit the exact response we want for remote endpoints,
and avoid egregiously large port allocations during call setup (which is an important goal).

I think that's a lot more solid set of reasons than the opposing
rationale you proffer of "there may or may not be products somewhere i= n
the world that don't really like this approach," not least of all
because that statement is true of any approach we come up with.

/a
 --_000_7594FB04B1934943A5C02806D1A2204B1C422A4FESESSMB209erics_-- From hadriel.kaplan@oracle.com Thu Aug 8 14:40:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A7C11E8230 for ; Thu, 8 Aug 2013 14:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Io6kz-XKMxsS for ; Thu, 8 Aug 2013 14:40:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id DDFF211E822E for ; Thu, 8 Aug 2013 14:40:35 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78LeVGg021581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 21:40:32 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78LeUbE019593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 21:40:31 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78LeTnZ020109; Thu, 8 Aug 2013 21:40:30 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 14:40:29 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422A4F@ESESSMB209.ericsson.se> Date: Thu, 8 Aug 2013 17:40:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com>, <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422A4F@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:40:42 -0000 On Aug 8, 2013, at 5:35 PM, Christer Holmberg = wrote: > Hadriel, > I'm a little confused. I thought you wanted port zero in the Answer, = but the discussion now seems to be around port zero in the Offer. > Or, have I missed something? Sorry for the confusion - the thing I'm arguing against is the Offer = having port=3D0, while the Answer having port=3DN. I'm fine with the Offer having port=3D0 and the Answer having port=3D0 = (i.e., sticking to RFC 3264). [yeeesh this topic is hard to discuss in email!] -hadriel > Sent from Windows using TouchDown (www.nitrodesk.com) >=20 > -----Original Message----- > From: Adam Roach [adam@nostrum.com] > To: Hadriel Kaplan [hadriel.kaplan@oracle.com] > CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic = [mmusic@ietf.org] > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for = bundle-only m- lines? > On 8/8/13 15:51, Hadriel Kaplan wrote: > > BTW, I'm not speaking about my employer's SBCs in particular - I = actually have no idea what we'll do with an UP bundle-only thing lying = about a port=3D0. We could handle it all correctly, or tear the call = down later, or call WOPR and tell it to play Global Thermonuclear War. = If something's broken in our implementation, we'll fix it... eventually. = I'm more worried about other systems, from vendors who don't attend the = IETF; and I'm worried about the people who have to run SIP networks, for = whom this stuff is not a greenfield. >=20 > The thing is: no matter what we do here, it's not going to look 100%=20= > like the stuff that came before it. All we can do is look at the=20 > products we know about, look at the existing published semantics for=20= > protocol elements, and make educated guesses about what is likely to=20= > cause the fewest problems. We *know* that using the same port numbers=20= > for multiple m-lines causes bad behavior in more than a few endpoints,=20= > so that's out. On the other hand, the semantics of port=3D0 are pretty=20= > well defined, elicit the exact response we want for remote endpoints,=20= > and avoid egregiously large port allocations during call setup (which = is=20 > an important goal). >=20 > I think that's a lot more solid set of reasons than the opposing=20 > rationale you proffer of "there may or may not be products somewhere = in=20 > the world that don't really like this approach," not least of all=20 > because that statement is true of any approach we come up with. >=20 > /a From christer.holmberg@ericsson.com Thu Aug 8 14:52:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9FE11E8247 for ; Thu, 8 Aug 2013 14:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.534 X-Spam-Level: X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2FZxzPxMbdp for ; Thu, 8 Aug 2013 14:52:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DDCC021F9967 for ; Thu, 8 Aug 2013 14:51:34 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-91-520412e55860 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 90.50.19388.5E214025; Thu, 8 Aug 2013 23:51:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 8 Aug 2013 23:51:33 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAAqqc3//9//gIAAJJ8N Date: Thu, 8 Aug 2013 21:51:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422B36@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com>, <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422A4F@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C422B36ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre5TIZYgg/8dihZ7/i5it/i06ROz xdTlj1kcmD2WLPnJ5DFr5xMWj49Pb7EEMEdx2aSk5mSWpRbp2yVwZayb/ZaxYKZLRcvBlUwN jDssuhg5OSQETCTaln9hgbDFJC7cW8/WxcjFISRwmFGibeMtKGcxo8ThaQtYuxg5ONgELCS6 /2mDmCICehJH73GC9DILWEssvDKFESQsLBAmMfVlCkhYRCBc4vCHbUwgU0QEmhgljjyexQyS YBFQkfj2Yj07iM0r4CvRfnYvE8SqVawSV4+uYwNJcArYSTxYfpQJxGYEOu77qTVMEMvEJW49 mc8EcbSAxJI955khbFGJl4//sULU5EvsaLnBBrFAUOLkzCcsExhFZiFpn4WkbBaSMoi4nsSN qVPYIGxtiWULXzND2LoSM/4dYkEWX8DIvoqRPTcxMye93HwTIzCeDm75bbCDcdN9sUOM0hws SuK8m/XOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpgPJ1hdCxYmN30hJYE8xqli0VPolli GtWnXnm1OZU/4yzj/vdx92r/8Kz8e/tUynbxFcevT14v8X725unL90TNlLERmMukND1nti53 7P+pS/bIJ1rErInZzrnGZG2sQaO5da2E4eKKXTr/HmzNktT986yqMqDR1dNn5bofi/VORXXc 1JsV8LhjpxJLcUaioRZzUXEiAPPKiQ51AgAA Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:52:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C422B36ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maybe we should create persistent chat rooms to discuss specific topics, or= something... Anyway, so you are saying that a port-zero Offer + a non-port zero Answer w= ill cause problems, and/or will require an update of 3264? Regarding the possible problem, I believe (I haven't checked how the produc= ts my company make behave, though) that intermediaries simply would not car= e about the port value in the Answer, as it was zero in the Offer. They wou= ld consider the associated media disabled/removed - which is why I believe = a second offer is needed also for bundle-only... Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hadriel Kaplan [hadriel.kaplan@oracle.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Adam Roach [adam@nostrum.com]; mmusic [mmusic@ietf.org] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On Aug 8, 2013, at 5:35 PM, Christer Holmberg wrote: > Hadriel, > I'm a little confused. I thought you wanted port zero in the Answer, but = the discussion now seems to be around port zero in the Offer. > Or, have I missed something? Sorry for the confusion - the thing I'm arguing against is the Offer having= port=3D0, while the Answer having port=3DN. I'm fine with the Offer having port=3D0 and the Answer having port=3D0 (i.e= ., sticking to RFC 3264). [yeeesh this topic is hard to discuss in email!] -hadriel > Sent from Windows using TouchDown (www.nitrodesk.com) > > -----Original Message----- > From: Adam Roach [adam@nostrum.com] > To: Hadriel Kaplan [hadriel.kaplan@oracle.com] > CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmusic@ie= tf.org] > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-onl= y m- lines? > On 8/8/13 15:51, Hadriel Kaplan wrote: > > BTW, I'm not speaking about my employer's SBCs in particular - I actual= ly have no idea what we'll do with an UP bundle-only thing lying about a po= rt=3D0. We could handle it all correctly, or tear the call down later, or = call WOPR and tell it to play Global Thermonuclear War. If something's bro= ken in our implementation, we'll fix it... eventually. I'm more worried ab= out other systems, from vendors who don't attend the IETF; and I'm worried = about the people who have to run SIP networks, for whom this stuff is not a= greenfield. > > The thing is: no matter what we do here, it's not going to look 100% > like the stuff that came before it. All we can do is look at the > products we know about, look at the existing published semantics for > protocol elements, and make educated guesses about what is likely to > cause the fewest problems. We *know* that using the same port numbers > for multiple m-lines causes bad behavior in more than a few endpoints, > so that's out. On the other hand, the semantics of port=3D0 are pretty > well defined, elicit the exact response we want for remote endpoints, > and avoid egregiously large port allocations during call setup (which is > an important goal). > > I think that's a lot more solid set of reasons than the opposing > rationale you proffer of "there may or may not be products somewhere in > the world that don't really like this approach," not least of all > because that statement is true of any approach we come up with. > > /a --_000_7594FB04B1934943A5C02806D1A2204B1C422B36ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Maybe we should create persistent chat rooms to discuss specific topics,&nb= sp;or something...
 
Anyway, so you are saying that a port-zero Offer + a non-port zero= Answer will cause problems, and/or will require an update of 3264?
 
Regarding the possible problem, I believe (I haven't checked how the p= roducts my company make behave, though) that intermediaries simply would no= t care about the port value in the Answer, as it was zero in the Offer. The= y would consider the associated media disabled/removed - which is why I believe a second offer is needed a= lso for bundle-only...
 
Regards,
 
Christer
 

Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: Adam Roach [adam@nostrum.com]; mmusic [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

On Aug 8, 2013, at 5:35 PM, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:

> Hadriel,
> I'm a little confused. I thought you wanted port zero in the Answer, b= ut the discussion now seems to be around port zero in the Offer.
> Or, have I missed something?

Sorry for the confusion - the thing I'm arguing against is the Offer having= port=3D0, while the Answer having port=3DN.

I'm fine with the Offer having port=3D0 and the Answer having port=3D0 (i.e= ., sticking to RFC 3264).

[yeeesh this topic is hard to discuss in email!]

-hadriel


> Sent from Windows using TouchDown (www.nitrodesk.com)
>
> -----Original Message-----
> From: Adam Roach [adam@nostrum.com]
> To: Hadriel Kaplan [hadriel.kaplan@oracle.com]
> CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmusic= @ietf.org]
> Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-= only m- lines?
> On 8/8/13 15:51, Hadriel Kaplan wrote:
> > BTW, I'm not speaking about my employer's SBCs in particular - I = actually have no idea what we'll do with an UP bundle-only thing lying abou= t a port=3D0.  We could handle it all correctly, or tear the call down= later, or call WOPR and tell it to play Global Thermonuclear War.  If something's broken in our implementation, we'l= l fix it... eventually.  I'm more worried about other systems, from ve= ndors who don't attend the IETF; and I'm worried about the people who have = to run SIP networks, for whom this stuff is not a greenfield.
>
> The thing is: no matter what we do here, it's not going to look 100% <= br> > like the stuff that came before it. All we can do is look at the
> products we know about, look at the existing published semantics for <= br> > protocol elements, and make educated guesses about what is likely to <= br> > cause the fewest problems. We *know* that using the same port numbers =
> for multiple m-lines causes bad behavior in more than a few endpoints,=
> so that's out. On the other hand, the semantics of port=3D0 are pretty=
> well defined, elicit the exact response we want for remote endpoints, =
> and avoid egregiously large port allocations during call setup (which = is
> an important goal).
>
> I think that's a lot more solid set of reasons than the opposing
> rationale you proffer of "there may or may not be products somewh= ere in
> the world that don't really like this approach," not least of all=
> because that statement is true of any approach we come up with.
>
> /a

 --_000_7594FB04B1934943A5C02806D1A2204B1C422B36ESESSMB209erics_-- From mary.ietf.barnes@gmail.com Thu Aug 8 15:01:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A2611E8242 for ; Thu, 8 Aug 2013 15:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.088 X-Spam-Level: X-Spam-Status: No, score=-102.088 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqO5awcTjjA0 for ; Thu, 8 Aug 2013 15:01:10 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id C0ACD21F9BBD for ; Thu, 8 Aug 2013 14:59:01 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id s1so1833125qcw.23 for ; Thu, 08 Aug 2013 14:59:01 -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=kc4udeM6GGYjo1zM4MMtfg+YpmtteT6xKlTaFU3J8kc=; b=Pdx9iLZRcaf3pfdSKltqqIVN9Bwv7aSUfm0ZrcBEWlvNYgt+yUjtRrlysE7Rsdlaec 1G8o4ojjH2rHWSBWicuAmDpvtIcYBHB2FpDOWapXf+OJG7sxnByf68M/GRSeUs5cT4xV /Tx1elQuSt7kKIF3PxMCL2Y7Jt22bKBsFnMzstr54dVrKx/6FoZQO8Vq3lqUUv2FZhCg uB+vcO99dLF9fAhBCiUcvB+6PixT10PDFREOK+MkZw2FDamvgztNOjDvhYxiSuPDbo/A igrOACjDs4tflk+w5xaK0EFAz7ZuupOmtJIO9CpvbsfM85OYLLtR8yvHvSnO4uXkbr7j Ozpw== MIME-Version: 1.0 X-Received: by 10.49.53.10 with SMTP id x10mr8186933qeo.46.1375999141235; Thu, 08 Aug 2013 14:59:01 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Thu, 8 Aug 2013 14:59:01 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422B36@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422A4F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422B36@ESESSMB209.ericsson.se> Date: Thu, 8 Aug 2013 16:59:01 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bd766de06502304e376c4c8 Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:01:11 -0000 --047d7bd766de06502304e376c4c8 Content-Type: text/plain; charset=ISO-8859-1 There is already a chatroom configured for each of the WGs: http://www.ietf.org/jabber/index.html It's the same one you would join during a meeting. You can access it via the tools page: http://tools.ietf.org/wg/mmusic/ Logs are permanent, etc. And, of course subject to IETF IPR rules ;) Mary. On Thu, Aug 8, 2013 at 4:51 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Maybe we should create persistent chat rooms to discuss specific > topics, or something... > > Anyway, so you are saying that a port-zero Offer + a non-port zero Answer > will cause problems, and/or will require an update of 3264? > > Regarding the possible problem, I believe (I haven't checked how the > products my company make behave, though) that intermediaries simply would > not care about the port value in the Answer, as it was zero in the Offer. > They would consider the associated media disabled/removed - which is why I > believe a second offer is needed also for bundle-only... > > Regards, > > Christer > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Hadriel Kaplan [hadriel.kaplan@oracle.com] > *To:* Christer Holmberg [christer.holmberg@ericsson.com] > *CC:* Adam Roach [adam@nostrum.com]; mmusic [mmusic@ietf.org] > *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for > bundle-only m- lines? > > On Aug 8, 2013, at 5:35 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hadriel, > > I'm a little confused. I thought you wanted port zero in the Answer, but > the discussion now seems to be around port zero in the Offer. > > Or, have I missed something? > > Sorry for the confusion - the thing I'm arguing against is the Offer > having port=0, while the Answer having port=N. > > I'm fine with the Offer having port=0 and the Answer having port=0 (i.e., > sticking to RFC 3264). > > [yeeesh this topic is hard to discuss in email!] > > -hadriel > > > > Sent from Windows using TouchDown (www.nitrodesk.com) > > > > -----Original Message----- > > From: Adam Roach [adam@nostrum.com] > > To: Hadriel Kaplan [hadriel.kaplan@oracle.com] > > CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [ > mmusic@ietf.org] > > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for > bundle-only m- lines? > > On 8/8/13 15:51, Hadriel Kaplan wrote: > > > BTW, I'm not speaking about my employer's SBCs in particular - I > actually have no idea what we'll do with an UP bundle-only thing lying > about a port=0. We could handle it all correctly, or tear the call down > later, or call WOPR and tell it to play Global Thermonuclear War. If > something's broken in our implementation, we'll fix it... eventually. I'm > more worried about other systems, from vendors who don't attend the IETF; > and I'm worried about the people who have to run SIP networks, for whom > this stuff is not a greenfield. > > > > The thing is: no matter what we do here, it's not going to look 100% > > like the stuff that came before it. All we can do is look at the > > products we know about, look at the existing published semantics for > > protocol elements, and make educated guesses about what is likely to > > cause the fewest problems. We *know* that using the same port numbers > > for multiple m-lines causes bad behavior in more than a few endpoints, > > so that's out. On the other hand, the semantics of port=0 are pretty > > well defined, elicit the exact response we want for remote endpoints, > > and avoid egregiously large port allocations during call setup (which is > > an important goal). > > > > I think that's a lot more solid set of reasons than the opposing > > rationale you proffer of "there may or may not be products somewhere in > > the world that don't really like this approach," not least of all > > because that statement is true of any approach we come up with. > > > > /a > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --047d7bd766de06502304e376c4c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There is already a chatroom configured for each of the WGs= :
It's the same one you would join d= uring a meeting. =A0You can access it via the tools page:=A0

Logs are permanent, etc. =A0And, of co= urse subject to IETF IPR rules ;)

Mary.


O= n Thu, Aug 8, 2013 at 4:51 PM, Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:

Maybe we should create persistent chat rooms to discuss specific topics,=A0= or something...
=A0
Anyway, so you are saying that a port-zero Offer + a non-port zero Ans= wer will cause problems, and/or will require an update of 3264?
=A0
Regarding the possible problem, I believe (I haven't checked how t= he products my company make behave, though) that intermediaries simply woul= d not care about the port value in the Answer, as it was zero in the Offer.= They would consider the associated media disabled/removed - which is why I believe a second offer is needed a= lso for bundle-only...
=A0
Regards,
=A0
Christer
=A0

Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: Adam Roach [adam@nostrum.com]; mmusic [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

On Aug 8, 2013, at 5:35 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> Hadriel,
> I'm a little confused. I thought you wanted port zero in the Answe= r, but the discussion now seems to be around port zero in the Offer.
> Or, have I missed something?

Sorry for the confusion - the thing I'm arguing against is the Offer ha= ving port=3D0, while the Answer having port=3DN.

I'm fine with the Offer having port=3D0 and the Answer having port=3D0 = (i.e., sticking to RFC 3264).

[yeeesh this topic is hard to discuss in email!]

-hadriel


> Sent from Windows using TouchDown (www.nitrodesk.com)
>
> -----Original Message-----
> From: Adam Roach [adam@nostrum.com]
> To: Hadriel Kaplan [hadriel.kaplan@oracle.com]
> CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmusic@ietf.org]
> Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-= only m- lines?
> On 8/8/13 15:51, Hadriel Kaplan wrote:
> > BTW, I'm not speaking about my employer's SBCs in particu= lar - I actually have no idea what we'll do with an UP bundle-only thin= g lying about a port=3D0.=A0 We could handle it all correctly, or tear the = call down later, or call WOPR and tell it to play Global Thermonuclear War.=A0 If something's broken in our implementation, we&= #39;ll fix it... eventually.=A0 I'm more worried about other systems, f= rom vendors who don't attend the IETF; and I'm worried about the pe= ople who have to run SIP networks, for whom this stuff is not a greenfield.
>
> The thing is: no matter what we do here, it's not going to look 10= 0%
> like the stuff that came before it. All we can do is look at the
> products we know about, look at the existing published semantics for <= br> > protocol elements, and make educated guesses about what is likely to <= br> > cause the fewest problems. We *know* that using the same port numbers =
> for multiple m-lines causes bad behavior in more than a few endpoints,=
> so that's out. On the other hand, the semantics of port=3D0 are pr= etty
> well defined, elicit the exact response we want for remote endpoints, =
> and avoid egregiously large port allocations during call setup (which = is
> an important goal).
>
> I think that's a lot more solid set of reasons than the opposing <= br> > rationale you proffer of "there may or may not be products somewh= ere in
> the world that don't really like this approach," not least of= all
> because that statement is true of any approach we come up with.
>
> /a

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


--047d7bd766de06502304e376c4c8-- From hadriel.kaplan@oracle.com Thu Aug 8 15:08:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15C21E80A7 for ; Thu, 8 Aug 2013 15:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFA0Agi1J8fw for ; Thu, 8 Aug 2013 15:08:14 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A0AA421F9BC1 for ; Thu, 8 Aug 2013 15:07:14 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r78M7AsG011202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Aug 2013 22:07:11 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78M7902006555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 22:07:09 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r78M794B008046; Thu, 8 Aug 2013 22:07:09 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Aug 2013 15:07:08 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5204075B.1080108@nostrum.com> Date: Thu, 8 Aug 2013 18:07:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:08:21 -0000 On Aug 8, 2013, at 5:02 PM, Adam Roach wrote: > On 8/8/13 15:51, Hadriel Kaplan wrote: >> BTW, I'm not speaking about my employer's SBCs in particular - I = actually have no idea what we'll do with an UP bundle-only thing lying = about a port=3D0. We could handle it all correctly, or tear the call = down later, or call WOPR and tell it to play Global Thermonuclear War. = If something's broken in our implementation, we'll fix it... eventually. = I'm more worried about other systems, from vendors who don't attend the = IETF; and I'm worried about the people who have to run SIP networks, for = whom this stuff is not a greenfield. >=20 > The thing is: no matter what we do here, it's not going to look 100% = like the stuff that came before it. All we can do is look at the = products we know about, look at the existing published semantics for = protocol elements, and make educated guesses about what is likely to = cause the fewest problems. We *know* that using the same port numbers = for multiple m-lines causes bad behavior in more than a few endpoints, = so that's out. On the other hand, the semantics of port=3D0 are pretty = well defined, elicit the exact response we want for remote endpoints, = and avoid egregiously large port allocations during call setup (which is = an important goal). The semantics of using port=3D0 are well defined, as you say - those = semantics are that you MUST NOT use the media. You are changing those = semantics, if the far-end supports BUNDLE. You feel it's safe to change = those semantics, because you feel that SDP is only being processed by = the local and remote endpoints. I'm saying that's a really bad = assumption, because I know that in fact it is not the case. > I think that's a lot more solid set of reasons than the opposing = rationale you proffer of "there may or may not be products somewhere in = the world that don't really like this approach," not least of all = because that statement is true of any approach we come up with. Do you honestly believe that using a port number of 0 in an offer, while = the answer uses a port number of N, is equally impacting on = interoperability as using an attribute for capability discovery and then = a second O/A round of the real numbers? C'mon man. You've seen the = stuff that's out there. The SDP Offer and Answer's m-line port number = is used by all kinds of whacky equipment, to determine the RTP/RTCP flow = information. It's used by passive monitoring systems, NATs, CGNs, = Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and god knows what = else. Even just in my own employer, we've got five different types of = equipment that look at the the m-line port numbers, only one of which is = our SBCs (and we've got multiple flavors of them too, fwiw). -hadriel From matthew@matthew.at Thu Aug 8 15:09:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F67F21E8098 for ; Thu, 8 Aug 2013 15:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu87Yq+WEOyE for ; Thu, 8 Aug 2013 15:09:41 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88C321E809E for ; Thu, 8 Aug 2013 15:09:01 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id CE9CB25004A for ; Thu, 8 Aug 2013 15:08:40 -0700 (PDT) Message-ID: <520416E7.8050709@matthew.at> Date: Thu, 08 Aug 2013 15:08:39 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <5200000A.40102@matthew.at> In-Reply-To: <5200000A.40102@matthew.at> Content-Type: multipart/alternative; boundary="------------080904020604060504040707" Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:09:47 -0000 This is a multi-part message in MIME format. --------------080904020604060504040707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/5/2013 12:42 PM, Matthew Kaufman wrote: > On 8/5/2013 9:59 AM, Christer Holmberg wrote: >> Hi, >> While cleaning up my MMUSIC notes today, I was listening to the audio >> recording, in order to get a clarification regarding what "scope is >> WEBRTC" really means. However, unless I missed something, I didn't >> get a clear answer. >> Does it only cover the browser API (JSEP) or does it also cover >> something that can be sent out on the wire (as long as it is not SIP) >> by a browser? >> > > And what if it passes through a gateway that doesn't inspect the SDP > and blindly passes it to a SIP device. What happens then? > > RTCWEB used SDP so it would be compatible with SIP legacy devices, so > certainly this will work... or something about all this has gone off > the rails. > > Matthew Kaufman There's been some great discussion in this thread, but nobody has answered my question or provided feedback on my interpretation of what might has happened. Anyone? Matthew Kaufman --------------080904020604060504040707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/5/2013 12:42 PM, Matthew Kaufman wrote:
On 8/5/2013 9:59 AM, Christer Holmberg wrote:
Hi,
 
While cleaning up my MMUSIC notes today, I was listening to the audio recording, in order to get a clarification regarding what "scope is WEBRTC" really means.  However, unless I missed something, I didn't get a clear answer.
 
Does it only cover the browser API (JSEP) or does it also cover something that can be sent out on the wire (as long as it is not SIP) by a browser?
 


And what if it passes through a gateway that doesn't inspect the SDP and blindly passes it to a SIP device. What happens then?

RTCWEB used SDP so it would be compatible with SIP legacy devices, so certainly this will work... or something about all this has gone off the rails.

Matthew Kaufman


There's been some great discussion in this thread, but nobody has answered my question or provided feedback on my interpretation of what might has happened. Anyone?

Matthew Kaufman
--------------080904020604060504040707-- From christer.holmberg@ericsson.com Thu Aug 8 21:38:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0310E21F9DED for ; Thu, 8 Aug 2013 21:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2NRLCrZzF60 for ; Thu, 8 Aug 2013 21:38:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5698021F9DE1 for ; Thu, 8 Aug 2013 21:38:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-ae-520472577fa5 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 84.9B.05990.75274025; Fri, 9 Aug 2013 06:38:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 06:38:47 +0200 From: Christer Holmberg To: Hadriel Kaplan , Adam Roach Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712Q== Date: Fri, 9 Aug 2013 04:38:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C422D7DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvrW54EUuQwfQdVhZ7/i5it/i06ROz xdTlj1kcmD2WLPnJ5DFr5xMWj49Pb7EEMEdx2aSk5mSWpRbp2yVwZUy5epy94JlrxYbb8xgb GC9adjFyckgImEi8WnWEHcIWk7hwbz1bFyMXh5DAYUaJ6YtXM0M4ixkl/rfvAqri4GATsJDo /qcN0iAi4Ctx9vB9RhCbWUBGYsbZRiaQEmGBMImpL1MgSsIlDn/YxgRh10lMfzyDFcRmEVCR 2H24HaycF2jMqwd1EJtesEh83LcdbBOngJ3E1M4ckHJGoNO+n1rDBLFJXOLWk/lMECcLSCzZ c54ZwhaVePn4HytIK7NAvsSvP6YgYV4BQYmTM5+wTGAUmYWkexZC1SwkVRAlehI3pk5hg7C1 JZYtfM0MYetKzPh3iAVZfAEj+ypG9tzEzJz0cqNNjMA4Orjlt+oOxjvnRA4xSnOwKInzbtY7 EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcYdU8gGb/acaNq78er5F8/P9B0pGUrK6u66z L/nHbu2w8fu+dmsX+X88vC6PL0RPclWb1rl7ru4x3e4H/98Z3fTO3fJQ5Eqq5e8n72c/WOV3 weXDlPxV9k8mr+9mf/pebI546q3k3LDdezK+2PMrxbiI7tkx4fORmTU92Y+cYhoZ2T0+aCn+ iVRiKc5INNRiLipOBABfP97AcQIAAA== Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 04:38:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C422D7DESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, An alternative way, using BUNDLE as currently specified, is the add the bun= dle-only m- lines in a subsequent Offer, once BUNDLE usage has been negotia= ted. Then one does not need port zero. Of course, that would a "third" Offe= r (technically it could be done already in the "second" Offer, but BUNDLE r= ecommends against that). Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Hadriel Kaplan [hadriel.kaplan@oracle.com] To: Adam Roach [adam@nostrum.com] CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmusic@ietf= .org] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On Aug 8, 2013, at 5:02 PM, Adam Roach wrote: > On 8/8/13 15:51, Hadriel Kaplan wrote: >> BTW, I'm not speaking about my employer's SBCs in particular - I actuall= y have no idea what we'll do with an UP bundle-only thing lying about a por= t=3D0. We could handle it all correctly, or tear the call down later, or c= all WOPR and tell it to play Global Thermonuclear War. If something's brok= en in our implementation, we'll fix it... eventually. I'm more worried abo= ut other systems, from vendors who don't attend the IETF; and I'm worried a= bout the people who have to run SIP networks, for whom this stuff is not a = greenfield. > > The thing is: no matter what we do here, it's not going to look 100% like= the stuff that came before it. All we can do is look at the products we kn= ow about, look at the existing published semantics for protocol elements, a= nd make educated guesses about what is likely to cause the fewest problems.= We *know* that using the same port numbers for multiple m-lines causes bad= behavior in more than a few endpoints, so that's out. On the other hand, t= he semantics of port=3D0 are pretty well defined, elicit the exact response= we want for remote endpoints, and avoid egregiously large port allocations= during call setup (which is an important goal). The semantics of using port=3D0 are well defined, as you say - those semant= ics are that you MUST NOT use the media. You are changing those semantics,= if the far-end supports BUNDLE. You feel it's safe to change those semant= ics, because you feel that SDP is only being processed by the local and rem= ote endpoints. I'm saying that's a really bad assumption, because I know t= hat in fact it is not the case. > I think that's a lot more solid set of reasons than the opposing rational= e you proffer of "there may or may not be products somewhere in the world t= hat don't really like this approach," not least of all because that stateme= nt is true of any approach we come up with. Do you honestly believe that using a port number of 0 in an offer, while th= e answer uses a port number of N, is equally impacting on interoperability = as using an attribute for capability discovery and then a second O/A round = of the real numbers? C'mon man. You've seen the stuff that's out there. = The SDP Offer and Answer's m-line port number is used by all kinds of whack= y equipment, to determine the RTP/RTCP flow information. It's used by pass= ive monitoring systems, NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs= , App servers, and god knows what else. Even just in my own employer, we'v= e got five different types of equipment that look at the the m-line port nu= mbers, only one of which is our SBCs (and we've got multiple flavors of the= m too, fwiw). -hadriel --_000_7594FB04B1934943A5C02806D1A2204B1C422D7DESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
An alternative way, using BUNDLE as currently s= pecified, is the add the bundle-only m- lines in a subsequent Offer, once B= UNDLE usage has been negotiated. Then one does not need port zero. Of cours= e, that would a "third" Offer (technically it could be done already in the "second" Offer, but BUNDLE recom= mends against that).
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Adam Roach [adam@nostrum.com]
CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmus= ic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

On Aug 8, 2013, at 5:02 PM, Adam Roach <adam@nostrum.com> wrote:

> On 8/8/13 15:51, Hadriel Kaplan wrote:
>> BTW, I'm not speaking about my employer's SBCs in particular - I a= ctually have no idea what we'll do with an UP bundle-only thing lying about= a port=3D0.  We could handle it all correctly, or tear the call down = later, or call WOPR and tell it to play Global Thermonuclear War.  If something's broken in our implementation, we'l= l fix it... eventually.  I'm more worried about other systems, from ve= ndors who don't attend the IETF; and I'm worried about the people who have = to run SIP networks, for whom this stuff is not a greenfield.
>
> The thing is: no matter what we do here, it's not going to look 100% l= ike the stuff that came before it. All we can do is look at the products we= know about, look at the existing published semantics for protocol elements= , and make educated guesses about what is likely to cause the fewest problems. We *know* that using the same port= numbers for multiple m-lines causes bad behavior in more than a few endpoi= nts, so that's out. On the other hand, the semantics of port=3D0 are pretty= well defined, elicit the exact response we want for remote endpoints, and avoid egregiously large port allocations= during call setup (which is an important goal).

The semantics of using port=3D0 are well defined, as you say - those semant= ics are that you MUST NOT use the media.  You are changing those seman= tics, if the far-end supports BUNDLE.  You feel it's safe to change th= ose semantics, because you feel that SDP is only being processed by the local and remote endpoints.  I'm saying t= hat's a really bad assumption, because I know that in fact it is not the ca= se.



> I think that's a lot more solid set of reasons than the opposing ratio= nale you proffer of "there may or may not be products somewhere in the= world that don't really like this approach," not least of all because= that statement is true of any approach we come up with.

Do you honestly believe that using a port number of 0 in an offer, while th= e answer uses a port number of N, is equally impacting on interoperability = as using an attribute for capability discovery and then a second O/A round = of the real numbers?  C'mon man.  You've seen the stuff that's out there.  The SDP Offer and Answer's m= -line port number is used by all kinds of whacky equipment, to determine th= e RTP/RTCP flow information.  It's used by passive monitoring systems,= NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and god knows what else.  Even just in my own empl= oyer, we've got five different types of equipment that look at the the m-li= ne port numbers, only one of which is our SBCs (and we've got multiple flav= ors of them too, fwiw).

-hadriel

 --_000_7594FB04B1934943A5C02806D1A2204B1C422D7DESESSMB209erics_-- From hadriel.kaplan@oracle.com Fri Aug 9 05:30:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B7A21F9FC3 for ; Fri, 9 Aug 2013 05:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CyImwlt-r0k for ; Fri, 9 Aug 2013 05:30:08 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7A921F9EA3 for ; Fri, 9 Aug 2013 05:30:08 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79CU4BI018527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 12:30:05 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79CU3fR017876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 12:30:04 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79CU3Pa017850; Fri, 9 Aug 2013 12:30:03 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 05:30:03 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> Date: Fri, 9 Aug 2013 08:30:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com>, <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 12:30:17 -0000 On Aug 9, 2013, at 12:38 AM, Christer Holmberg = wrote: > An alternative way, using BUNDLE as currently specified, is the add = the bundle-only m- lines in a subsequent Offer, once BUNDLE usage has = been negotiated. Then one does not need port zero. Yup, that makes a lot of sense. > Of course, that would a "third" Offer (technically it could be done = already in the "second" Offer, but BUNDLE recommends against that). Why does BUNDLE recommend against it, such that it needs a third round? -hadriel From christer.holmberg@ericsson.com Fri Aug 9 06:21:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2EE11E80ED for ; Fri, 9 Aug 2013 06:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.985 X-Spam-Level: X-Spam-Status: No, score=-3.985 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI6RL97G0sot for ; Fri, 9 Aug 2013 06:20:56 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8A11E80D2 for ; Fri, 9 Aug 2013 06:20:55 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-92-5204ecb66a0d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id EF.9E.02664.6BCE4025; Fri, 9 Aug 2013 15:20:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 15:20:54 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712YAAYiQAgAAvLZA= Date: Fri, 9 Aug 2013 13:20:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C423165@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com>, <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre62NyxBBm8mGVns+buI3eLTpk/M FlOXP2ZxYPZYsuQnk8esnU9YPD4+vcUSwBzFZZOSmpNZllqkb5fAlbFo1Qz2gjtsFcd2vmJu YJzL2sXIySEhYCLx+sxNRghbTOLCvfVsXYxcHEICRxklmrZfZoVwFjNKHJv6iLmLkYODTcBC ovufNogpIqAncfQeJ0gvs4C1xMIrUxhBwsICYRL7X0aAhEUEwiUOf9jGBDJFRKCLUWLf+vPs IAkWARWJTae6mEBsXgFfifdzZjFDrHrAKjFldjsbSIJTwE5ixvoGFhCbEei476fWMEEsE5f4 cPA6M8TRAhJL9pyHskUlXj7+B/WYksSPDZdYIOp1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYw is1CMnYWkpZZSFpmIWlZwMiyipGjOLU4KTfdyGATIzByDm75bbGD8fJfm0OM0hwsSuK8W/TO BAoJpCeWpGanphakFsUXleakFh9iZOLglGpgbPiVPtfEf+U8//3v7v6rTAuSLX/G86U+yF7Z a8FHJT0d+8YMrdud1648vqEuJeiTaMdWbnXrovrmPdt+cndWXrN8925a0p2jvQX+rSfeLlAL 3jQzuz9hnUoVg+TGIwpTd22qifdao+Bav8NuQ3Qq++wNnLvjOfTWd7UlP9h3f77rygW7ZE4d UGIpzkg01GIuKk4EADfC3ttqAgAA Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:21:09 -0000 Hi, >> An alternative way, using BUNDLE as currently specified, is the add the = bundle-only m- lines in a subsequent Offer, once BUNDLE usage has been nego= tiated. Then one does not need port zero. > > Yup, that makes a lot of sense. > >> Of course, that would a "third" Offer (technically it could be done alre= ady in the "second" Offer, but BUNDLE recommends against that). > > Why does BUNDLE recommend against it, such that it needs a third round? I don't have the exact wording in front of me, but as the second offer is m= eant mainly for "port synchronizing", one should not put lots of extra stuf= f to it, which raises the chance for the offer being rejected. But, of course, you don't have to reject the whole offer if you don't like = the new m- lines, as you can reject them with port zero... Regards, Christer From hadriel.kaplan@oracle.com Fri Aug 9 06:43:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D86D11E80FC for ; Fri, 9 Aug 2013 06:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI+idtIGaF+q for ; Fri, 9 Aug 2013 06:43:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8248611E810A for ; Fri, 9 Aug 2013 06:43:17 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79Dh5De023183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 13:43:06 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79Dh4Ca022229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 13:43:05 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79Dh446007980; Fri, 9 Aug 2013 13:43:04 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 06:43:04 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C423165@ESESSMB209.ericsson.se> Date: Fri, 9 Aug 2013 09:43:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com>, <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C423165@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:43:24 -0000 On Aug 9, 2013, at 9:20 AM, Christer Holmberg = wrote: > Hi, >=20 >>> An alternative way, using BUNDLE as currently specified, is the add = the bundle-only m- lines in a subsequent Offer, once BUNDLE usage has = been negotiated. Then one does not need port zero. >>=20 >> Yup, that makes a lot of sense. >>=20 >>> Of course, that would a "third" Offer (technically it could be done = already in the "second" Offer, but BUNDLE recommends against that). >>=20 >> Why does BUNDLE recommend against it, such that it needs a third = round? >=20 > I don't have the exact wording in front of me, but as the second offer = is meant mainly for "port synchronizing", one should not put lots of = extra stuff to it, which raises the chance for the offer being rejected. >=20 > But, of course, you don't have to reject the whole offer if you don't = like the new m- lines, as you can reject them with port zero=85 Yup. And the advantage with this whole idea is there is no = "a=3Dbundle-only" attribute needed whatsoever, no change in port=3D0 = behavior, etc. It just goes back to the semantics we have today, which = is arguably the safest thing to do. I like your idea a lot. The concept of "change as little as possible in the second offer" makes = some pragmatic sense, but a UAC could be more aggressive/optimistic by = having the second offer do it all, and if that Offer gets rejected = entirely then do it piecemeal. In other words, have the initial Offer = advertise the current bundle stuff (without bundle-only m-lines), and if = the Answer says bundle, then a second offer sends the original m-lines = with corrected port numbers as well as new bundled m-lines - the ones it = was only willing to use if the other end supported BUNDLE. And if that = Offer fails completely, then send an Offer of only the original bundle = lines with corrected port numbers. Or we could even just leave that type of decision up to local policy. = We don't usually say what to do if a whole Offer gets rejected. Of = course we should remind the implementor that it might happen, and how = they could handle it, but it doesn't have to be normative at all. -hadriel From hadriel.kaplan@oracle.com Fri Aug 9 07:24:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26F21F9F31 for ; Fri, 9 Aug 2013 07:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4dnIDP3FqRj for ; Fri, 9 Aug 2013 07:24:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C2A0921F992E for ; Fri, 9 Aug 2013 07:24:17 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79EOG3Y032756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 14:24:17 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79EOFxB017664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 14:24:16 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79EOF33023943; Fri, 9 Aug 2013 14:24:15 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 07:24:15 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <520416E7.8050709@matthew.at> Date: Fri, 9 Aug 2013 10:24:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <5200000A.40102@matthew.at> <520416E7.8050709@matthew.at> To: Matthew Kaufman X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:24:24 -0000 On Aug 8, 2013, at 6:08 PM, Matthew Kaufman wrote: >> And what if it passes through a gateway that doesn't inspect the SDP = and blindly passes it to a SIP device. What happens then? >>=20 >> RTCWEB used SDP so it would be compatible with SIP legacy devices, so = certainly this will work... or something about all this has gone off the = rails. Are we talking about theory, or reality? I've been told that one vendor thinks they'll be able to pass the SDP = from WebRTC-land to SIP-land unchanged. My belief is that this would = require all the SIP devices in their SIP-land to be manufactured by = them, or at least known to support their particular features. But for = their general/common customer environment, that's likely to be the case = so it's not an issue for them. (unless of course the requests get = forwarded outside their domain, but for that they sell SBCs to normalize = it all) For most vendors and deployment scenarios, however, I think blindly = passing SDP between WebRTC and SIP is a pipe dream. At the very least, = there'll be a lot of media-plane interworking for some WbeRTC-SIP = interworking gateway to perform, so it can't be SDP agnostic/blind. = Things like ICE termination, SRTP interworking or termination, audio = transcoding, and perhaps data-channel interworking for certain = applications. It might also want to do BUNDLE rtp-mux termination, = although the complexities of that in the media-plane likely outweigh the = benefits. As far as I can recall, however, the main benefit of WebRTC using SDP = was NOT the ability to interwork to SIP easily. That was more of a = frosting-on-the-cake type thing. The main benefit its proponents = espoused was that it would let simple WebRTC use-cases be done easily, = with few lines of JS code. Advanced use-cases would be possible, but = not easy. I.e., they would require SDP munging in JS, or worse. Or at least that is my impression of what the main argument for SDP was. = Of course this was like two years ago, so my memory could be faulty. = Maybe it was not the main argument, but just the one that I personally = felt was actually valid and laudable. :) -hadriel From christer.holmberg@ericsson.com Fri Aug 9 08:10:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E7D21E8155 for ; Fri, 9 Aug 2013 08:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.795 X-Spam-Level: X-Spam-Status: No, score=-5.795 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFJGtYb6i4Ss for ; Fri, 9 Aug 2013 08:09:47 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D62E921E80DA for ; Fri, 9 Aug 2013 08:03:13 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-f1-520504affc9a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A9.DC.19388.FA405025; Fri, 9 Aug 2013 17:03:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 17:03:11 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712YAAYiQAgAAvLZD//+U4AIAANosw Date: Fri, 9 Aug 2013 15:03:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C423263@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com>, <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C423165@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre56FtYgg99dShZ7/i5it/i06ROz xdTlj1kcmD2WLPnJ5DFr5xMWj49Pb7EEMEdx2aSk5mSWpRbp2yVwZSz9u4a54KpIxYSPjYwN jKsFuhg5OSQETCQ+/v/CBGGLSVy4t56ti5GLQ0jgMKPE5xmrmSGcxYwSfbs+sHQxcnCwCVhI dP/TBjFFBPQkjt7jBOllFrCWWHhlCiNIWFggTGL/ywiQsIhAuMThD9uYQKaICExjlNjwaRIL SIJFQEXi748OZhCbV8BXYldLB9SqG2wS6+avYgRJcArYSZy4cAOsiBHouO+n1jBBLBOX+HDw OjPE0QISS/ach7JFJV4+/scKYStJNC55wgpRryOxYPcnNghbW2LZwtdQiwUlTs58wjKBUWwW krGzkLTMQtIyC0nLAkaWVYzsuYmZOenl5psYgXFzcMtvgx2Mm+6LHWKU5mBREufdrHcmUEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj8baZsxtfO988p2mqFnGs0fjKtg9BG/NtlirvVPi8 gbVzn1bJggVGe80eqXtfXZUkWn5Mb5ORh9Fc+blMxq9brm0qaDE5KNmr8Lg59dd6c62GlZl/ 7nze+L8wqb9xBev0Z0avE5vD/wXO+fZRjP8NxyKb+KCfZpU+31meHatZvJbZzWjXGlsFJZbi jERDLeai4kQAY9nJ1mkCAAA= Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:10:01 -0000 Hi, >>>> An alternative way, using BUNDLE as currently specified, is the add th= e bundle-only m- lines in a subsequent Offer, once BUNDLE usage has been ne= gotiated. Then one does not need port zero. >>>=20 >>> Yup, that makes a lot of sense. >>>=20 >>>> Of course, that would a "third" Offer (technically it could be done al= ready in the "second" Offer, but BUNDLE recommends against that). >>>=20 >>> Why does BUNDLE recommend against it, such that it needs a third round? >>=20 >> I don't have the exact wording in front of me, but as the second offer i= s meant mainly for "port synchronizing", one should not put lots of extra s= tuff to it, which raises the chance for the offer being rejected. >>=20 >> But, of course, you don't have to reject the whole offer if you don't li= ke the new m- lines, as you can reject them with port zero... > > Yup. And the advantage with this whole idea is there is no "a=3Dbundle-o= nly" attribute needed whatsoever, no change in port=3D0 behavior, etc. It = just goes back to the semantics we have today, which is arguably the safest= thing to do. I like your idea a lot. But, that doesn't mean you will put my picture on one of your future meetin= g slides, does it? ;) > The concept of "change as little as possible in the second offer" makes s= ome pragmatic sense, but a UAC could be more aggressive/optimistic by havin= g the second offer do it all, and if that Offer gets rejected entirely then= do it piecemeal. In other=20 > words, have the initial Offer advertise the current bundle > stuff (witho= ut bundle-only m-lines), and if the Answer says bundle, then a second offer= sends the original m-lines with corrected port numbers as well as new bund= led m-lines - the ones it=20 > was only willing to use if the other end supported BUNDLE. And if that O= ffer fails completely, then send an Offer of only the original bundle lines= with corrected port numbers. Yes. > Or we could even just leave that type of decision up to local policy. We= don't usually say what to do if a whole Offer gets rejected. Of course we= should remind the implementor that it might happen, and how they could han= dle it, but it doesn't have to be normative at all. Currently, the only thing the standard (RFC 3264) says is that, if the Offe= r gets rejected, the previous SDP state apply. However, in the case of BUND= LE, as the second offer is very much "bound" to the first one, since it com= pletes the BUNDLE negotiation, we may need to say something (the draft may = already say something) on how to behave. Regards, Christer From ekr@rtfm.com Fri Aug 9 08:35:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4A611E825E for ; Fri, 9 Aug 2013 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTbwMW+a3rWW for ; Fri, 9 Aug 2013 08:35:14 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1611E8176 for ; Fri, 9 Aug 2013 08:28:53 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id d10so2269416qcz.15 for ; Fri, 09 Aug 2013 08:28:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iPUr0uu2KVxfRdTRI542faehf1uEvmj16jveAyveAzI=; b=C1mehcyAnihq7Q+rIFYIpnS1X/swYfEUJQVJ+C2XBMWjOyU0ut5kb/TGIKSyMz+q28 sJ+C9dqQkNuyEZ3Qmr533riDA4lV6MFJe/vuuU7nMzHrHMpXJCvnH21Iua+342R1QD+K T6LolhFk7PcEKkrgh8HriWi+BCPotUZtCpNeBW8d9L4Wt7OKZHwdd9VW+ao/HpFlBxpZ TSvE0DA1VYVFFiOmV2ngSByaaOy9I/QshNZh1BESX0axtF5wtxb3Gh+ovJJ+pWnJhNbM DUqKgTRWg+CgyKxiLEZMruirbY4EXC1wccW/XGM5pYAzjQoUyebCD+u1I6GA9GU9y6Cc hzzA== X-Gm-Message-State: ALoCoQmHbVSSx7lmQeQOE9onG9acvuVkgYklDtnkdxTakNYYwzApBd5ahf86B5ETEE9A3PnWSsTF X-Received: by 10.224.73.200 with SMTP id r8mr10896561qaj.90.1376062131554; Fri, 09 Aug 2013 08:28:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Fri, 9 Aug 2013 08:28:11 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Fri, 9 Aug 2013 08:28:11 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c3e4208a5ed504e3856e31 Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:35:18 -0000 --001a11c3e4208a5ed504e3856e31 Content-Type: text/plain; charset=ISO-8859-1 Uh, just say no to this. We can't design a system under the constraint that it doesn't annoy any middlebox in the world. -Ekr On Thu, Aug 8, 2013 at 9:38 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > An alternative way, using BUNDLE as currently specified, is the add the > bundle-only m- lines in a subsequent Offer, once BUNDLE usage has been > negotiated. Then one does not need port zero. Of course, that would a > "third" Offer (technically it could be done already in the "second" Offer, > but BUNDLE recommends against that). > > Regards, > > Christer > > > > Sent from *Windows* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Hadriel Kaplan [hadriel.kaplan@oracle.com] > *To:* Adam Roach [adam@nostrum.com] > *CC:* Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [ > mmusic@ietf.org] > *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for > bundle-only m- lines? > > On Aug 8, 2013, at 5:02 PM, Adam Roach wrote: > > > On 8/8/13 15:51, Hadriel Kaplan wrote: > >> BTW, I'm not speaking about my employer's SBCs in particular - I > actually have no idea what we'll do with an UP bundle-only thing lying > about a port=0. We could handle it all correctly, or tear the call down > later, or call WOPR and tell it to play Global Thermonuclear War. If > something's broken in our implementation, we'll fix it... eventually. I'm > more worried about other systems, from vendors who don't attend the IETF; > and I'm worried about the people who have to run SIP networks, for whom > this stuff is not a greenfield. > > > > The thing is: no matter what we do here, it's not going to look 100% > like the stuff that came before it. All we can do is look at the products > we know about, look at the existing published semantics for protocol > elements, and make educated guesses about what is likely to cause the > fewest problems. We *know* that using the same port numbers for multiple > m-lines causes bad behavior in more than a few endpoints, so that's out. On > the other hand, the semantics of port=0 are pretty well defined, elicit the > exact response we want for remote endpoints, and avoid egregiously large > port allocations during call setup (which is an important goal). > > The semantics of using port=0 are well defined, as you say - those > semantics are that you MUST NOT use the media. You are changing those > semantics, if the far-end supports BUNDLE. You feel it's safe to change > those semantics, because you feel that SDP is only being processed by the > local and remote endpoints. I'm saying that's a really bad assumption, > because I know that in fact it is not the case. > > > > > I think that's a lot more solid set of reasons than the opposing > rationale you proffer of "there may or may not be products somewhere in the > world that don't really like this approach," not least of all because that > statement is true of any approach we come up with. > > Do you honestly believe that using a port number of 0 in an offer, while > the answer uses a port number of N, is equally impacting on > interoperability as using an attribute for capability discovery and then a > second O/A round of the real numbers? C'mon man. You've seen the stuff > that's out there. The SDP Offer and Answer's m-line port number is used by > all kinds of whacky equipment, to determine the RTP/RTCP flow information. > It's used by passive monitoring systems, NATs, CGNs, Firewalls, Routers, > PDGs, x-CSCFs, SBCs, App servers, and god knows what else. Even just in my > own employer, we've got five different types of equipment that look at the > the m-line port numbers, only one of which is our SBCs (and we've got > multiple flavors of them too, fwiw). > > -hadriel > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11c3e4208a5ed504e3856e31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Uh, just say no to this.

We can= 9;t design a system under the constraint that it doesn't annoy
any middlebox in the world.

-Ekr



O= n Thu, Aug 8, 2013 at 9:38 PM, Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
Hi,
=A0
An alternative way, using BUNDLE as currently s= pecified, is the add the bundle-only m- lines in a subsequent Offer, once B= UNDLE usage has been negotiated. Then one does not need port zero. Of cours= e, that=A0would a "third" Offer (technically it could be done already in the "second" Offer, but BUNDLE recom= mends against that).
=A0
Regards,
=A0
Christer
=A0


Sent from Windows using TouchDown= (www.nitrodesk.com<= /a>)

-----Original Message-----
From: Hadriel Kaplan [hadriel.kaplan@oracle.com]
To: Adam Roach [adam@nostrum.com]
CC: Christer Holmberg [christer.holmberg@ericsson.com]; mmusic [mmusic@ietf.org]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?

On Aug 8, 2013, at 5:02 PM, Adam Roach <adam@nostrum.com> wrote:

> On 8/8/13 15:51, Hadriel Kaplan wrote:
>> BTW, I'm not speaking about my employer's SBCs in particul= ar - I actually have no idea what we'll do with an UP bundle-only thing= lying about a port=3D0.=A0 We could handle it all correctly, or tear the c= all down later, or call WOPR and tell it to play Global Thermonuclear War.=A0 If something's broken in our implementation, we&= #39;ll fix it... eventually.=A0 I'm more worried about other systems, f= rom vendors who don't attend the IETF; and I'm worried about the pe= ople who have to run SIP networks, for whom this stuff is not a greenfield.
>
> The thing is: no matter what we do here, it's not going to look 10= 0% like the stuff that came before it. All we can do is look at the product= s we know about, look at the existing published semantics for protocol elem= ents, and make educated guesses about what is likely to cause the fewest problems. We *know* that using the same port= numbers for multiple m-lines causes bad behavior in more than a few endpoi= nts, so that's out. On the other hand, the semantics of port=3D0 are pr= etty well defined, elicit the exact response we want for remote endpoints, and avoid egregiously large port allocations= during call setup (which is an important goal).

The semantics of using port=3D0 are well defined, as you say - those semant= ics are that you MUST NOT use the media.=A0 You are changing those semantic= s, if the far-end supports BUNDLE.=A0 You feel it's safe to change thos= e semantics, because you feel that SDP is only being processed by the local and remote endpoints.=A0 I'm saying = that's a really bad assumption, because I know that in fact it is not t= he case.



> I think that's a lot more solid set of reasons than the opposing r= ationale you proffer of "there may or may not be products somewhere in= the world that don't really like this approach," not least of all= because that statement is true of any approach we come up with.

Do you honestly believe that using a port number of 0 in an offer, while th= e answer uses a port number of N, is equally impacting on interoperability = as using an attribute for capability discovery and then a second O/A round = of the real numbers?=A0 C'mon man.=A0 You've seen the stuff that's out there.=A0 The SDP Offer and Answe= r's m-line port number is used by all kinds of whacky equipment, to det= ermine the RTP/RTCP flow information.=A0 It's used by passive monitorin= g systems, NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and god knows what else.=A0 Even just in my own employe= r, we've got five different types of equipment that look at the the m-l= ine port numbers, only one of which is our SBCs (and we've got multiple= flavors of them too, fwiw).

-hadriel

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


--001a11c3e4208a5ed504e3856e31-- From partha@parthasarathi.co.in Fri Aug 9 09:24:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986EA11E81BD for ; Fri, 9 Aug 2013 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EknMfphtHsVp for ; Fri, 9 Aug 2013 09:24:53 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.233]) by ietfa.amsl.com (Postfix) with ESMTP id E2D1421F9C34 for ; Fri, 9 Aug 2013 09:16:53 -0700 (PDT) Received: from userPC (unknown [122.179.104.110]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 4B7C1638D50; Fri, 9 Aug 2013 16:16:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1376065008; bh=PIpXM0YR5lL+JsrT8XZaU10KZKWXktv5GKNw51LXiT0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WVCPHJgD1UG3xgdbe64yDY08foVh8mIfA+VuJun/ZGoOEnVPaBSq64BaEliqzQkmq tjcUHHvyySYG+ltQFuJjSvRDbl7RKYJaAq9k1wvV3XmxscARLKKskASEhY/wert33u z0u/UQoWLKfpvCx3ZY5AhafT+ZPkApT8Zz+TLgKE= From: "Parthasarathi R" To: "'Hadriel Kaplan'" , "'Adam Roach'" References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> In-Reply-To: Date: Fri, 9 Aug 2013 21:46:32 +0530 Message-ID: <009d01ce951b$d52aa340$7f7fe9c0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6Ug/tq7OWFcMaLQvusZphmCnk4FAAlfj9Q Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0201.520515F0.0069, 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: 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 70.87.28.142 Cc: 'mmusic' , 'Christer Holmberg' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:24:57 -0000 I agree with Hadriel that offer with port 0 and answer with non-zero Port is harmful and leads to interop issues. This approach also Violates Sec 8.2 of RFC 3264 requirement " A stream that is offered with a port of zero MUST be marked with port zero in the answer." Thanks Partha > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Friday, August 09, 2013 3:37 AM > To: Adam Roach > Cc: mmusic; Christer Holmberg > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle- > only m- lines? > > > On Aug 8, 2013, at 5:02 PM, Adam Roach wrote: > > > On 8/8/13 15:51, Hadriel Kaplan wrote: > >> BTW, I'm not speaking about my employer's SBCs in particular - I > actually have no idea what we'll do with an UP bundle-only thing lying > about a port=0. We could handle it all correctly, or tear the call > down later, or call WOPR and tell it to play Global Thermonuclear War. > If something's broken in our implementation, we'll fix it... > eventually. I'm more worried about other systems, from vendors who > don't attend the IETF; and I'm worried about the people who have to run > SIP networks, for whom this stuff is not a greenfield. > > > > The thing is: no matter what we do here, it's not going to look 100% > like the stuff that came before it. All we can do is look at the > products we know about, look at the existing published semantics for > protocol elements, and make educated guesses about what is likely to > cause the fewest problems. We *know* that using the same port numbers > for multiple m-lines causes bad behavior in more than a few endpoints, > so that's out. On the other hand, the semantics of port=0 are pretty > well defined, elicit the exact response we want for remote endpoints, > and avoid egregiously large port allocations during call setup (which > is an important goal). > > The semantics of using port=0 are well defined, as you say - those > semantics are that you MUST NOT use the media. You are changing those > semantics, if the far-end supports BUNDLE. You feel it's safe to > change those semantics, because you feel that SDP is only being > processed by the local and remote endpoints. I'm saying that's a > really bad assumption, because I know that in fact it is not the case. > > > > > I think that's a lot more solid set of reasons than the opposing > rationale you proffer of "there may or may not be products somewhere in > the world that don't really like this approach," not least of all > because that statement is true of any approach we come up with. > > Do you honestly believe that using a port number of 0 in an offer, > while the answer uses a port number of N, is equally impacting on > interoperability as using an attribute for capability discovery and > then a second O/A round of the real numbers? C'mon man. You've seen > the stuff that's out there. The SDP Offer and Answer's m-line port > number is used by all kinds of whacky equipment, to determine the > RTP/RTCP flow information. It's used by passive monitoring systems, > NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and > god knows what else. Even just in my own employer, we've got five > different types of equipment that look at the the m-line port numbers, > only one of which is our SBCs (and we've got multiple flavors of them > too, fwiw). > > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Fri Aug 9 09:50:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E6A21F9DA3 for ; Fri, 9 Aug 2013 09:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.296 X-Spam-Level: X-Spam-Status: No, score=-0.296 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUW4H1XlwtQ6 for ; Fri, 9 Aug 2013 09:50:18 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 78FCF11E81BD for ; Fri, 9 Aug 2013 09:42:56 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta02.westchester.pa.mail.comcast.net with comcast id AerD1m00716LCl051givNu; Fri, 09 Aug 2013 16:42:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id Agiv1m00R3ZTu2S3SgivlW; Fri, 09 Aug 2013 16:42:55 +0000 Message-ID: <52051C0F.7010908@alum.mit.edu> Date: Fri, 09 Aug 2013 18:42:55 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> In-Reply-To: <5203F37A.8030204@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=q20121106; t=1376066575; bh=/ExZPZ9ukCrV6bQisspjX+k7zvXARIHYsAy+7H4k6+0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ls5fKEYiu+GWFfYCO7ntmpOjxgbVrWOqn5aNJt1xviLY+2upe1C8/O4FTU6QAyijo 77tiC5Bk7qc7rEFwWsHP9fg9yE+mowzswzbcTG1BXfCA5ihmStq4YJ/yWdf6zvtUQ9 57yKBdUnk0VgRPnegP62+zFthIq7ZhBIF7raNQlhUQkIpbvvEYlHdlDAmP1RLVjsgO PbdBHPIR1waXqfbOYE56LoDio9kat+JbbpPn7EG0ZFR/wCbH8U3oz5ly0t6j6jD3Ys lEB8tmyWecTHvKBRmFxQrYGrNYsoTXtA5Qi4QyVm14JnCqiwlLpVxZuHh2SLQH87Vo Soy/2UV97uoag== Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:50:22 -0000 Wow! I ignore this thread for a day and it goes wild! I get the advantage of looking at the long discussion and only replying selectively. On 8/8/13 9:37 PM, Adam Roach wrote: > On 8/8/13 14:11, Hadriel Kaplan wrote: >> If I send a new SDP Offer 10 minutes later during the session, and I >> set an existing m-line to port 0 in that Offer, does it mean I want to >> disable the media, or restart bundling, or what? > > We already talked about that in Berlin: it means you want to disable the > line. We're assigning special semantics to port=0 in the **FIRST** offer > of a session. IMO this is the wrong way to think of this special case. Rather, it is special to the first offer that proposes a new bundle. It need not be the first offer of the session. It may be that you have many offers in the session that don't use bundle at all. And then eventually you get into a state where you need a bundle. (Yes, I know that is not the WebRTC use case.) Thanks, Paul > Only. Basically, it's a secret handshake that allows you > to negotiate bundle at the same time as using it without confusing those > implementations that have no idea what all this bundle stuff means. Once > you've established that the other end can understand bundle, you don't > need the port-0 indication. > > /a > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Fri Aug 9 09:53:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958BB21F9A64 for ; Fri, 9 Aug 2013 09:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K91ga+bKTj0 for ; Fri, 9 Aug 2013 09:53:21 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 946A721F9D1F for ; Fri, 9 Aug 2013 09:47:10 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta12.westchester.pa.mail.comcast.net with comcast id AdZG1m0050ldTLk5Cgn9go; Fri, 09 Aug 2013 16:47:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id Agn91m00X3ZTu2S01gn9V3; Fri, 09 Aug 2013 16:47:09 +0000 Message-ID: <52051D0C.2070106@alum.mit.edu> Date: Fri, 09 Aug 2013 18:47:08 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com>, <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C422D7D@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=q20121106; t=1376066829; bh=bG6SpC3QqruAZZshWoK9rxJWno8C98fRrdZyRn13Law=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nq3uf+cC2DaPIud/18+/8NvtidpyJV9mn+C39dTQfvVz3fx5PORIzYUkqA1SiEmQw HgVT3G/mAdKsxUfMyvUGoF0DWxJAW6JgHgNhLae186l5gcaOYgQLdM5XABDbm/0Fvh wSe09gXhig4FhmmWjrVBDXXZTQnT4h1/Pv4DA9JMLHbxBp7pr1gdue4hRdiK/aSSsv Wh+LjN0RhLhZoRugOiym5CNXs9MYYi8DrPNkbF0yj+eDsakCRm1lBF9feWZHtlYgLU s8HWhhg4oFD3qghpO0vYhDfJdw4zIC4pCJrDIEAuHq/YfQChRKlID7tvt91cvo9NxB /rGpL5zL8bLiA== Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:53:25 -0000 On 8/9/13 6:38 AM, Christer Holmberg wrote: > Hi, > An alternative way, using BUNDLE as currently specified, is the add the > bundle-only m- lines in a subsequent Offer, once BUNDLE usage has been > negotiated. Then one does not need port zero. Of course, that would a > "third" Offer (technically it could be done already in the "second" > Offer, but BUNDLE recommends against that). I quite like this, but prefer that it be allowed in the 2nd O/A. It is consistent with my desire to make many of these "rules" a bit more lenient. If done in the 2nd O/A, which is required anyway, then that should eliminate much (not all) of the objections that are likely to come from RTCWEB. Thanks, Paul > Regards, > Christer > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Hadriel Kaplan [hadriel.kaplan@oracle.com] > *To:* Adam Roach [adam@nostrum.com] > *CC:* Christer Holmberg [christer.holmberg@ericsson.com]; mmusic > [mmusic@ietf.org] > *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for > bundle-only m- lines? > > On Aug 8, 2013, at 5:02 PM, Adam Roach wrote: > >> On 8/8/13 15:51, Hadriel Kaplan wrote: >>> BTW, I'm not speaking about my employer's SBCs in particular - I actually have no idea what we'll do with an UP bundle-only thing lying about a port=0. We could handle it all correctly, or tear the call down later, or call WOPR and tell it to play Global Thermonuclear War. If something's broken in our implementation, we'll > fix it... eventually. I'm more worried about other systems, from > vendors who don't attend the IETF; and I'm worried about the people who > have to run SIP networks, for whom this stuff is not a greenfield. >> >> The thing is: no matter what we do here, it's not going to look 100% like the stuff that came before it. All we can do is look at the products we know about, look at the existing published semantics for protocol elements, and make educated guesses about what is likely to cause the fewest problems. We *know* that using the same > port numbers for multiple m-lines causes bad behavior in more than a few > endpoints, so that's out. On the other hand, the semantics of port=0 are > pretty well defined, elicit the exact response we want for remote > endpoints, and avoid egregiously large port allocations during call > setup (which is an important goal). > > The semantics of using port=0 are well defined, as you say - those > semantics are that you MUST NOT use the media. You are changing those > semantics, if the far-end supports BUNDLE. You feel it's safe to change > those semantics, because you feel that SDP is only being processed by > the local and remote endpoints. I'm saying that's a really bad > assumption, because I know that in fact it is not the case. > > > >> I think that's a lot more solid set of reasons than the opposing rationale you proffer of "there may or may not be products somewhere in the world that don't really like this approach," not least of all because that statement is true of any approach we come up with. > > Do you honestly believe that using a port number of 0 in an offer, while > the answer uses a port number of N, is equally impacting on > interoperability as using an attribute for capability discovery and then > a second O/A round of the real numbers? C'mon man. You've seen the > stuff that's out there. The SDP Offer and Answer's m-line port number > is used by all kinds of whacky equipment, to determine the RTP/RTCP flow > information. It's used by passive monitoring systems, NATs, CGNs, > Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and god knows what > else. Even just in my own employer, we've got five different types of > equipment that look at the the m-line port numbers, only one of which is > our SBCs (and we've got multiple flavors of them too, fwiw). > > -hadriel > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From adam@nostrum.com Fri Aug 9 10:00:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9738A21F9C87 for ; Fri, 9 Aug 2013 10:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ7r7lO6CT83 for ; Fri, 9 Aug 2013 10:00:05 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A1ECF21F9C99 for ; Fri, 9 Aug 2013 09:53:11 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r79Gr9ro041911 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 11:53:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <52051E6F.20009@nostrum.com> Date: Fri, 09 Aug 2013 11:53:03 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Kyzivat References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <52051C0F.7010908@alum.mit.edu> In-Reply-To: <52051C0F.7010908@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:00:07 -0000 On 8/9/13 11:42, Paul Kyzivat wrote: > Wow! I ignore this thread for a day and it goes wild! > I get the advantage of looking at the long discussion and only > replying selectively. > > On 8/8/13 9:37 PM, Adam Roach wrote: >> On 8/8/13 14:11, Hadriel Kaplan wrote: >>> If I send a new SDP Offer 10 minutes later during the session, and I >>> set an existing m-line to port 0 in that Offer, does it mean I want to >>> disable the media, or restart bundling, or what? >> >> We already talked about that in Berlin: it means you want to disable the >> line. We're assigning special semantics to port=0 in the **FIRST** offer >> of a session. > > IMO this is the wrong way to think of this special case. > Rather, it is special to the first offer that proposes a new bundle. > It need not be the first offer of the session. It may be that you have > many offers in the session that don't use bundle at all. And then > eventually you get into a state where you need a bundle. (Yes, I know > that is not the WebRTC use case.) Yes, that's a good point. Basically, it's got to be the first message that tries to use bundle. /a From hadriel.kaplan@oracle.com Fri Aug 9 10:03:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2DB21F9CAD for ; Fri, 9 Aug 2013 10:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvMuWb1zfebn for ; Fri, 9 Aug 2013 10:03:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 54B0021F9CB5 for ; Fri, 9 Aug 2013 09:57:33 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79GvUgC030689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 16:57:31 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79GvT7T012687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 16:57:30 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79GvTra012109; Fri, 9 Aug 2013 16:57:29 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 09:57:29 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 9 Aug 2013 12:57:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66E4998D-33FC-4D9B-8E59-AFF2028F45AA@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> To: Eric Rescorla X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:03:20 -0000 On Aug 9, 2013, at 11:28 AM, Eric Rescorla wrote: > Uh, just say no to this. >=20 > We can't design a system under the constraint that it doesn't annoy > any middlebox in the world. If we're talking about solely for WebRTC usage, I agree: we have a = greenfield playground, in an early phase of life. If we're talking about SIP, it's a widely deployed critical = infrastructure - we can make changes, but we really do have to be super = cautious about what the changes are and what they impact. Not only have = we previously done exactly that for exactly these reasons for very = similar situations for SIP including SDP changes... but we do the same = for other IETF protocols that are no longer in incubation phases but = rather widely deployed and critical for users that they don't break: for = example DNS, SMTP, and even HTTP. The IETF recognizes that there are = undefined middleboxes (both active and passive), in various deployment = models, which constrain the types of changes that can be safely made to = those protocols; and we recognize that breaking things isn't in the best = interest of the users of the Internet, nor the admins which have to run = it. I'm not saying we can't ever make changes to SIP - of course we can, and = we do - but we really do need to consider the implications of what we're = changing on the deployed infrastructure, and in way more than a one = month "let us know if we break stuff" review period. -hadriel From christer.holmberg@ericsson.com Fri Aug 9 12:51:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0F01F0D7E for ; Fri, 9 Aug 2013 12:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW7wXJaetQjV for ; Fri, 9 Aug 2013 12:51:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3E21F92C2 for ; Fri, 9 Aug 2013 12:44:18 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-62-52054691834c Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 11.B0.05990.19645025; Fri, 9 Aug 2013 21:44:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 21:44:17 +0200 From: Christer Holmberg To: Hadriel Kaplan , Eric Rescorla Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlSJcXtEBSiIYg0auyr4C7X7bIZmNRtCw Date: Fri, 9 Aug 2013 19:44:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C42338C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <66E4998D-33FC-4D9B-8E59-AFF2028F45AA@oracle.com> In-Reply-To: <66E4998D-33FC-4D9B-8E59-AFF2028F45AA@oracle.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre5EN9Ygg9+TNS1WvD7HbvFp0ydm i6nLH7M4MHssWfKTyePj01ssHpMftzEHMEdx2aSk5mSWpRbp2yVwZRyafZil4LhgxcnfD1kb GHv4uhg5OSQETCQWnDjDBGGLSVy4t56ti5GLQ0jgMKPE8p2HGSGcxYwSk79+Yu5i5OBgE7CQ 6P6nDdIgIuAjsf3Pb2YQm1lARmLG2UawQcICYRJ7Oh6wQNSES5x/c5oJwjaSmLvlIFg9i4CK xJGZM8FqeAV8JeZ1rmWG2LWaTeL58SawBk4BO4nOzsNgNiPQdd9PrWGCWCYu8eHgdWaIqwUk luw5D2WLSrx8/I8VwlaSaFzyhBWiXk/ixtQpbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRjZyFp mYWkZRaSlgWMLKsY2XMTM3PSy402MQIj5+CW36o7GO+cEznEKM3BoiTOu1nvTKCQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGxqV1JiXVAhmL5q9lMDogdr2s9Zdg8FTZ7LKohkS58Houyc1P z0zrnXYx+I5JvnjihZrLHw64/hZe1+U9K/nMdZm07zuOPeRrjHY2/iI9P/P5/mcR6T/3vF1/ eSV/y+RHbnIXW1qDH/+f1Ke/X/HNyZhlB+p+m897wjxd2I/54FWe/uTy5DWXeZRYijMSDbWY i4oTAWY5wjJqAgAA Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 19:51:08 -0000 Hi, Also keep in mind that what I am suggesting *IS* already supported by BUNDL= E. There is nothing we need to change - not in BUNDLE, not in 3264, not any= where else :) And, as the second offer is needed anyway, we are not adding any extra dela= y etc either. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] P= uolesta Hadriel Kaplan L=E4hetetty: 9. elokuuta 2013 19:57 Vastaanottaja: Eric Rescorla Kopio: mmusic Aihe: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- = lines? On Aug 9, 2013, at 11:28 AM, Eric Rescorla wrote: > Uh, just say no to this. >=20 > We can't design a system under the constraint that it doesn't annoy=20 > any middlebox in the world. If we're talking about solely for WebRTC usage, I agree: we have a greenfie= ld playground, in an early phase of life. If we're talking about SIP, it's a widely deployed critical infrastructure = - we can make changes, but we really do have to be super cautious about wha= t the changes are and what they impact. Not only have we previously done e= xactly that for exactly these reasons for very similar situations for SIP i= ncluding SDP changes... but we do the same for other IETF protocols that ar= e no longer in incubation phases but rather widely deployed and critical fo= r users that they don't break: for example DNS, SMTP, and even HTTP. The I= ETF recognizes that there are undefined middleboxes (both active and passiv= e), in various deployment models, which constrain the types of changes that= can be safely made to those protocols; and we recognize that breaking thin= gs isn't in the best interest of the users of the Internet, nor the admins = which have to run it. I'm not saying we can't ever make changes to SIP - of course we can, and we= do - but we really do need to consider the implications of what we're chan= ging on the deployed infrastructure, and in way more than a one month "let = us know if we break stuff" review period. -hadriel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Aug 9 12:58:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C1F11E813B for ; Fri, 9 Aug 2013 12:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.804 X-Spam-Level: X-Spam-Status: No, score=-5.804 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTyM4HhkIGPe for ; Fri, 9 Aug 2013 12:58:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A927D21F9D71 for ; Fri, 9 Aug 2013 12:49:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-45-520547d7f78a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4B.74.03938.7D745025; Fri, 9 Aug 2013 21:49:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 21:49:43 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712YAAqfkAgABUDKA= Date: Fri, 9 Aug 2013 19:49:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com>, <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> In-Reply-To: <52051D0C.2070106@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI 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+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvre4Nd9Ygg8M9AhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxYmIfS8FylYq27+eYGxhnynYxcnJICJhI fH7wmgXCFpO4cG89WxcjF4eQwGFGiTvPN7JDOIsZJbZ9mAVUxcHBJmAh0f1PG6RBRMBX4tnj 22wgYWGBMIn9LyMgwuEShz9sYwJpFRHoYpR4dWwdM0iCRUBFYvufi2DLeIF6p+z7BhYXErjC KnFhUz3IHE4BHYkdh8JBwoxA93w/tYYJxGYWEJf4cPA6M8SdAhJL9pyHskUlXj7+xwphK0k0 LnnCClGvI7Fg9yc2CFtbYtnC18wQawUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZ OenlhpsYgZFwcMtv3R2Mp86JHGKU5mBREufdpHcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOjsHWC5oXib7MVDFvuNe/S+9fpz2frdjQgR7Igu//T1ac1T+L3fy9geVTf8KDn+CmpnsdP p8uLudhXuJmtd51tm3DOXjDb/sCyUwxfzs3TXHQiadbkXeliWRuYTTqU6uQspvYGh31JTXRX 6Ht+ltVjpvGSQ/Ofzli5fBmLOc8S26mu9rppsvlKLMUZiYZazEXFiQBQHjJRUgIAAA== Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 19:58:17 -0000 Hi, , >> An alternative way, using BUNDLE as currently specified, is the add=20 >> the bundle-only m- lines in a subsequent Offer, once BUNDLE usage has=20 >> been negotiated. Then one does not need port zero. Of course, that=20 >> would a "third" Offer (technically it could be done already in the "seco= nd" >> Offer, but BUNDLE recommends against that). > > I quite like this, but prefer that it be allowed in the 2nd O/A. > It is consistent with my desire to make many of these "rules" a bit more = lenient. > > If done in the 2nd O/A, which is required anyway, then that should elimin= ate much (not all) of the objections that are likely to come from RTCWEB. Yes. And, the 2nd O/A should be fine, as the new bundle-only m- lines can be rej= ected (using port zero in the Answer) without having to reject the whole Of= fer (i.e. it won't affect the "port synchronization" of the other m- lines = in the Offer). Regards, Christer > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > -----Original Message----- > *From:* Hadriel Kaplan [hadriel.kaplan@oracle.com] > *To:* Adam Roach [adam@nostrum.com] > *CC:* Christer Holmberg [christer.holmberg@ericsson.com]; mmusic=20 > [mmusic@ietf.org] > *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for=20 > bundle-only m- lines? > > On Aug 8, 2013, at 5:02 PM, Adam Roach wrote: > >> On 8/8/13 15:51, Hadriel Kaplan wrote: >>> BTW, I'm not speaking about my employer's SBCs in particular - I=20 >>> actually have no idea what we'll do with an UP bundle-only thing=20 >>> lying about a port=3D0. We could handle it all correctly, or tear the= =20 >>> call down later, or call WOPR and tell it to play Global =20 >>> Thermonuclear War. If something's broken in our implementation,=20 >>> we'll > fix it... eventually. I'm more worried about other systems, from=20 > vendors who don't attend the IETF; and I'm worried about the people=20 > who have to run SIP networks, for whom this stuff is not a greenfield. >> >> The thing is: no matter what we do here, it's not going to look 100%=20 >> like the stuff that came before it. All we can do is look at the=20 >> products we know about, look at the existing published semantics for=20 >> protocol elements, and make educated guesses about what is likely to=20 >> cause the fewest problems. We *know* that using the same > port numbers for multiple m-lines causes bad behavior in more than a=20 > few endpoints, so that's out. On the other hand, the semantics of=20 > port=3D0 are pretty well defined, elicit the exact response we want for=20 > remote endpoints, and avoid egregiously large port allocations during=20 > call setup (which is an important goal). > > The semantics of using port=3D0 are well defined, as you say - those=20 > semantics are that you MUST NOT use the media. You are changing those=20 > semantics, if the far-end supports BUNDLE. You feel it's safe to=20 > change those semantics, because you feel that SDP is only being=20 > processed by the local and remote endpoints. I'm saying that's a=20 > really bad assumption, because I know that in fact it is not the case. > > > >> I think that's a lot more solid set of reasons than the opposing rationa= le you proffer of "there may or may not be products somewhere in the world = that don't really like this approach," not least of all because that statem= ent is true of any approach we come up with. > > Do you honestly believe that using a port number of 0 in an offer,=20 > while the answer uses a port number of N, is equally impacting on=20 > interoperability as using an attribute for capability discovery and=20 > then a second O/A round of the real numbers? C'mon man. You've seen=20 > the stuff that's out there. The SDP Offer and Answer's m-line port=20 > number is used by all kinds of whacky equipment, to determine the=20 > RTP/RTCP flow information. It's used by passive monitoring systems,=20 > NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and=20 > god knows what else. Even just in my own employer, we've got five=20 > different types of equipment that look at the the m-line port numbers,=20 > only one of which is our SBCs (and we've got multiple flavors of them too= , fwiw). > > -hadriel > > > > _______________________________________________ > 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 christer.holmberg@ericsson.com Fri Aug 9 13:02:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E77721F963F for ; Fri, 9 Aug 2013 13:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9owkfSw9hgdj for ; Fri, 9 Aug 2013 13:02:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CADD421F9D7B for ; Fri, 9 Aug 2013 12:55:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-80-520549324595 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1C.94.03938.23945025; Fri, 9 Aug 2013 21:55:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Fri, 9 Aug 2013 21:55:30 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIABYY6AgABV8bA= Date: Fri, 9 Aug 2013 19:55:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4233D6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <52051C0F.7010908@alum.mit.edu> In-Reply-To: <52051C0F.7010908@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI 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+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvra6xJ2uQQfdVRoupyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4Nnkye0ETf8WX79uYGhhbeLoYOTkkBEwk Pm5cygxhi0lcuLeerYuRi0NI4DCjxI+PS5kgnMWMEjfPLwJyODjYBCwkuv9pgzSICPhKPHt8 mw0kLCwQJrH/ZQREOFzi8IdtTBB2ksTuW19ZQWwWARWJBcd+sIHYvECtE3+sY4YYv55ZouXL a7AjOAV0JO72vAezGYEO+n5qDdggZgFxiQ8Hr0MdKiCxZM95KFtU4uXjf6wQtpJE45InrBD1 OhILdn9ig7C1JZYthJjPKyAocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGJkz03MzEkvN9zE CIyFg1t+6+5gPHVO5BCjNAeLkjjvJr0zgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYNe/L ZB9uSjq3eZ/jbkGzq8Z3o+Z0V2bOkpv8Six/2cXygo63Gi+KgtZ8ZD8xI+5Xwpcbn96qnnyv 2mKq0bXxGfdqtg36ddZlQmmCgjrm3bEVWZvdJH7P+XiH6+DzQ4y/1s4uivMxTJF9Uvp9Bd9S xrP7r2475K9Wxv378FIJRbdc+d+bJqotUmIpzkg01GIuKk4EAOJdpSxTAgAA Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:02:21 -0000 Hi, > Wow! I ignore this thread for a day and it goes wild! > I get the advantage of looking at the long discussion and only replying s= electively. We should have someone "taking notes" of the e-mail discussions, and then p= ost a week-everyone-who-cares-need-to-know summary once a week :) >>> If I send a new SDP Offer 10 minutes later during the session, and I=20 >>> set an existing m-line to port 0 in that Offer, does it mean I want=20 >>> to disable the media, or restart bundling, or what? >> >> We already talked about that in Berlin: it means you want to disable=20 >> the line. We're assigning special semantics to port=3D0 in the **FIRST**= =20 >> offer of a session. > > IMO this is the wrong way to think of this special case. > Rather, it is special to the first offer that proposes a new bundle. > It need not be the first offer of the session. It may be that you have ma= ny offers in the session that don't use bundle at all. And then eventually = you get into a state where you need a bundle. (Yes, I know that is not the = WebRTC use case.) Can't you have a WebRTC use case with only one m- line, which obviously wou= ldn't require usage of BUNDLE? Then, when you later add new m- lines, you = also want to use BUNDLE... Regards, Christer > Only. Basically, it's a secret handshake that allows you to negotiate=20 > bundle at the same time as using it without confusing those=20 > implementations that have no idea what all this bundle stuff means.=20 > Once you've established that the other end can understand bundle, you=20 > don't need the port-0 indication. > > /a > _______________________________________________ > 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 fandreas@cisco.com Fri Aug 9 15:16:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E911E813B for ; Fri, 9 Aug 2013 15:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaK8zZu7CG+I for ; Fri, 9 Aug 2013 15:16:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AC77321F9BF7 for ; Fri, 9 Aug 2013 15:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11703; q=dns/txt; s=iport; t=1376086218; x=1377295818; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=JX8j12NykHb6Z0rEAc9m+0t1IZzKseVl5ru6GB19fvY=; b=kXavd7DK3xueCLa9Jom7+oJ9cPqAs5DWRzHA2QuiMLjxnqDHLje4GMwm ZW+wP19YKB07kvYzqvTEqXTEXOC1MeorP2VAj1apFPG+mS3CfnoAgv8ER LHntq5b2uXDtZyf/Shm9+bbsaIyi8Lx9K2qh40Nng+AV93/dv2rlmKkPZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsKAJxnBVKtJV2a/2dsb2JhbABbgwY1iUChXAKLTog9gRwWdIIkAQEBBAEBAWsKDQQcAwECChYECwkDAgECARUoCAYNBgIBAYgMDLhokCEYBoQJA5digSqQJYFhgVYg X-IronPort-AV: E=Sophos;i="4.89,849,1367971200"; d="scan'208,217";a="245641286" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 09 Aug 2013 22:10:18 +0000 Received: from bxb-fandreas-8812.cisco.com (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r79MAHe5031926 for ; Fri, 9 Aug 2013 22:10:17 GMT Message-ID: <520568C9.9010603@cisco.com> Date: Fri, 09 Aug 2013 18:10:17 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> In-Reply-To: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020204010109030904060700" Subject: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:16:05 -0000 This is a multi-part message in MIME format. --------------020204010109030904060700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greetings MMUSIC As you can see per the below, the IESG approved the Circuit-Switched Bearers draft for publication, however before doing so, they requested a couple of changes. The resulting approved document can be found at http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21 One of the changes introduced resulted in all 3 correlation mechanisms now being mandatory-to-implement (previously they were not): Implementations MUST support the three correlation mechanisms specified inSection 5.2.3.2 ,Section 5.2.3.3 andSection 5.2.3.4 , and SHOULD include all supported mechanisms the initial Offer. Since this is a non-trivial change that has not been discussed by the WG (and we know of at least one person having expressed concerns with it off-line), we are hereby solicting the WG participants for input on changes introduced as a result of the IESG review with a focus on the above. In doing so, please keep in mind that we are developing standards that work in the general Internet. The following URL provides a diff-file showing the changes resulting from the IESG review: http://tools.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sdp-cs-18.txt&url2=draft-ietf-mmusic-sdp-cs-21.txt Comments are due by August 23 (two weeks from today) Thanks -- Flemming (MMUSIC co-chair) -------- Original Message -------- Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt) Date: Mon, 1 Jul 2013 11:56:23 -0700 From: The IESG To: IETF-Announce CC: mmusic chair , mmusic mailing list , RFC Editor The IESG has approved the following document: - 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ *Technical Summary * The document describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Publich Switched Telephone Network (PSTN) *Working Group Summary * The WG had some discussion around the format to use for E.164 numbers and whether to align this with the existing definition in RFC 3108. The RFC 3108 definition was seen as deficient and the WG agreed it was better to align with relevant parts of the tel URI format defined in RFC 3966, not least since SDP address types are defined in the context of a particular network type, and hence RFC 3108 compatibility is not a concern (the implication is that the "E164" address type may differ between network types in SDP). *Document Quality * There are currently no known implementations of the draft, however the draft is a dependency for 3GPP, so future implementations are expected. The document has received good overall review in the WG, some of which resulted in changes to the detailed specification. The document has been reviewed in detail several times, including of the last few versions. The major contributors to these as well as earlier discussions are listed in the Acknowledgements section of the document. *Personnel * Document Shepherd: Flemming Andreasen Responsible AD: Gonzalo Camarillo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic . --------------020204010109030904060700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greetings MMUSIC

As you can see per the below, the IESG approved the Circuit-Switched Bearers draft for publication, however before doing so, they requested a couple of changes. The resulting approved document can be found at http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21

One of the changes introduced resulted in all 3 correlation mechanisms now being mandatory-to-implement (previously they were not):
<quote>
   Implementations MUST support the three correlation mechanisms
   specified in Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4,
   and SHOULD include all supported mechanisms the initial Offer.
</quote>
Since this is a non-trivial change that has not been discussed by the WG (and we know of at least one person having expressed concerns with it off-line), we are hereby solicting the WG participants for input on changes introduced as a result of the IESG review with a focus on the above. In doing so, please keep in mind that we are developing standards that work in the general Internet.


The following URL provides a diff-file showing the changes resulting from the IESG review:
    http://tools.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sdp-cs-18.txt&url2=draft-ietf-mmusic-sdp-cs-21.txt

Comments are due by August 23 (two weeks from today)

Thanks

-- Flemming (MMUSIC co-chair)



-------- Original Message --------
Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)
Date: Mon, 1 Jul 2013 11:56:23 -0700
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: mmusic chair <mmusic-chairs@tools.ietf.org>, mmusic mailing list <mmusic@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org> 


The IESG has approved the following document:
- 'Session Description Protocol (SDP) Extension For Setting Audio and
   Video Media Streams Over Circuit-Switched Bearers In The Public
   Switched Telephone Network (PSTN)'
  (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard

This document is the product of the Multiparty Multimedia Session Control
Working Group.

The IESG contact persons are Gonzalo Camarillo and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/




*Technical Summary
*

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

*Working Group Summary
*

The WG had some discussion around the format to use for E.164 numbers
and whether to align this with the existing definition in RFC 3108. The
RFC 3108 definition was seen as deficient and the WG agreed it was
better to align with relevant parts of the tel URI format defined in RFC
3966, not least since SDP address types are defined in the context of a
particular network type, and hence RFC 3108 compatibility is not a
concern (the implication is that the "E164" address type may differ
between network types in SDP).

*Document Quality
*

There are currently no known implementations of the draft, however the
draft is a dependency for 3GPP, so future implementations are expected.

The document has received good overall review in the WG, some of which
resulted in changes to the detailed specification. The document has been
reviewed in detail several times, including of the last few versions.
The major contributors to these as well as earlier discussions are
listed in the Acknowledgements section of the document.


*Personnel
*

Document Shepherd: Flemming Andreasen
Responsible AD: Gonzalo Camarillo 
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
.


--------------020204010109030904060700-- From juberti@google.com Fri Aug 9 15:43:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEFC11E8160 for ; Fri, 9 Aug 2013 15:43:17 -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=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQfzc5z6X5Mg for ; Fri, 9 Aug 2013 15:43:16 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8655D21F9D5A for ; Fri, 9 Aug 2013 15:35:21 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e14so5214734iej.15 for ; Fri, 09 Aug 2013 15:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oVsHN5eepjUmZYdi/IbRtoFnwWB8dWH2pfbAD6AQ5Hg=; b=e171We/7w4qIfLTternldbzqRcD+nlqW4aVStTZu9z4wGeT3b69g5JwGkkx+puJm2d CwHix0l143tqTjkMzLrb+z8RbOM0uXfIE5fxZgLnfUckWeV+oKvFCPpZz1C59sl/2JuQ AD26C+CIadlQGuDkm/C+FtrWNYvhgzADqVUg+IvAxUyIiFSiPD3MQC30qdtDP++32sUP WLVyXwLbRuCzvejhbLtoyD3JgiHoGt5xbeuT/rgrTo782QJXPHzi52K5Fe+yp5WNkyl0 /AtkLscV7J+A1+J2P2jzLYYaUZehHrBmB/kBw3Hiv5Nh4Ejckju6MXkhZFkazrP87vlh SydQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oVsHN5eepjUmZYdi/IbRtoFnwWB8dWH2pfbAD6AQ5Hg=; b=NxcFLth48iW19cBAbtA/400szbjr4NYe7PXjPe8Mquiya9L3fhZ0b6C8ku5Br7JsPv z3wmG6JZUmVJUe48RTiy7UNji7o8Vkyj7+SnF1J1PyDudA4D0NVYXRnrA1fE9uYRAKkj eCYzVEkvpLURg/tbAC9tbMy5CFnQP/nXRGbGfSRN5wfeTwRkS6Btt8rKa3CZb+89Nk0w mXUJ5OQkJ0JlWjWqlWjfOk+ba53fFVouTwQdMDcOcrKM7nzSkOYO1zYBYEcujG/a5MXd VAjLDTv1g2oQ5F0ik48pmeRgkYCmtRW0wdZED48rvU81pIAqXImg+sBNTtCpWq25/ln7 goTg== X-Gm-Message-State: ALoCoQneZtPwxwy30qRsnS/ecVqfUdxsLsyebNrC92SvUlTridd3fOC7jIaHnsP8tN9CArvGwLpJuffhRMyNnV6x0FRQtCNRp7MiLkd0Gr3SEysRpb7XE3VHQBD2g4uM0bNlN/Wl/XMyXqrKrsrJJRncSbxfeyMxKLQXyvsKhKnkWtfdQnhfPkyY2NjRJrYi2twhlO+ZSReQ X-Received: by 10.50.77.69 with SMTP id q5mr3490628igw.16.1376087720900; Fri, 09 Aug 2013 15:35:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Fri, 9 Aug 2013 15:35:00 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C42157D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C42157D@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 9 Aug 2013 15:35:00 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bdc0ddac8d6ce04e38b63bf Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:43:18 -0000 --047d7bdc0ddac8d6ce04e38b63bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That is not my understanding. If we don't care about intermediaries, we could have made BUNDLE and UP a lot simpler. I think the expectation should be that Matthew's proposed case will work, modulo any implementation bugs on the remote device. On Wed, Aug 7, 2013 at 8:27 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > If everyone has the same understanding, I would ask the chairs to make > it *very clear* in the final minutes ;)**** > > ** ** > > Regards,**** > > ** ** > > Christer**** > > ** ** > > ** ** > > ** ** > > *L=C3=A4hett=C3=A4j=C3=A4:* Mary Barnes [mailto:mary.ietf.barnes@gmail.co= m] > *L=C3=A4hetetty:* 7. elokuuta 2013 18:25 > *Vastaanottaja:* Christer Holmberg > *Kopio:* Paul Kyzivat; mmusic@ietf.org > > *Aihe:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"**** > > ** ** > > ** ** > > ** ** > > On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote:**** > > Hi,**** > > **** > > Ok, so what is =E2=80=9DRTCWEB usage=E2=80=9D then? :)**** > > **** > > For example, if I implement a JavaScript SIP app, and want to use the UP > with SIP on the wire, would that be a =E2=80=9CRTCWEB usage=E2=80=9D? My = understanding is > that it would NOT be.**** > > **** > > My personal understanding of the scope is:**** > > [MB] That is also my understanding. [/MB] **** > > **** > > 1) JSEP; and**** > > 2) Browser-to-browser cases where we KNOW there are no > intermediaries etc in between.**** > > **** > > Regards,**** > > **** > > Christer**** > > **** > > *L=C3=A4hett=C3=A4j=C3=A4:* mmusic-bounces@ietf.org [mailto:mmusic-bounce= s@ietf.org] *Puolesta > *Mary Barnes > *L=C3=A4hetetty:* 7. elokuuta 2013 17:56 > *Vastaanottaja:* Paul Kyzivat > *Kopio:* mmusic@ietf.org > *Aihe:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"**** > > **** > > On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat > wrote:**** > > On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:**** > > As one of those that used the term, my intention was that the initial > decision was to agree to define what RTCWEB needed. > > As each dependent working group looks at the extensions they need to do, > then they need to make the decision as to whether a wider scope of > possible, desirable, or dangerous. > > So the BUNDLE status at the moment is that any changes for the unified > plan should work for RTCWEB usage, but not for general. It would > probably make sense to make it more generally applicable, but that is > the next step in the decision process, and may need some other technical > decisions before it happens.**** > > **** > > I don't know how you intend the above to be parsed. Specifically, when yo= u > say:**** > > > "any changes for the unified plan should work for RTCWEB usage"**** > > Do you mean: > > 1) that the changes should be designed solely with RTCWEB usage in mind? > (But are still applicable in other environments that find them useful and > choose to adopt them.) > > Or do you mean: > > 2) that those changes should not be used in any environment other than > RTCWEB? > > I might be able to accept (1), but not (2).**** > > [MB] I would agree with your (1), however, not with the parenthetical > part. I would suggest that be "But MAY still be applicable in other > environments... " My concern is that at this point in time, you can't s= ay > that the changes ARE applicable to other environments .... [/MB]**** > > **** > > > Thanks, > Paul**** > > Keith > > ------------------------------------------------------------------------ > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Bernard Aboba > *Sent:* 07 August 2013 00:50 > *To:* Christer Holmberg; mmusic > *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"**** > > > > Christer said: > > "While cleaning up my MMUSIC notes today, I was listening to the audio > recording, in order to get a clarification regarding what "scope is > WEBRTC" really means. However, unless I missed something, I didn't get > a clear answer. > > Does it only cover the browser API (JSEP) or does it also cover > something that can be sent out on the wire (as long as it is not SIP) by > a browser? > > Feel free to tell me that it is a stupid question, and that the answer > is very clear :)" > > [BA] I actually think it is a good question :) > > One interpretation of "scope is WebRTC" is that the SDP in "Unified > Plan" applies to use within the JSEP API. As a result, one > might expect the SDP used in createOffer, setLocalDescription and > setRemoteDescription to resemble that in the "Unified Plan" document. > Since signaling is out of scope for WebRTC, applications that use the > JSEP API might or might not use the "Unified Plan" SDP in signaling on > the wire. > > However, "Unified Plan" includes normative references to published SDP > specifications that were developed for general use, and the adoption of > "Unified Plan" (or even an applicability statement within the "Unified > Plan" document) doesn't change the applicability of those documents. > > Also, there may be some specifications that are part of the "Unified > Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgroup: > SIMULCAST) > > Ultimately, I am expecting the work involved in "Unified Plan" to span > multiple documents, and to clarify the applicability, those individual > documents will need to explain what they apply to (just WebRTC use or > more general use). > > **** > > _______________________________________________ > 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 > > --047d7bdc0ddac8d6ce04e38b63bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That is not my understanding. If we don't care about i= ntermediaries, we could have made BUNDLE and UP a lot simpler.

I think the expectation should be that Matthew's proposed case w= ill work, modulo any implementation bugs on the remote device.


On Wed,= Aug 7, 2013 at 8:27 AM, Christer Holmberg <christer.holmberg= @ericsson.com> wrote:

If everyon= e has the same understanding, I would ask the chairs to make it very clear in the final minutes ;)

=C2= =A0

Regards,

=C2= =A0

Christer

=C2= =A0

=C2= =A0

=C2= =A0

L=C3=A4hett=C3=A4j=C3=A4:<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif""> Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
L=C3=A4hetetty: 7. elokuuta 2013 18:25
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic@ietf.org


Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"=

=C2=A0

=C2=A0

=C2=A0<= /p>

On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,<= /p>

=C2=A0

Ok, so wha= t is =E2=80=9DRTCWEB usage=E2=80=9D then? :)

=C2=A0

For exampl= e, if I implement a JavaScript SIP app, and want to use the UP with SIP on the wire, would that be a =E2=80=9CRTCWEB usage=E2=80=9D? My understanding= is that it would NOT be.

=C2=A0

My persona= l understanding of the scope is:

[MB] That is also my understanding. [/MB]=C2=A0

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 JSEP; and=

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Browser-to-browser cases w= here we KNOW there are no intermediaries etc in between.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

L=C3=A4hett=C3=A4j=C3=A4:<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif""> mmusic-bounces= @ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mary Barnes
L=C3=A4hetetty: 7. elokuuta 2013 17:56
Vastaanottaja: Paul Kyzivat
Kopio: mmusic@i= etf.org
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"=

=C2=A0

On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:

On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:

As one of those that used the term, my intention was= that the initial
decision was to agree to define what RTCWEB needed.

As each dependent working group looks at the extensions they need to do, then they need to make the decision as to whether a wider scope of
possible, desirable, or dangerous.

So the BUNDLE status at the moment is that any changes for the unified
plan should work for RTCWEB usage, but not for general. It would
probably make sense to make it more generally applicable, but that is
the next step in the decision process, and may need some other technical decisions before it happens.

=C2=A0

I don't know how you intend the above to be pars= ed. Specifically, when you say:


=C2=A0 "any changes for the unified plan should work for RTCWEB usage&= quot;

Do you mean:

1) that the changes should be designed solely with RTCWEB usage in mind? (B= ut are still applicable in other environments that find them useful and cho= ose to adopt them.)

Or do you mean:

2) that those changes should not be used in any environment other than RTCW= EB?

I might be able to accept (1), but not (2).

[MB] I would agree with your (1), however, not with = the parenthetical part. =C2=A0I would suggest that be "But MAY still b= e applicable in other environments... " =C2=A0 My concern is that at this point in time, you can't say that the changes ARE applicable t= o other environments .... =C2=A0[/MB]

=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

Keith

------------------------------------------------------------------------
*From:*mmusic-= bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On
Behalf Of *Bernard Aboba
*Sent:* 07 August 2013 00:50
*To:* Christer Holmberg; mmusic
*Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"



Christer said:

"While cleaning up my MMUSIC notes today, I was listening to the audio=
recording, in order to get a clarification regarding what "scope is WEBRTC" really means. =C2=A0However, unless I missed something, I didn= 't get
a clear answer.

Does it only cover the browser API (JSEP) or does it also cover
something that can be sent out on the wire (as long as it is not SIP) by a browser?

Feel free to tell me that it is a stupid question, and that the answer
is very clear :)"

[BA] =C2=A0I actually think it is a good question :)

One interpretation of "scope is WebRTC" =C2=A0is that the =C2=A0S= DP in "Unified
Plan" applies to use within =C2=A0the JSEP API. =C2=A0 =C2=A0As a resu= lt, one
might expect the SDP used in createOffer, setLocalDescription and
setRemoteDescription to resemble that in the "Unified Plan" docum= ent.
Since signaling is out of scope for WebRTC, applications that use the
JSEP API might or might not use the "Unified Plan" SDP in signali= ng on
the wire.

However, "Unified Plan" includes normative references to publishe= d SDP
specifications that were developed for general use, and the adoption of
"Unified Plan" (or even an applicability statement within the &qu= ot;Unified
Plan" document) doesn't change the applicability of those document= s.

Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgro= up:
SIMULCAST)

Ultimately, I am expecting the work involved in "Unified Plan" to= span
multiple documents, and to clarify the applicability, =C2=A0those individua= l
documents will need to explain what they apply to (just WebRTC use or
more general use).

_____________________= __________________________
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

=C2=A0

=C2=A0


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


--047d7bdc0ddac8d6ce04e38b63bf-- From matthew@matthew.at Fri Aug 9 16:17:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC98521F9FF1 for ; Fri, 9 Aug 2013 16:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEg3wTAytQiP for ; Fri, 9 Aug 2013 16:17:02 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A09821F9F9B for ; Fri, 9 Aug 2013 16:11:31 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id C4BA2250042 for ; Fri, 9 Aug 2013 16:11:28 -0700 (PDT) Message-ID: <52057721.8080207@matthew.at> Date: Fri, 09 Aug 2013 16:11:29 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C42157D@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 23:17:07 -0000 On 8/9/2013 3:35 PM, Justin Uberti wrote: > That is not my understanding. If we don't care about intermediaries, > we could have made BUNDLE and UP a lot simpler. > > I think the expectation should be that Matthew's proposed case will > work, modulo any implementation bugs on the remote device. > I agree. Otherwise we're doing this "standards" thing wrong OR shouldn't be reusing *this* standard for *that* application. Matthew Kaufman From juberti@google.com Fri Aug 9 16:26:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603A621F8ECA for ; Fri, 9 Aug 2013 16:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0u-T3p5p7Ui for ; Fri, 9 Aug 2013 16:26:09 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6E87021F8319 for ; Fri, 9 Aug 2013 16:20:59 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id f4so5053047iea.23 for ; Fri, 09 Aug 2013 16:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zhPuh/zgz2wsFsgDsnQgsywpDgRu8rYYQMWt45RTkVw=; b=WHXMitVtHNDNMnakA2KTtWr4x7HBBFREijMYJOtv9QiOcPq4VfXudQNr1jsDBxs0IG k5uftCHxMxJ04ZToFm4xsSFcR52Tu2H2v9EKhZIBqqI5fvYYn3DnYiaYnwdU/GbQBWJg CC4VdXi35SNpV72lYmICsugdV9MLZWDnFMlmCb7lpqVXhKGemq1H42ZxLhq0i832ZWor ZYxNNYc4p43wNKRDvOs2RvAnaPfPjZXL9vDj9hRUzOEUGAC14zSqPJ+5f0+rvHb7p1V6 gGVpsYPKo0madgk5slUofiawwoEUhVjUD7oRqffcgbHDY8U/qLp3AxUAsXeaF/MAYPVG luzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zhPuh/zgz2wsFsgDsnQgsywpDgRu8rYYQMWt45RTkVw=; b=B/qZggbqO19HsHcK/snpt5Uluh5DwL68yrq3pvKjJdAUhr19iFY6Qgs140+EQ8WK2h +zxXt/y+ZzBk11SMxKDtR+0/N17ceu8a2j+O8KKjIwD1tH60vJZ0OYTNFTJOL/QHgUuK QXp87I0iFxermqpDqxb20b2miPTTosaCdObdik/dYsMzj/TJVN+ZVdf0QQCFiavb0vqD Ck9OR/aATNTqB+SjdYEdRpP/A2In9Gg3X7PU9oVhsDWbbAZVAdeoUGrsFeHaTUwqmNZm jNgqIDvHVA4Z3i6pG/R91QnsRhqBzCm+UAm6k4wRf5PsGMG+3Wvegq9BzT1p5MO6XYnW WC+Q== X-Gm-Message-State: ALoCoQk74uTTp0pySVGuuYFCVfTNau1XbpvnqO3Z8uuXGkZ6kkQvzMT0rTjSXpZ1Vq9y3ie9dDj/BeAIOrtRkOUyIWb1D88+IGPKSeeUR5sp94UxHxNYAOkct7imjJaMBwEDrTdaWE4m+KU/pPHSH1qyHL9LI1gDaL6g2W1dpIKnsYLAYwXcyMYix2EbVlwb1P3mXLiawk2g X-Received: by 10.50.77.69 with SMTP id q5mr3554136igw.16.1376090457586; Fri, 09 Aug 2013 16:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Fri, 9 Aug 2013 16:20:37 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> From: Justin Uberti Date: Fri, 9 Aug 2013 16:20:37 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bdc0ddae75c3204e38c06c9 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 23:26:10 -0000 --047d7bdc0ddae75c3204e38c06c9 Content-Type: text/plain; charset=UTF-8 Requiring a second offer to add the bundle-only m-lines defeats the purpose of bundle-only. a) The delay to do an O/A will often exceed the time to allocate candidates, for small numbers of streams; bundle-only was meant to avoid this candidate latency. b) Once you have the initial answer, you know whether the other side supports BUNDLE, so you can take the appropriate action (and so there is no need for bundle-only). If SIP can't deal with the bundle-only concept, then WebRTC apps that care about latency will have to decide whether they are running in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will be bundled in the initial offer; in compatibility mode, 2 offer-answers will be needed. This would be a somewhat unfortunate outcome, so I'd like to see bundle-only (or something like it) work. On Fri, Aug 9, 2013 at 12:49 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > , > >> An alternative way, using BUNDLE as currently specified, is the add > >> the bundle-only m- lines in a subsequent Offer, once BUNDLE usage has > >> been negotiated. Then one does not need port zero. Of course, that > >> would a "third" Offer (technically it could be done already in the > "second" > >> Offer, but BUNDLE recommends against that). > > > > I quite like this, but prefer that it be allowed in the 2nd O/A. > > It is consistent with my desire to make many of these "rules" a bit more > lenient. > > > > If done in the 2nd O/A, which is required anyway, then that should > eliminate much (not all) of the objections that are likely to come from > RTCWEB. > > Yes. > > And, the 2nd O/A should be fine, as the new bundle-only m- lines can be > rejected (using port zero in the Answer) without having to reject the whole > Offer (i.e. it won't affect the "port synchronization" of the other m- > lines in the Offer). > > Regards, > > Christer > > > > > > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > > > -----Original Message----- > > *From:* Hadriel Kaplan [hadriel.kaplan@oracle.com] > > *To:* Adam Roach [adam@nostrum.com] > > *CC:* Christer Holmberg [christer.holmberg@ericsson.com]; mmusic > > [mmusic@ietf.org] > > *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for > > bundle-only m- lines? > > > > On Aug 8, 2013, at 5:02 PM, Adam Roach wrote: > > > >> On 8/8/13 15:51, Hadriel Kaplan wrote: > >>> BTW, I'm not speaking about my employer's SBCs in particular - I > >>> actually have no idea what we'll do with an UP bundle-only thing > >>> lying about a port=0. We could handle it all correctly, or tear the > >>> call down later, or call WOPR and tell it to play Global > >>> Thermonuclear War. If something's broken in our implementation, > >>> we'll > > fix it... eventually. I'm more worried about other systems, from > > vendors who don't attend the IETF; and I'm worried about the people > > who have to run SIP networks, for whom this stuff is not a greenfield. > >> > >> The thing is: no matter what we do here, it's not going to look 100% > >> like the stuff that came before it. All we can do is look at the > >> products we know about, look at the existing published semantics for > >> protocol elements, and make educated guesses about what is likely to > >> cause the fewest problems. We *know* that using the same > > port numbers for multiple m-lines causes bad behavior in more than a > > few endpoints, so that's out. On the other hand, the semantics of > > port=0 are pretty well defined, elicit the exact response we want for > > remote endpoints, and avoid egregiously large port allocations during > > call setup (which is an important goal). > > > > The semantics of using port=0 are well defined, as you say - those > > semantics are that you MUST NOT use the media. You are changing those > > semantics, if the far-end supports BUNDLE. You feel it's safe to > > change those semantics, because you feel that SDP is only being > > processed by the local and remote endpoints. I'm saying that's a > > really bad assumption, because I know that in fact it is not the case. > > > > > > > >> I think that's a lot more solid set of reasons than the opposing > rationale you proffer of "there may or may not be products somewhere in the > world that don't really like this approach," not least of all because that > statement is true of any approach we come up with. > > > > Do you honestly believe that using a port number of 0 in an offer, > > while the answer uses a port number of N, is equally impacting on > > interoperability as using an attribute for capability discovery and > > then a second O/A round of the real numbers? C'mon man. You've seen > > the stuff that's out there. The SDP Offer and Answer's m-line port > > number is used by all kinds of whacky equipment, to determine the > > RTP/RTCP flow information. It's used by passive monitoring systems, > > NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and > > god knows what else. Even just in my own employer, we've got five > > different types of equipment that look at the the m-line port numbers, > > only one of which is our SBCs (and we've got multiple flavors of them > too, fwiw). > > > > -hadriel > > > > > > > > _______________________________________________ > > 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 > --047d7bdc0ddae75c3204e38c06c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Requiring a second offer to add the bundle-only m-lines de= feats the purpose of bundle-only.
a) The delay to do an O/A will often = exceed the time to allocate candidates, for small numbers of streams; bundl= e-only was meant to avoid this candidate latency.
b) Once you have the initial answer, you know whether the other side s= upports BUNDLE, so you can take the appropriate action (and so there is no = need for bundle-only).

If SIP can't deal with = the bundle-only concept, then WebRTC apps that care about latency will have= to decide whether they are running in WebRTC-only mode or compatibility mo= de. In WebRTC-only mode, streams will be bundled in the initial offer; in c= ompatibility mode, 2 offer-answers will be needed.

This would be a somewhat unfortunate outcome, so I'= d like to see bundle-only (or something like it) work.

<= /div>





On Fri, Aug 9, 2013 at 12:49 PM, Christe= r Holmberg <christer.holmberg@ericsson.com> wro= te:
Hi,
,
>> An alternative way, using BUNDLE as currently specified, is the ad= d
>> the bundle-only m- lines in a subsequent Offer, once BUNDLE usage = has
>> been negotiated. Then one does not need port zero. Of course, that=
>> would a "third" Offer (technically it could be done alre= ady in the "second"
>> Offer, but BUNDLE recommends against that).
>
> I quite like this, but prefer that it be allowed in the 2nd O/A.
> It is consistent with my desire to make many of these "rules"= ; a bit more lenient.
>
> If done in the 2nd O/A, which is required anyway, then that should eli= minate much (not all) of the objections that are likely to come from RTCWEB= .

Yes.

And, the 2nd O/A should be fine, as the new bundle-only m- lines can be rej= ected (using port zero in the Answer) without having to reject the whole Of= fer (i.e. it won't affect the "port synchronization" of the o= ther m- lines in the Offer).

Regards,

Christer






> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> -----Original Message-----
> *From:* Hadriel Kaplan [h= adriel.kaplan@oracle.com]
> *To:* Adam Roach [adam@nostrum.com= ]
> *CC:* Christer Holmberg [christer.holmberg@ericsson.com]; mmusic
> [mmusic@ietf.org]
> *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for
> bundle-only m- lines?
>
> On Aug 8, 2013, at 5:02 PM, Adam Roach <adam@nostrum.com> wrote:
>
>> On 8/8/13 15:51, Hadriel Kaplan wrote:
>>> BTW, I'm not speaking about my employer's SBCs in part= icular - I
>>> actually have no idea what we'll do with an UP bundle-only= thing
>>> lying about a port=3D0. =C2=A0We could handle it all correctly= , or tear the
>>> call down later, or call WOPR and tell it to play Global
>>> Thermonuclear War. =C2=A0If something's broken in our impl= ementation,
>>> we'll
> fix it... eventually. =C2=A0I'm more worried about other systems, = from
> vendors who don't attend the IETF; and I'm worried about the p= eople
> who have to run SIP networks, for whom this stuff is not a greenfield.=
>>
>> The thing is: no matter what we do here, it's not going to loo= k 100%
>> like the stuff that came before it. All we can do is look at the >> products we know about, look at the existing published semantics f= or
>> protocol elements, and make educated guesses about what =C2=A0is l= ikely to
>> cause the fewest problems. We *know* that using the same
> port numbers for multiple m-lines causes bad behavior in more than a > few endpoints, so that's out. On the other hand, the semantics of<= br> > port=3D0 are pretty well defined, elicit the exact response we want fo= r
> remote endpoints, and avoid egregiously large port allocations during<= br> > call setup (which is an important goal).
>
> The semantics of using port=3D0 are well defined, as you say - those > semantics are that you MUST NOT use the media. =C2=A0You are changing = those
> semantics, if the far-end supports BUNDLE. =C2=A0You feel it's saf= e to
> change those semantics, because you feel that SDP is only being
> processed by the local and remote endpoints. =C2=A0I'm saying that= 's a
> really bad assumption, because I know that in fact it is not the case.=
>
>
>
>> I think that's a lot more solid set of reasons than the opposi= ng rationale you proffer of "there may or may not be products somewher= e in the world that don't really like this approach," not least of= all because that statement is true of any approach we come =C2=A0up with.<= br> >
> Do you honestly believe that using a port number of 0 in an offer,
> while the answer uses a port number of N, is equally impacting on
> interoperability as using an attribute for capability discovery and > then a second O/A round of the real numbers? =C2=A0C'mon man. You&= #39;ve seen
> the stuff that's out there. =C2=A0The SDP Offer and Answer's m= -line port
> number is used by all kinds of whacky equipment, to determine the
> RTP/RTCP flow information. =C2=A0It's used by passive monitoring s= ystems,
> NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and<= br> > god knows what else. =C2=A0Even just in my own employer, we've got= five
> different types of equipment that look at the the m-line port numbers,=
> only one of which is our SBCs (and we've got multiple flavors of t= hem too, fwiw).
>
> -hadriel
>
>
>
> _______________________________________________
> 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

--047d7bdc0ddae75c3204e38c06c9-- From hadriel.kaplan@oracle.com Fri Aug 9 16:33:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A5821F9A35 for ; Fri, 9 Aug 2013 16:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHW9fBHcFo-T for ; Fri, 9 Aug 2013 16:33:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 08D9021F9B18 for ; Fri, 9 Aug 2013 16:28:15 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r79NSEUa014444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Aug 2013 23:28:15 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79NSDH8001429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 23:28:14 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r79NSDXu012808; Fri, 9 Aug 2013 23:28:13 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 16:28:12 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <520568C9.9010603@cisco.com> Date: Fri, 9 Aug 2013 19:28:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <520568C9.9010603@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: mmusic Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 23:33:07 -0000 Wow. I can kinda understand why they'd say that (interop reasons, = presumably), but that's a big deal. The 3 mechanisms are very = different, with very different architectural and deployment = implications. I have a very hard time believing any of us would truly = implement all three. In fact, I don't truly believe anyone would. So... I hate to do this, but can the authors summarize the history of = how we got 3 mechanisms to begin with, and who would really implement = them all? Or to put it another way, instead of specifying all 3, would it be = impossible to take a step back and reconsider the real motivating = use-case (which as far as I know is 3GPP), and only specify the one they = need/use? -hadriel On Aug 9, 2013, at 6:10 PM, Flemming Andreasen = wrote: > Greetings MMUSIC >=20 > As you can see per the below, the IESG approved the Circuit-Switched = Bearers draft for publication, however before doing so, they requested a = couple of changes. The resulting approved document can be found at = http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21 >=20 > One of the changes introduced resulted in all 3 correlation mechanisms = now being mandatory-to-implement (previously they were not): > > Implementations MUST support the three correlation mechanisms > specified in=20 > Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4 > , > and SHOULD include all supported mechanisms the initial Offer. >=20 > > Since this is a non-trivial change that has not been discussed by the = WG (and we know of at least one person having expressed concerns with it = off-line), we are hereby solicting the WG participants for input on = changes introduced as a result of the IESG review with a focus on the = above. In doing so, please keep in mind that we are developing standards = that work in the general Internet.=20 >=20 >=20 > The following URL provides a diff-file showing the changes resulting = from the IESG review: > = http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sdp-cs-18.txt&url2=3D= draft-ietf-mmusic-sdp-cs-21.txt >=20 > Comments are due by August 23 (two weeks from today) >=20 > Thanks=20 >=20 > -- Flemming (MMUSIC co-chair) >=20 >=20 >=20 > -------- Original Message -------- > Subject: [MMUSIC] Protocol Action: 'Session Description Protocol = (SDP) Extension For Setting Audio and Video Media Streams Over = Circuit-Switched Bearers In The Public Switched Telephone Network = (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt) > Date: Mon, 1 Jul 2013 11:56:23 -0700 > From: The IESG > To: IETF-Announce > CC: mmusic chair , mmusic mailing list = , RFC Editor >=20 > The IESG has approved the following document: > - 'Session Description Protocol (SDP) Extension For Setting Audio and > Video Media Streams Over Circuit-Switched Bearers In The Public > Switched Telephone Network (PSTN)' > (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard >=20 > This document is the product of the Multiparty Multimedia Session = Control > Working Group. >=20 > The IESG contact persons are Gonzalo Camarillo and Richard Barnes. >=20 > A URL of this Internet Draft is: >=20 > http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >=20 >=20 >=20 >=20 >=20 > *Technical Summary > * >=20 > The document describes use cases, requirements, and protocol = extensions > for using the Session Description Protocol (SDP) Offer/Answer model = for > establishing audio and video media streams over circuit-switched = bearers > in the Publich Switched Telephone Network (PSTN) >=20 > *Working Group Summary > * >=20 > The WG had some discussion around the format to use for E.164 numbers > and whether to align this with the existing definition in RFC 3108. = The > RFC 3108 definition was seen as deficient and the WG agreed it was > better to align with relevant parts of the tel URI format defined in = RFC > 3966, not least since SDP address types are defined in the context of = a > particular network type, and hence RFC 3108 compatibility is not a > concern (the implication is that the "E164" address type may differ > between network types in SDP). >=20 > *Document Quality > * >=20 > There are currently no known implementations of the draft, however the > draft is a dependency for 3GPP, so future implementations are = expected. >=20 > The document has received good overall review in the WG, some of which > resulted in changes to the detailed specification. The document has = been > reviewed in detail several times, including of the last few versions. > The major contributors to these as well as earlier discussions are > listed in the Acknowledgements section of the document. >=20 >=20 > *Personnel > * >=20 > Document Shepherd: Flemming Andreasen > Responsible AD: Gonzalo Camarillo=20 > _______________________________________________ > mmusic mailing list >=20 > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 > . >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Aug 9 16:42:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B1721F9E40 for ; Fri, 9 Aug 2013 16:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 516-JJS3CZ1X for ; Fri, 9 Aug 2013 16:42:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B1E6111E8129 for ; Fri, 9 Aug 2013 16:36:14 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-23-52057cec65bb Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 71.A6.05990.CEC75025; Sat, 10 Aug 2013 01:36:12 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.241]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Sat, 10 Aug 2013 01:36:12 +0200 From: Christer Holmberg To: Justin Uberti Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712YAAqfkAgABUDKCAABnkgIAAIrhg Date: Fri, 9 Aug 2013 23:36:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvre6bGtYggyMfpS22ThWymLr8MYvF ig0HWB2YPf6+/8DksWBTqceSJT+ZApijuGxSUnMyy1KL9O0SuDKW3zjFWnDEseL7i5/MDYxv 7LsYOTkkBEwkNs56wQZhi0lcuLceyObiEBI4zCjxdfESdghnCaPEukWnWboYOTjYBCwkuv9p gzSICKhJPJy1ixXEZhbwlXi54AszSImwQJjE/pcRECXhEoc/bGMCGSMiMA1o5uspzCAJFgEV iQvzJzCC1PMC9bb3q0Ksussm0fLgFCNIDadAoETHs1tgxzECHff91BomiF3iEh8OXmeGOFpA Ysme81C2qMTLx/9YIWwlicYlT1hB5jMLaEqs36UP0aooMaX7ITuIzSsgKHFy5hOWCYxis5BM nYXQMQtJxywkHQsYWVYxsucmZuaklxttYgTGy8Etv1V3MN45J3KIUZqDRUmcd7PemUAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjJ2sag1m30xLA4O75l9qWPthuofQ7XcTeW5YJovnGTGe DC3WFUiZeKLv8tEII8cl4U13ujfKvhDMtsz2EDo0cdpj1ks9erFJdoq33j7vDN9htLJZVmrK xdyvGy3OK4X+D/l67M714g8/1WImFGuxH4hsFMlq2dJht9Xs4IqyTNcnra2P34T7KLEUZyQa ajEXFScCAP0B2gxlAgAA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 23:42:37 -0000 SGkgSnVzdGluLA0KDQo+IFJlcXVpcmluZyBhIHNlY29uZCBvZmZlciB0byBhZGQgdGhlIGJ1bmRs ZS1vbmx5IG0tbGluZXMgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBidW5kbGUtb25seS4NCg0KV2Ug YWxyZWFkeSByZXF1aXJlIGEgc2Vjb25kIG9mZmVyLiBJIGtub3cgdGhhdCBzb21lIHBlb3BsZSwg aW5jbHVkaW5nIHlvdXJzZWxmLCB3YW50IHRvIGNoYW5nZSB0aGF0LCBidXQgdGhhdCBpcyBub3Ro aW5nIHdlIGhhdmUgYWdyZWVkIG9uLiANCg0KPiBhKSBUaGUgZGVsYXkgdG8gZG8gYW4gTy9BIHdp bGwgb2Z0ZW4gZXhjZWVkIHRoZSB0aW1lIHRvIGFsbG9jYXRlIGNhbmRpZGF0ZXMsIGZvciBzbWFs bCBudW1iZXJzIG9mIHN0cmVhbXM7IGJ1bmRsZS1vbmx5IHdhcyBtZWFudCB0byBhdm9pZCB0aGlz IGNhbmRpZGF0ZSBsYXRlbmN5Lg0KDQpZb3UgZG8gbm90IGhhdmUgdG8gYWxsb2NhdGUgcG9ydHMg Zm9yIHRoZSBidW5kbGUtb25seSBtLSBsaW5lcy4NCg0KPiBiKSBPbmNlIHlvdSBoYXZlIHRoZSBp bml0aWFsIGFuc3dlciwgeW91IGtub3cgd2hldGhlciB0aGUgb3RoZXIgc2lkZSBzdXBwb3J0cyBC VU5ETEUsIHNvIHlvdSBjYW4gdGFrZSB0aGUgYXBwcm9wcmlhdGUgYWN0aW9uIChhbmQgc28gdGhl cmUgaXMgbm8gbmVlZCBmb3IgYnVuZGxlLW9ubHkpLg0KPg0KPiBJZiBTSVAgY2FuJ3QgZGVhbCB3 aXRoIHRoZSBidW5kbGUtb25seSBjb25jZXB0LCB0aGVuIFdlYlJUQyBhcHBzIHRoYXQgY2FyZSBh Ym91dCBsYXRlbmN5IHdpbGwgaGF2ZSB0byBkZWNpZGUgd2hldGhlciB0aGV5IGFyZSBydW5uaW5n IGluIFdlYlJUQy1vbmx5IG1vZGUgb3IgY29tcGF0aWJpbGl0eSBtb2RlLiBJbiBXZWJSVEMtb25s eSBtb2RlLCBzdHJlYW1zIHdpbGwgYmUgYnVuZGxlZCBpbiB0aGUgaW5pdGlhbCBvZmZlcjsgaW4g Y29tcGF0aWJpbGl0eSBtb2RlLCAyIG9mZmVyLWFuc3dlcnMgd2lsbCBiZSBuZWVkZWQuDQoNClRo ZXJlIGFyZSBubyAibW9kZXMiIGluIEJVTkRMRSB0b2RheSA6KQ0KDQo+IFRoaXMgd291bGQgYmUg YSBzb21ld2hhdCB1bmZvcnR1bmF0ZSBvdXRjb21lLCBzbyBJJ2QgbGlrZSB0byBzZWUgYnVuZGxl LW9ubHkgKG9yIHNvbWV0aGluZyBsaWtlIGl0KSB3b3JrLg0KDQpJIGRvbid0IHRoaW5rIHRoZSBz ZWNvbmQgb2ZmZXIgaXMgZ29pbmcgdG8gY2F1c2UgYW55IGxhdGVuY3kuIEFsc28sIGtlZXAgaW4g bWluZCB0aGF0IHlvdSBvbmx5IG5lZWQgdGhlIDJuZCBPZmZlci9BbnN3ZXIgZHVyaW5nIHRoZSBz ZXNzaW9uIGVzdGFibGlzaG1lbnQuIEFzIGFncmVlZCBpbiBCZXJsaW4sIGluIG1pZC1zZXNzaW9u IGNoYW5nZXMgeW91IGRvIE5PVCBuZWVkIDIgb2ZmZXIvYW5zd2Vycy4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCg0KDQpPbiBGcmksIEF1ZyA5LCAyMDEzIGF0IDEyOjQ5IFBNLCBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCkhp LA0KLA0KPj4gQW4gYWx0ZXJuYXRpdmUgd2F5LCB1c2luZyBCVU5ETEUgYXMgY3VycmVudGx5IHNw ZWNpZmllZCwgaXMgdGhlIGFkZA0KPj4gdGhlIGJ1bmRsZS1vbmx5IG0tIGxpbmVzIGluIGEgc3Vi c2VxdWVudCBPZmZlciwgb25jZSBCVU5ETEUgdXNhZ2UgaGFzDQo+PiBiZWVuIG5lZ290aWF0ZWQu IFRoZW4gb25lIGRvZXMgbm90IG5lZWQgcG9ydCB6ZXJvLiBPZiBjb3Vyc2UsIHRoYXQNCj4+IHdv dWxkIGEgInRoaXJkIiBPZmZlciAodGVjaG5pY2FsbHkgaXQgY291bGQgYmUgZG9uZSBhbHJlYWR5 IGluIHRoZSAic2Vjb25kIg0KPj4gT2ZmZXIsIGJ1dCBCVU5ETEUgcmVjb21tZW5kcyBhZ2FpbnN0 IHRoYXQpLg0KPg0KPiBJIHF1aXRlIGxpa2UgdGhpcywgYnV0IHByZWZlciB0aGF0IGl0IGJlIGFs bG93ZWQgaW4gdGhlIDJuZCBPL0EuDQo+IEl0IGlzIGNvbnNpc3RlbnQgd2l0aCBteSBkZXNpcmUg dG8gbWFrZSBtYW55IG9mIHRoZXNlICJydWxlcyIgYSBiaXQgbW9yZSBsZW5pZW50Lg0KPg0KPiBJ ZiBkb25lIGluIHRoZSAybmQgTy9BLCB3aGljaCBpcyByZXF1aXJlZCBhbnl3YXksIHRoZW4gdGhh dCBzaG91bGQgZWxpbWluYXRlIG11Y2ggKG5vdCBhbGwpIG9mIHRoZSBvYmplY3Rpb25zIHRoYXQg YXJlIGxpa2VseSB0byBjb21lIGZyb20gUlRDV0VCLg0KWWVzLg0KDQpBbmQsIHRoZSAybmQgTy9B IHNob3VsZCBiZSBmaW5lLCBhcyB0aGUgbmV3IGJ1bmRsZS1vbmx5IG0tIGxpbmVzIGNhbiBiZSBy ZWplY3RlZCAodXNpbmcgcG9ydCB6ZXJvIGluIHRoZSBBbnN3ZXIpIHdpdGhvdXQgaGF2aW5nIHRv IHJlamVjdCB0aGUgd2hvbGUgT2ZmZXIgKGkuZS4gaXQgd29uJ3QgYWZmZWN0IHRoZSAicG9ydCBz eW5jaHJvbml6YXRpb24iIG9mIHRoZSBvdGhlciBtLSBsaW5lcyBpbiB0aGUgT2ZmZXIpLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KPiBTZW50IGZyb20gKi9XaW5kb3dzLyog dXNpbmcgKlRvdWNoRG93biogKHd3dy5uaXRyb2Rlc2suY29tKQ0KPg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiAqRnJvbToqIEhhZHJpZWwgS2FwbGFuIFtoYWRyaWVsLmthcGxhbkBv cmFjbGUuY29tXQ0KPiAqVG86KiBBZGFtIFJvYWNoIFthZGFtQG5vc3RydW0uY29tXQ0KPiAqQ0M6 KiBDaHJpc3RlciBIb2xtYmVyZyBbY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXTsgbW11 c2ljDQo+IFttbXVzaWNAaWV0Zi5vcmddDQo+ICpTdWJqZWN0OiogUmU6IFtNTVVTSUNdIEJVTkRM RSBnb2VzIFVQOiBEbyB3ZSBuZWVkIHBvcnQgemVybyBmb3INCj4gYnVuZGxlLW9ubHkgbS0gbGlu ZXM/DQo+DQo+IE9uIEF1ZyA4LCAyMDEzLCBhdCA1OjAyIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5v c3RydW0uY29tPiB3cm90ZToNCj4NCj4+IE9uIDgvOC8xMyAxNTo1MSwgSGFkcmllbCBLYXBsYW4g d3JvdGU6DQo+Pj4gQlRXLCBJJ20gbm90IHNwZWFraW5nIGFib3V0IG15IGVtcGxveWVyJ3MgU0JD cyBpbiBwYXJ0aWN1bGFyIC0gSQ0KPj4+IGFjdHVhbGx5IGhhdmUgbm8gaWRlYSB3aGF0IHdlJ2xs IGRvIHdpdGggYW4gVVAgYnVuZGxlLW9ubHkgdGhpbmcNCj4+PiBseWluZyBhYm91dCBhIHBvcnQ9 MC4gwqBXZSBjb3VsZCBoYW5kbGUgaXQgYWxsIGNvcnJlY3RseSwgb3IgdGVhciB0aGUNCj4+PiBj YWxsIGRvd24gbGF0ZXIsIG9yIGNhbGwgV09QUiBhbmQgdGVsbCBpdCB0byBwbGF5IEdsb2JhbA0K Pj4+IFRoZXJtb251Y2xlYXIgV2FyLiDCoElmIHNvbWV0aGluZydzIGJyb2tlbiBpbiBvdXIgaW1w bGVtZW50YXRpb24sDQo+Pj4gd2UnbGwNCj4gZml4IGl0Li4uIGV2ZW50dWFsbHkuIMKgSSdtIG1v cmUgd29ycmllZCBhYm91dCBvdGhlciBzeXN0ZW1zLCBmcm9tDQo+IHZlbmRvcnMgd2hvIGRvbid0 IGF0dGVuZCB0aGUgSUVURjsgYW5kIEknbSB3b3JyaWVkIGFib3V0IHRoZSBwZW9wbGUNCj4gd2hv IGhhdmUgdG8gcnVuIFNJUCBuZXR3b3JrcywgZm9yIHdob20gdGhpcyBzdHVmZiBpcyBub3QgYSBn cmVlbmZpZWxkLg0KPj4NCj4+IFRoZSB0aGluZyBpczogbm8gbWF0dGVyIHdoYXQgd2UgZG8gaGVy ZSwgaXQncyBub3QgZ29pbmcgdG8gbG9vayAxMDAlDQo+PiBsaWtlIHRoZSBzdHVmZiB0aGF0IGNh bWUgYmVmb3JlIGl0LiBBbGwgd2UgY2FuIGRvIGlzIGxvb2sgYXQgdGhlDQo+PiBwcm9kdWN0cyB3 ZSBrbm93IGFib3V0LCBsb29rIGF0IHRoZSBleGlzdGluZyBwdWJsaXNoZWQgc2VtYW50aWNzIGZv cg0KPj4gcHJvdG9jb2wgZWxlbWVudHMsIGFuZCBtYWtlIGVkdWNhdGVkIGd1ZXNzZXMgYWJvdXQg d2hhdCDCoGlzIGxpa2VseSB0bw0KPj4gY2F1c2UgdGhlIGZld2VzdCBwcm9ibGVtcy4gV2UgKmtu b3cqIHRoYXQgdXNpbmcgdGhlIHNhbWUNCj4gcG9ydCBudW1iZXJzIGZvciBtdWx0aXBsZSBtLWxp bmVzIGNhdXNlcyBiYWQgYmVoYXZpb3IgaW4gbW9yZSB0aGFuIGENCj4gZmV3IGVuZHBvaW50cywg c28gdGhhdCdzIG91dC4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSBzZW1hbnRpY3Mgb2YNCj4gcG9y dD0wIGFyZSBwcmV0dHkgd2VsbCBkZWZpbmVkLCBlbGljaXQgdGhlIGV4YWN0IHJlc3BvbnNlIHdl IHdhbnQgZm9yDQo+IHJlbW90ZSBlbmRwb2ludHMsIGFuZCBhdm9pZCBlZ3JlZ2lvdXNseSBsYXJn ZSBwb3J0IGFsbG9jYXRpb25zIGR1cmluZw0KPiBjYWxsIHNldHVwICh3aGljaCBpcyBhbiBpbXBv cnRhbnQgZ29hbCkuDQo+DQo+IFRoZSBzZW1hbnRpY3Mgb2YgdXNpbmcgcG9ydD0wIGFyZSB3ZWxs IGRlZmluZWQsIGFzIHlvdSBzYXkgLSB0aG9zZQ0KPiBzZW1hbnRpY3MgYXJlIHRoYXQgeW91IE1V U1QgTk9UIHVzZSB0aGUgbWVkaWEuIMKgWW91IGFyZSBjaGFuZ2luZyB0aG9zZQ0KPiBzZW1hbnRp Y3MsIGlmIHRoZSBmYXItZW5kIHN1cHBvcnRzIEJVTkRMRS4gwqBZb3UgZmVlbCBpdCdzIHNhZmUg dG8NCj4gY2hhbmdlIHRob3NlIHNlbWFudGljcywgYmVjYXVzZSB5b3UgZmVlbCB0aGF0IFNEUCBp cyBvbmx5IGJlaW5nDQo+IHByb2Nlc3NlZCBieSB0aGUgbG9jYWwgYW5kIHJlbW90ZSBlbmRwb2lu dHMuIMKgSSdtIHNheWluZyB0aGF0J3MgYQ0KPiByZWFsbHkgYmFkIGFzc3VtcHRpb24sIGJlY2F1 c2UgSSBrbm93IHRoYXQgaW4gZmFjdCBpdCBpcyBub3QgdGhlIGNhc2UuDQo+DQo+DQo+DQo+PiBJ IHRoaW5rIHRoYXQncyBhIGxvdCBtb3JlIHNvbGlkIHNldCBvZiByZWFzb25zIHRoYW4gdGhlIG9w cG9zaW5nIHJhdGlvbmFsZSB5b3UgcHJvZmZlciBvZiAidGhlcmUgbWF5IG9yIG1heSBub3QgYmUg cHJvZHVjdHMgc29tZXdoZXJlIGluIHRoZSB3b3JsZCB0aGF0IGRvbid0IHJlYWxseSBsaWtlIHRo aXMgYXBwcm9hY2gsIiBub3QgbGVhc3Qgb2YgYWxsIGJlY2F1c2UgdGhhdCBzdGF0ZW1lbnQgaXMg dHJ1ZSBvZiBhbnkgYXBwcm9hY2ggd2UgY29tZSDCoHVwIHdpdGguDQo+DQo+IERvIHlvdSBob25l c3RseSBiZWxpZXZlIHRoYXQgdXNpbmcgYSBwb3J0IG51bWJlciBvZiAwIGluIGFuIG9mZmVyLA0K PiB3aGlsZSB0aGUgYW5zd2VyIHVzZXMgYSBwb3J0IG51bWJlciBvZiBOLCBpcyBlcXVhbGx5IGlt cGFjdGluZyBvbg0KPiBpbnRlcm9wZXJhYmlsaXR5IGFzIHVzaW5nIGFuIGF0dHJpYnV0ZSBmb3Ig Y2FwYWJpbGl0eSBkaXNjb3ZlcnkgYW5kDQo+IHRoZW4gYSBzZWNvbmQgTy9BIHJvdW5kIG9mIHRo ZSByZWFsIG51bWJlcnM/IMKgQydtb24gbWFuLiBZb3UndmUgc2Vlbg0KPiB0aGUgc3R1ZmYgdGhh dCdzIG91dCB0aGVyZS4gwqBUaGUgU0RQIE9mZmVyIGFuZCBBbnN3ZXIncyBtLWxpbmUgcG9ydA0K PiBudW1iZXIgaXMgdXNlZCBieSBhbGwga2luZHMgb2Ygd2hhY2t5IGVxdWlwbWVudCwgdG8gZGV0 ZXJtaW5lIHRoZQ0KPiBSVFAvUlRDUCBmbG93IGluZm9ybWF0aW9uLiDCoEl0J3MgdXNlZCBieSBw YXNzaXZlIG1vbml0b3Jpbmcgc3lzdGVtcywNCj4gTkFUcywgQ0dOcywgRmlyZXdhbGxzLCBSb3V0 ZXJzLCBQREdzLCB4LUNTQ0ZzLCBTQkNzLCBBcHAgc2VydmVycywgYW5kDQo+IGdvZCBrbm93cyB3 aGF0IGVsc2UuIMKgRXZlbiBqdXN0IGluIG15IG93biBlbXBsb3llciwgd2UndmUgZ290IGZpdmUN Cj4gZGlmZmVyZW50IHR5cGVzIG9mIGVxdWlwbWVudCB0aGF0IGxvb2sgYXQgdGhlIHRoZSBtLWxp bmUgcG9ydCBudW1iZXJzLA0KPiBvbmx5IG9uZSBvZiB3aGljaCBpcyBvdXIgU0JDcyAoYW5kIHdl J3ZlIGdvdCBtdWx0aXBsZSBmbGF2b3JzIG9mIHRoZW0gdG9vLCBmd2l3KS4NCj4NCj4gLWhhZHJp ZWwNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPiBtbXVzaWNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QN Cm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt bXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== From juberti@google.com Fri Aug 9 17:10:00 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6073B21F9EBE for ; Fri, 9 Aug 2013 17:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLhtCkolTb0O for ; Fri, 9 Aug 2013 17:09:59 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2FED421F9D18 for ; Fri, 9 Aug 2013 17:03:08 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id 9so5198614iec.21 for ; Fri, 09 Aug 2013 17:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7HeGD7x/advtNt0ahf1cqNW1h8uE5U3wGDiLOeZTwh8=; b=l37S+3DZruAZao26+HOyOaCdjecnVFtNA2H4SCuGiRwriwNalZ0XUKmOZJze/F9YjC i0IC59y4fh/zZUTM1Xh/m+WI49jCnAEwPApYD+wrCw08hf05sld7UcD6RaazQTgPyLWy TBsFn36MvZpGtQQhiG+ocGOf5TrDelyUTn6JskXspfEIku1htkPmLrkBzslNdlMBFaNm HN9ZCKeAzNcnGvtvPsqtYKuZ+J3ST/hrp/VWhFfNov9PInlGT8F9pB1sC1fNcqLkPrbz w+ci39gmeCOvVzThvDK1pAyF5rWlURFaxGePXVTT4Vi9QqskBdirueBFttiebC8eea1M C9xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7HeGD7x/advtNt0ahf1cqNW1h8uE5U3wGDiLOeZTwh8=; b=oLn5ZR529muqsXHtT1xolkK21cLYQDMGbWq8wQws7SkdP3upw9f4ZJY1m6Cnplfa/Q XbDc72zaGquLvwdUoZAvd+GORzOPypOMvviKa7p1wxsgWRMj8TYUrEnav9bTfu4GTKFP deaxaNy1sm9Rbp293I5HG5OZRCnNQj4a8uceWJUtQCJ8n//wNXkfdmrhe2WrTjNTzraD ny7fFV5MPVh37ePt06Nk1rVQRVTzK9EcGPrLkxbGC04DYD8WzM9XZOGMeTERVTA90oxO QaKPFrGVpeRk9YvLaJbadYrONHJIaMpRxUjVC0Vkw8XVGGyw2PLpJmTtoyKPL2i5Oilz 5mFQ== X-Gm-Message-State: ALoCoQm00AvaW58ndztS0wCohC2OfSxElVqtMOhSSnsjwI7Eh9u9xlyli/+5xundnkWXZZDhTxDcbTF/c3PfLKf63tauctpV0tpGwpyELcyFAvP5MWZTxdR/7Fvwwk/pb5Zrzy0sp7sQUJCF7F1T17tudAi8UM6BHlQDHAwShHRuVKGWW/AXGfjp2NhoCy9IbV6wAezkaFrj X-Received: by 10.50.73.41 with SMTP id i9mr2863917igv.30.1376092986297; Fri, 09 Aug 2013 17:03:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Fri, 9 Aug 2013 17:02:46 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> From: Justin Uberti Date: Fri, 9 Aug 2013 17:02:46 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013a0270a06c0204e38c9d3a Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:10:00 -0000 --089e013a0270a06c0204e38c9d3a Content-Type: text/plain; charset=UTF-8 On Fri, Aug 9, 2013 at 4:36 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Justin, > > > Requiring a second offer to add the bundle-only m-lines defeats the > purpose of bundle-only. > > We already require a second offer. I know that some people, including > yourself, want to change that, but that is nothing we have agreed on. > > > a) The delay to do an O/A will often exceed the time to allocate > candidates, for small numbers of streams; bundle-only was meant to avoid > this candidate latency. > > You do not have to allocate ports for the bundle-only m- lines. > > b) Once you have the initial answer, you know whether the other side > supports BUNDLE, so you can take the appropriate action (and so there is no > need for bundle-only). > > > > If SIP can't deal with the bundle-only concept, then WebRTC apps that > care about latency will have to decide whether they are running in > WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will > be bundled in the initial offer; in compatibility mode, 2 offer-answers > will be needed. > > There are no "modes" in BUNDLE today :) > Of course there are. The handling in a reinvite case is distinct from the initial offer, so that is modal behavior. > > > This would be a somewhat unfortunate outcome, so I'd like to see > bundle-only (or something like it) work. > > I don't think the second offer is going to cause any latency. Also, keep > in mind that you only need the 2nd Offer/Answer during the session > establishment. As agreed in Berlin, in mid-session changes you do NOT need > 2 offer/answers. > Please provide support for this statement. It seems clear that a 2nd offer adds _at least_ 1 RTT latency. > > Regards, > > Christer > > > > > > On Fri, Aug 9, 2013 at 12:49 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > Hi, > , > >> An alternative way, using BUNDLE as currently specified, is the add > >> the bundle-only m- lines in a subsequent Offer, once BUNDLE usage has > >> been negotiated. Then one does not need port zero. Of course, that > >> would a "third" Offer (technically it could be done already in the > "second" > >> Offer, but BUNDLE recommends against that). > > > > I quite like this, but prefer that it be allowed in the 2nd O/A. > > It is consistent with my desire to make many of these "rules" a bit more > lenient. > > > > If done in the 2nd O/A, which is required anyway, then that should > eliminate much (not all) of the objections that are likely to come from > RTCWEB. > Yes. > > And, the 2nd O/A should be fine, as the new bundle-only m- lines can be > rejected (using port zero in the Answer) without having to reject the whole > Offer (i.e. it won't affect the "port synchronization" of the other m- > lines in the Offer). > > Regards, > > Christer > > > > > > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > > > -----Original Message----- > > *From:* Hadriel Kaplan [hadriel.kaplan@oracle.com] > > *To:* Adam Roach [adam@nostrum.com] > > *CC:* Christer Holmberg [christer.holmberg@ericsson.com]; mmusic > > [mmusic@ietf.org] > > *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for > > bundle-only m- lines? > > > > On Aug 8, 2013, at 5:02 PM, Adam Roach wrote: > > > >> On 8/8/13 15:51, Hadriel Kaplan wrote: > >>> BTW, I'm not speaking about my employer's SBCs in particular - I > >>> actually have no idea what we'll do with an UP bundle-only thing > >>> lying about a port=0. We could handle it all correctly, or tear the > >>> call down later, or call WOPR and tell it to play Global > >>> Thermonuclear War. If something's broken in our implementation, > >>> we'll > > fix it... eventually. I'm more worried about other systems, from > > vendors who don't attend the IETF; and I'm worried about the people > > who have to run SIP networks, for whom this stuff is not a greenfield. > >> > >> The thing is: no matter what we do here, it's not going to look 100% > >> like the stuff that came before it. All we can do is look at the > >> products we know about, look at the existing published semantics for > >> protocol elements, and make educated guesses about what is likely to > >> cause the fewest problems. We *know* that using the same > > port numbers for multiple m-lines causes bad behavior in more than a > > few endpoints, so that's out. On the other hand, the semantics of > > port=0 are pretty well defined, elicit the exact response we want for > > remote endpoints, and avoid egregiously large port allocations during > > call setup (which is an important goal). > > > > The semantics of using port=0 are well defined, as you say - those > > semantics are that you MUST NOT use the media. You are changing those > > semantics, if the far-end supports BUNDLE. You feel it's safe to > > change those semantics, because you feel that SDP is only being > > processed by the local and remote endpoints. I'm saying that's a > > really bad assumption, because I know that in fact it is not the case. > > > > > > > >> I think that's a lot more solid set of reasons than the opposing > rationale you proffer of "there may or may not be products somewhere in the > world that don't really like this approach," not least of all because that > statement is true of any approach we come up with. > > > > Do you honestly believe that using a port number of 0 in an offer, > > while the answer uses a port number of N, is equally impacting on > > interoperability as using an attribute for capability discovery and > > then a second O/A round of the real numbers? C'mon man. You've seen > > the stuff that's out there. The SDP Offer and Answer's m-line port > > number is used by all kinds of whacky equipment, to determine the > > RTP/RTCP flow information. It's used by passive monitoring systems, > > NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and > > god knows what else. Even just in my own employer, we've got five > > different types of equipment that look at the the m-line port numbers, > > only one of which is our SBCs (and we've got multiple flavors of them > too, fwiw). > > > > -hadriel > > > > > > > > _______________________________________________ > > 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 > > --089e013a0270a06c0204e38c9d3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 9, 2013 at 4:36 PM, Christer Holmberg <ch= rister.holmberg@ericsson.com> wrote:
Hi Justin,

> Requiring a second offer to add the bundle-only m-lines defeats the pu= rpose of bundle-only.

We already require a second offer. I know that some people, including= yourself, want to change that, but that is nothing we have agreed on.

> a) The delay to do an O/A will often exceed the time to allocate candi= dates, for small numbers of streams; bundle-only was meant to avoid this ca= ndidate latency.

You do not have to allocate ports for the bundle-only m- lines.=C2=A0=

> b) Once you have the initial answer, you know whether the other side s= upports BUNDLE, so you can take the appropriate action (and so there is no = need for bundle-only).
>
> If SIP can't deal with the bundle-only concept, then WebRTC apps t= hat care about latency will have to decide whether they are running in WebR= TC-only mode or compatibility mode. In WebRTC-only mode, streams will be bu= ndled in the initial offer; in compatibility mode, 2 offer-answers will be = needed.

There are no "modes" in BUNDLE today :)

Of course there are. The handling in a reinvite case is di= stinct from the initial offer, so that is modal behavior.=C2=A0

> This would be a somewhat unfortunate outcome, so I'd like to see b= undle-only (or something like it) work.

I don't think the second offer is going to cause any latency. Als= o, keep in mind that you only need the 2nd Offer/Answer during the session = establishment. As agreed in Berlin, in mid-session changes you do NOT need = 2 offer/answers.

Please provide support for this statement.= It seems clear that a 2nd offer adds _at least_ 1 RTT latency.=C2=A0
=

Regards,

Christer





On Fri, Aug 9, 2013 at 12:49 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:=
Hi,
,
>> An alternative way, using BUNDLE as currently specified, is the ad= d
>> the bundle-only m- lines in a subsequent Offer, once BUNDLE usage = has
>> been negotiated. Then one does not need port zero. Of course, that=
>> would a "third" Offer (technically it could be done alre= ady in the "second"
>> Offer, but BUNDLE recommends against that).
>
> I quite like this, but prefer that it be allowed in the 2nd O/A.
> It is consistent with my desire to make many of these "rules"= ; a bit more lenient.
>
> If done in the 2nd O/A, which is required anyway, then that should eli= minate much (not all) of the objections that are likely to come from RTCWEB= .
Yes.

And, the 2nd O/A should be fine, as the new bundle-only m- lines can be rej= ected (using port zero in the Answer) without having to reject the whole Of= fer (i.e. it won't affect the "port synchronization" of the o= ther m- lines in the Offer).

Regards,

Christer






> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> -----Original Message-----
> *From:* Hadriel Kaplan [h= adriel.kaplan@oracle.com]
> *To:* Adam Roach [adam@nostrum.com= ]
> *CC:* Christer Holmberg [christer.holmberg@ericsson.com]; mmusic
> [mmusic@ietf.org]
> *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for
> bundle-only m- lines?
>
> On Aug 8, 2013, at 5:02 PM, Adam Roach <adam@nostrum.com> wrote:
>
>> On 8/8/13 15:51, Hadriel Kaplan wrote:
>>> BTW, I'm not speaking about my employer's SBCs in part= icular - I
>>> actually have no idea what we'll do with an UP bundle-only= thing
>>> lying about a port=3D0. =C2=A0We could handle it all correctly= , or tear the
>>> call down later, or call WOPR and tell it to play Global
>>> Thermonuclear War. =C2=A0If something's broken in our impl= ementation,
>>> we'll
> fix it... eventually. =C2=A0I'm more worried about other systems, = from
> vendors who don't attend the IETF; and I'm worried about the p= eople
> who have to run SIP networks, for whom this stuff is not a greenfield.=
>>
>> The thing is: no matter what we do here, it's not going to loo= k 100%
>> like the stuff that came before it. All we can do is look at the >> products we know about, look at the existing published semantics f= or
>> protocol elements, and make educated guesses about what =C2=A0is l= ikely to
>> cause the fewest problems. We *know* that using the same
> port numbers for multiple m-lines causes bad behavior in more than a > few endpoints, so that's out. On the other hand, the semantics of<= br> > port=3D0 are pretty well defined, elicit the exact response we want fo= r
> remote endpoints, and avoid egregiously large port allocations during<= br> > call setup (which is an important goal).
>
> The semantics of using port=3D0 are well defined, as you say - those > semantics are that you MUST NOT use the media. =C2=A0You are changing = those
> semantics, if the far-end supports BUNDLE. =C2=A0You feel it's saf= e to
> change those semantics, because you feel that SDP is only being
> processed by the local and remote endpoints. =C2=A0I'm saying that= 's a
> really bad assumption, because I know that in fact it is not the case.=
>
>
>
>> I think that's a lot more solid set of reasons than the opposi= ng rationale you proffer of "there may or may not be products somewher= e in the world that don't really like this approach," not least of= all because that statement is true of any approach we come =C2=A0up with.<= br> >
> Do you honestly believe that using a port number of 0 in an offer,
> while the answer uses a port number of N, is equally impacting on
> interoperability as using an attribute for capability discovery and > then a second O/A round of the real numbers? =C2=A0C'mon man. You&= #39;ve seen
> the stuff that's out there. =C2=A0The SDP Offer and Answer's m= -line port
> number is used by all kinds of whacky equipment, to determine the
> RTP/RTCP flow information. =C2=A0It's used by passive monitoring s= ystems,
> NATs, CGNs, Firewalls, Routers, PDGs, x-CSCFs, SBCs, App servers, and<= br> > god knows what else. =C2=A0Even just in my own employer, we've got= five
> different types of equipment that look at the the m-line port numbers,=
> only one of which is our SBCs (and we've got multiple flavors of t= hem too, fwiw).
>
> -hadriel
>
>
>
> _______________________________________________
> 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


--089e013a0270a06c0204e38c9d3a-- From hadriel.kaplan@oracle.com Fri Aug 9 17:18:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CC221F9A2A for ; Fri, 9 Aug 2013 17:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, J_BACKHAIR_27=1, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy7HbPV5CdRB for ; Fri, 9 Aug 2013 17:18:14 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E725A21F99E7 for ; Fri, 9 Aug 2013 17:13:11 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7A0DAPR031302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Aug 2013 00:13:10 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7A0D9YP006809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Aug 2013 00:13:09 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7A0D8D7004990; Sat, 10 Aug 2013 00:13:08 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Aug 2013 17:13:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Fri, 9 Aug 2013 20:13:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <24FAAB9F-D014-4B84-BE41-91D43E5604DD@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> To: Justin Uberti X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:18:21 -0000 On Aug 9, 2013, at 7:20 PM, Justin Uberti wrote: > Requiring a second offer to add the bundle-only m-lines defeats the = purpose of bundle-only. > a) The delay to do an O/A will often exceed the time to allocate = candidates, for small numbers of streams; bundle-only was meant to avoid = this candidate latency. You lost me - I thought the "bundle-only" lines do not use their own = transport, and instead require a regular "bundle" line to use its = transport info. Afaict, that means the bundle-only have no candidates. = No? (or I could be misunderstanding your point) We're really only talking about the bundle-only lines in this = discussion, I think. > b) Once you have the initial answer, you know whether the other side = supports BUNDLE, so you can take the appropriate action (and so there is = no need for bundle-only). >=20 Christer's proposal is to send the regular m-lines, including regular = bundle m-lines, in the initial Offer. The Answer comes back for those, = and tells you if the far-end does bundle. You then send another Offer, = with more *bundle* m-lines. There is no "bundle-only" needed anymore. > If SIP can't deal with the bundle-only concept, then WebRTC apps that = care about latency will have to decide whether they are running in = WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams = will be bundled in the initial offer; in compatibility mode, 2 = offer-answers will be needed. Sure, that's WebRTC's decision. Certainly for a JS<->Browser API, doing = 2 offer-answers seems silly to me. I don't know what you mean by "compatibility" mode. What is a = JS<->Browser API that's *not* "WebRTC-only" mode? Shouldn't a Browser = just always be in "WebRTC" mode? If some specific *application* needs = to do something else, I would think that's what JavaScript is for. Wasn't the premise supposed to be WebRTC does the basic things by = default in SDP to make simple things easy to write in JS; but lets the = advanced applications be possible by munging SDP and doing other things = in JS? Surely an application developer who wishes to interface to = SIP-land for more than just the basic audio+video calls can figure out = how to write some Javascript to do a double offer/answer, no? -hadriel From juberti@google.com Fri Aug 9 17:48:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7269C21F9C40 for ; Fri, 9 Aug 2013 17:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_27=1, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyCl3tN3Ba45 for ; Fri, 9 Aug 2013 17:48:05 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DF48821F9C87 for ; Fri, 9 Aug 2013 17:42:24 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k5so5223792iea.4 for ; Fri, 09 Aug 2013 17:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s3mxonHFhY5Z5/2C3t3v9uhINv3C03RcKvEly46/NjA=; b=ZlZpK3fk1bRhNgZ6oDl+hh1pOAkHv8REkRQN2KQojLr88WISUu7DwQHa6DCY/zEmBo oZI7O/fabKjE4goQ9O5TufbKtmK4i9V9tCvJWduLePekWFFzwEoWUZV6yG7s9ecz+cbf oxw/uFjqA0cftqUvlzSXMQj9RYX4LA+HxrN041pleGpLQVEbGsoyBz5BwKAVng9w1nKq uecweMTo/cf6bpZbi7/CdqQcyQOKzBUkymTqDeDGEZoNGhzDFkZD5cJzKpjWRcxeLloQ 1K5/cq0nbjI5xkC6T9Vr58aI7NRRhGapUQ/+l+c14dW9whnlpn9CuRImMpOP4+j7y3fV DWVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=s3mxonHFhY5Z5/2C3t3v9uhINv3C03RcKvEly46/NjA=; b=LXnNRM500vilLzvLU+YrRGUCcP9zriYct52B3hmfxeo8HFN3bGxYPeZS0b+P/BRpKy h3tXfudGNvEwzxAk9T7oGnqNkQCA3AwZ6nBXj+JjrnFp95PDBL/gI67us8lNw1F+XqoM vDXyLzQ150e2nR+Jb/4TS5SXlbBVrC295UsSVe78gJTtFKT1fAH0VyA0voker19eZtse eFPTO1FWCdIZM5eppzcl2rHUHYyswPju5RK+N1vk4mv540h59XSmD2Njb11aOdIHcWXn 5qZE2dCOm0LYsOuLkBFpqxMVqpDIvZZamqHCZQa9VA/cnykIao/HzXSB6hwJWDoONEiM ht9Q== X-Gm-Message-State: ALoCoQn7hdGh6GqnGMZgOIsKwwxKYrHh1GbpkUtDy3IyxOJPIHHQYdNmSS260mEYfU1rGptEVStqkK0KtNpdIZlIhoyae4nSmRR8DFnJ4tq57fjwX0hehuY6fAhencBDs9Czlz/Ud5aqTz9Czr+4TiSZdZl1wCc6Sp0zkTMFVtT5pQSOQOS76i6kQyPFW0aSj3/gmWcSL/f/ X-Received: by 10.50.73.41 with SMTP id i9mr2923350igv.30.1376095343133; Fri, 09 Aug 2013 17:42:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Fri, 9 Aug 2013 17:42:03 -0700 (PDT) In-Reply-To: <24FAAB9F-D014-4B84-BE41-91D43E5604DD@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <24FAAB9F-D014-4B84-BE41-91D43E5604DD@oracle.com> From: Justin Uberti Date: Fri, 9 Aug 2013 17:42:03 -0700 Message-ID: To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=089e013a02701ae87404e38d2abc Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:48:06 -0000 --089e013a02701ae87404e38d2abc Content-Type: text/plain; charset=UTF-8 On Fri, Aug 9, 2013 at 5:13 PM, Hadriel Kaplan wrote: > > On Aug 9, 2013, at 7:20 PM, Justin Uberti wrote: > > > Requiring a second offer to add the bundle-only m-lines defeats the > purpose of bundle-only. > > a) The delay to do an O/A will often exceed the time to allocate > candidates, for small numbers of streams; bundle-only was meant to avoid > this candidate latency. > > You lost me - I thought the "bundle-only" lines do not use their own > transport, and instead require a regular "bundle" line to use its transport > info. Afaict, that means the bundle-only have no candidates. No? (or I > could be misunderstanding your point) > > We're really only talking about the bundle-only lines in this discussion, > I think. > I agree with what you are saying - I am just saying the latency effect of the second O/A may be worse than the problem that bundle-only was trying to solve. > > > > b) Once you have the initial answer, you know whether the other side > supports BUNDLE, so you can take the appropriate action (and so there is no > need for bundle-only). > > > > Christer's proposal is to send the regular m-lines, including regular > bundle m-lines, in the initial Offer. The Answer comes back for those, and > tells you if the far-end does bundle. You then send another Offer, with > more *bundle* m-lines. There is no "bundle-only" needed anymore. > Agree - there is no need for bundle-only with 2 O/As. > > > > If SIP can't deal with the bundle-only concept, then WebRTC apps that > care about latency will have to decide whether they are running in > WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will > be bundled in the initial offer; in compatibility mode, 2 offer-answers > will be needed. > > Sure, that's WebRTC's decision. Certainly for a JS<->Browser API, doing 2 > offer-answers seems silly to me. > > I don't know what you mean by "compatibility" mode. What is a > JS<->Browser API that's *not* "WebRTC-only" mode? Shouldn't a Browser just > always be in "WebRTC" mode? If some specific *application* needs to do > something else, I would think that's what JavaScript is for. > > Wasn't the premise supposed to be WebRTC does the basic things by default > in SDP to make simple things easy to write in JS; but lets the advanced > applications be possible by munging SDP and doing other things in JS? > Surely an application developer who wishes to interface to SIP-land for > more than just the basic audio+video calls can figure out how to write some > Javascript to do a double offer/answer, no? There has been resistance to the idea that the app needs to decide if it's interfacing with SIP-land or not. Which is understandable, but perhaps this goal of app agnosticism is unattainable. --089e013a02701ae87404e38d2abc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 9, 2013 at 5:13 PM, Hadriel Kaplan &l= t;hadriel.ka= plan@oracle.com> wrote:

On Aug 9, 2013, at 7:20 PM, Justin Uberti <juberti@google.com> wrote:

> Requiring a second offer to add the bundle-only m-lines defeats the pu= rpose of bundle-only.
> a) The delay to do an O/A will often exceed the time to allocate candi= dates, for small numbers of streams; bundle-only was meant to avoid this ca= ndidate latency.

You lost me - I thought the "bundle-only" lines do not use = their own transport, and instead require a regular "bundle" line = to use its transport info. =C2=A0Afaict, that means the bundle-only have no= candidates. =C2=A0No? =C2=A0(or I could be misunderstanding your point)
We're really only talking about the bundle-only lines in this discussio= n, I think.

I agree with what you are s= aying - I am just saying the latency effect of the second O/A may be worse = than the problem that bundle-only was trying to solve.=C2=A0


> b) Once you have the initial answer, you know whether the other side s= upports BUNDLE, so you can take the appropriate action (and so there is no = need for bundle-only).
>

Christer's proposal is to send the regular m-lines, including reg= ular bundle m-lines, in the initial Offer. =C2=A0The Answer comes back for = those, and tells you if the far-end does bundle. =C2=A0You then send anothe= r Offer, with more *bundle* m-lines. =C2=A0There is no "bundle-only&qu= ot; needed anymore.

Agree - there is no need for bundle-only w= ith 2 O/As.=C2=A0


> If SIP can't deal with the bundle-only concept, then WebRTC apps t= hat care about latency will have to decide whether they are running in WebR= TC-only mode or compatibility mode. In WebRTC-only mode, streams will be bu= ndled in the initial offer; in compatibility mode, 2 offer-answers will be = needed.

Sure, that's WebRTC's decision. =C2=A0Certainly for a JS<-= >Browser API, doing 2 offer-answers seems silly to me.

I don't know what you mean by "compatibility" mode. =C2=A0Wha= t is a JS<->Browser API that's *not* "WebRTC-only" mode= ? =C2=A0Shouldn't a Browser just always be in "WebRTC" mode? = =C2=A0If some specific *application* needs to do something else, I would th= ink that's what JavaScript is for.

Wasn't the premise supposed to be WebRTC does the basic things by defau= lt in SDP to make simple things easy to write in JS; but lets the advanced = applications be possible by munging SDP and doing other things in JS? =C2= =A0Surely an application developer who wishes to interface to SIP-land for = more than just the basic audio+video calls can figure out how to write some= Javascript to do a double offer/answer, no?

There has been resistance to the idea that the app need= s to decide if it's interfacing with SIP-land or not. Which is understa= ndable, but perhaps this goal of app agnosticism is unattainable.
--089e013a02701ae87404e38d2abc-- From partha@parthasarathi.co.in Sat Aug 10 12:12:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABF921F9B94 for ; Sat, 10 Aug 2013 12:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6b+6-Wcp92j for ; Sat, 10 Aug 2013 12:12:49 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id 840E121F9F86 for ; Sat, 10 Aug 2013 12:04:09 -0700 (PDT) Received: from userPC (unknown [122.179.40.18]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 2AE91638E8D; Sat, 10 Aug 2013 19:04:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1376161448; bh=IdLqQQI9xWUWrIyXy0wIiM/1vskelny9e8gLMCEGImY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Qop0nstEs60QmlHe688CjvrViVQTUoLjeFfOFnjzFRWVvlgu7AUR6s8rAvRKhJe7t FJpBO2UkWVx4wRO8kRfdduhdmIKLyO0VFPL/WZvtkps1b/c3lUAtXSayOb+gDJxkWc 1Vc+ZM4/wJB1EUmBPjPggxOnFsXdXYmAeAJa/0zY= From: "Parthasarathi R" To: "'Matthew Kaufman'" , References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C42157D@ESESSMB209.ericsson.se> <52057721.8080207@matthew.at> In-Reply-To: <52057721.8080207@matthew.at> Date: Sun, 11 Aug 2013 00:33:54 +0530 Message-ID: <000201ce95fc$5f1b87a0$1d5296e0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6VVpuQT8sYa0BkSH+ZwwVqBjWeywAoGS6A Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0205.52068EA8.0065, 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: 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-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 19:12:53 -0000 Matthew, I like your argument of "shouldn't be reusing *this* standard for *that* application". I have already mentioned in draft-partha-rtcweb-jsep-sip-00 that SDP usage in WebRTC is making the complication in interworking with SIP. The current Unified plan (UP) is adding fuel to the fire. In case UP plan is not going to work with SIP/RFC 3264 based mechanism, I agree with your statement of "we're doing this "standards" thing wrong". I started thinking the standards are going wrong after the current UP discussion as 1) Some of the web developers are already not interested in current WebRTC SDP (last month Public-webrtc discussion) 2) WebRTC SDP will not be suitable for future SIP based devices as well and not just legacy PSTN/PLMN/Enterprise SIP devices. 3) My guess from your words is that WebRTC SDP is not so useful/flexible for proprietary VoIP apps like Skype. 4) I'm getting the feeling that WebRTC SDP mechanism will work only for Jingle (XMPP based) sort of mechanism and not for anything else. (Disclaimer: I don't know much about Jingle). Having said that, I guess that UP will be updated to work at least with RFC 3264 (offer/answer) requirements and WebRTC SDP shall be reused for SIP application. Thanks Partha PS: CU-WebRTC kind of WebRTC API will be more useful to interop with SIP than current UP based WebRTC API as SDP required for SIP shall be built using JavaScript/another W3C API in case CU-WebRTC kind of API exists. > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Matthew Kaufman > Sent: Saturday, August 10, 2013 4:41 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > > On 8/9/2013 3:35 PM, Justin Uberti wrote: > > That is not my understanding. If we don't care about intermediaries, > > we could have made BUNDLE and UP a lot simpler. > > > > I think the expectation should be that Matthew's proposed case will > > work, modulo any implementation bugs on the remote device. > > > > > I agree. Otherwise we're doing this "standards" thing wrong OR > shouldn't > be reusing *this* standard for *that* application. > > Matthew Kaufman > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Sat Aug 10 15:15:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BD221F9C55 for ; Sat, 10 Aug 2013 15:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-hPbwLZQFhq for ; Sat, 10 Aug 2013 15:15:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 87FB311E8155 for ; Sat, 10 Aug 2013 15:08:38 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-0d-5206b9e4f4f4 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 70.76.03938.4E9B6025; Sun, 11 Aug 2013 00:08:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Sun, 11 Aug 2013 00:08:36 +0200 From: Christer Holmberg To: Justin Uberti Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712YAAqfkAgABUDKCAABnkgIAAIrhg///pDwCAAZH/EA== Date: Sat, 10 Aug 2013 22:08:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C43BA02@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvre6TnWxBBlOPyVlsnSpkMXX5YxaL FRsOsDowe/x9/4HJY8GmUo8lS34yBTBHcdmkpOZklqUW6dslcGU0r+lhL7glXrFlTyt7A2OP eBcjJ4eEgIlET/c7ZghbTOLCvfVsXYxcHEIChxklvuydyQjhLGaUmNf2i6WLkYODTcBCovuf NkiDiICaxMNZu1hBbGYBX4mXC74wg5QIC4RJ7H8ZAVESLnH4wzYmkDEiAssYJXa9O8gGkmAR UJVovDWbHaSeF6i387kvxKoX7BIrX8wFq+EUCJTYvvMeO4jNCHTc91NrmCB2iUt8OHgd6mgB iSV7zkPZohIvH/9jhbCVJBqXPGEFmc8soCmxfpc+RKuixJTuh2AjeQUEJU7OfMIygVFsFpKp sxA6ZiHpmIWkYwEjyypG9tzEzJz0csNNjMB4Objlt+4OxlPnRA4xSnOwKInzbtI7EygkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBMZC9me/Fhz3vnkiWdK6cNet09TGV4N3yIhlW4us2zyi7 8O/P93VNDy+rc3yNO+igzbCsOobPjbnjsJrenuM7Vh7e0rp4Ytc79axX5ruV7CdKHl794YaP yf5QbqEZ7yu+/PHPPqBc90Zvofec2fq7fh/p0DW6u3Cvc/jrfA6li6kt61luy/+8WqvEUpyR aKjFXFScCAAeWyYdZQIAAA== Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 22:15:26 -0000 SGksDQoNCj4+PiBSZXF1aXJpbmcgYSBzZWNvbmQgb2ZmZXIgdG8gYWRkIHRoZSBidW5kbGUtb25s eSBtLWxpbmVzIGRlZmVhdHMgdGhlIHB1cnBvc2Ugb2YgYnVuZGxlLW9ubHkuDQo+PiBXZSBhbHJl YWR5IHJlcXVpcmUgYSBzZWNvbmQgb2ZmZXIuIEkga25vdyB0aGF0IHNvbWUgcGVvcGxlLCBpbmNs dWRpbmcgeW91cnNlbGYsIHdhbnQgdG8gY2hhbmdlIHRoYXQsIGJ1dCB0aGF0IGlzIG5vdGhpbmcg d2UgaGF2ZSBhZ3JlZWQgb24uDQo+Pg0KPj4+IGEpIFRoZSBkZWxheSB0byBkbyBhbiBPL0Egd2ls bCBvZnRlbiBleGNlZWQgdGhlIHRpbWUgdG8gYWxsb2NhdGUgY2FuZGlkYXRlcywgZm9yIHNtYWxs IG51bWJlcnMgb2Ygc3RyZWFtczsgYnVuZGxlLW9ubHkgd2FzIG1lYW50IHRvIGF2b2lkIHRoaXMg Y2FuZGlkYXRlIGxhdGVuY3kuDQo+PiBZb3UgZG8gbm90IGhhdmUgdG8gYWxsb2NhdGUgcG9ydHMg Zm9yIHRoZSBidW5kbGUtb25seSBtLSBsaW5lcy7CoA0KPj4NCj4+PiBiKSBPbmNlIHlvdSBoYXZl IHRoZSBpbml0aWFsIGFuc3dlciwgeW91IGtub3cgd2hldGhlciB0aGUgb3RoZXIgc2lkZSBzdXBw b3J0cyBCVU5ETEUsIHNvIHlvdSBjYW4gdGFrZSB0aGUgYXBwcm9wcmlhdGUgYWN0aW9uIChhbmQg c28gdGhlcmUgaXMgbm8gbmVlZCBmb3IgYnVuZGxlLW9ubHkpLg0KPj4+DQo+Pj4gSWYgU0lQIGNh bid0IGRlYWwgd2l0aCB0aGUgYnVuZGxlLW9ubHkgY29uY2VwdCwgdGhlbiBXZWJSVEMgYXBwcyB0 aGF0IGNhcmUgYWJvdXQgbGF0ZW5jeSB3aWxsIGhhdmUgdG8gZGVjaWRlIHdoZXRoZXIgdGhleSBh cmUgcnVubmluZyBpbiBXZWJSVEMtb25seSBtb2RlIG9yIGNvbXBhdGliaWxpdHkgbW9kZS4gSW4g V2ViUlRDLW9ubHkgbW9kZSwgc3RyZWFtcyB3aWxsIGJlIGJ1bmRsZWQgaW4gdGhlIGluaXRpYWwg b2ZmZXI7IGluIGNvbXBhdGliaWxpdHkgbW9kZSwgMiBvZmZlci1hbnN3ZXJzIHdpbGwgYmUgbmVl ZGVkLg0KPj4gVGhlcmUgYXJlIG5vICJtb2RlcyIgaW4gQlVORExFIHRvZGF5IDopDQo+Pg0KPiBP ZiBjb3Vyc2UgdGhlcmUgYXJlLiBUaGUgaGFuZGxpbmcgaW4gYSByZWludml0ZSBjYXNlIGlzIGRp c3RpbmN0IGZyb20gdGhlIGluaXRpYWwgb2ZmZXIsIHNvIHRoYXQgaXMgbW9kYWwgYmVoYXZpb3Iu wqANCg0KU3VyZSwgYnV0IHlvdSB3ZXJlIHRhbGtpbmcgYWJvdXQgIldlYlJUQy1vbmx5IG1vZGUi IGFuZCAiY29tcGF0aWJpbGl0eSBtb2RlIiwgYW5kIG15IHBvaW50IGlzIHRoYXQgY3VycmVudGx5 IHRoZSBwcm9jZWR1cmVzIGZvciBpbml0aWFsIG9mZmVycywgc3Vic2VxdWVudCBvZmZlcnMgZXRj IGFyZSB0aGUgc2FtZS4NCg0KPj4+IFRoaXMgd291bGQgYmUgYSBzb21ld2hhdCB1bmZvcnR1bmF0 ZSBvdXRjb21lLCBzbyBJJ2QgbGlrZSB0byBzZWUgYnVuZGxlLW9ubHkgKG9yIHNvbWV0aGluZyBs aWtlIGl0KSB3b3JrLg0KPj4gSSBkb24ndCB0aGluayB0aGUgc2Vjb25kIG9mZmVyIGlzIGdvaW5n IHRvIGNhdXNlIGFueSBsYXRlbmN5LiBBbHNvLCBrZWVwIGluIG1pbmQgdGhhdCB5b3Ugb25seSBu ZWVkIHRoZSAybmQgT2ZmZXIvQW5zd2VyIGR1cmluZyB0aGUgc2Vzc2lvbiBlc3RhYmxpc2htZW50 LiBBcyBhZ3JlZWQgaW4gQmVybGluLCBpbiBtaWQtc2Vzc2lvbiBjaGFuZ2VzIHlvdSBkbyBOT1Qg bmVlZCAyIG9mZmVyL2Fuc3dlcnMuDQo+DQo+IFBsZWFzZSBwcm92aWRlIHN1cHBvcnQgZm9yIHRo aXMgc3RhdGVtZW50LiBJdCBzZWVtcyBjbGVhciB0aGF0IGEgMm5kIG9mZmVyIGFkZHMgX2F0IGxl YXN0XyAxIFJUVCBsYXRlbmN5LsKgDQoNClN1cmUsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgaXMg Z29pbmcgdG8gYmUgYSBwcmFjdGljYWwgcHJvYmxlbS4NCg0KRmlyc3QsIHRoZXJlIGFyZSBkZXBs b3llZCBsZWdhY3kgU0lQIHN5c3RlbXMgdGhhdCB1c2UgZXZlbiBtb3JlIE8vQSB0cmFuc2FjdGlv bnMgZHVyaW5nIHNlc3Npb24gZXN0YWJsaXNobWVudC4gQW5kLCBpbiB5b3VyIGNhc2UgSSBhc3N1 bWUgeW91IGFyZSBldmVuIGdvaW5nIHRvIHVzZSBzb21ldGhpbmcgbW9yZSAibGlnaHR3ZWlnaHQi IHRoYW4gU0lQIHRvIGNhcnJ5IHlvdXIgT2ZmZXIvQW5zd2Vycy4NCg0KU2Vjb25kLCBhcyBXZWJS VEMgbWFuZGF0ZXMgdXNhZ2Ugb2YgSUNFLCB5b3UgYXJlIG9mdGVuIGdvaW5nIHRvIG5lZWQgYSBz dWJzZXF1ZW50IE8vQSBhbnl3YXkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K From christer.holmberg@ericsson.com Sat Aug 10 15:24:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555F221F9F00 for ; Sat, 10 Aug 2013 15:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVLHvBQ5qnkr for ; Sat, 10 Aug 2013 15:24:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEEF21F9DBE for ; Sat, 10 Aug 2013 15:15:40 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-0d-5206bb84902a Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 80.B6.03938.48BB6025; Sun, 11 Aug 2013 00:15:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Sun, 11 Aug 2013 00:15:31 +0200 From: Christer Holmberg To: Justin Uberti , Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlV8ioTPI9FwY/k2V07fO+LYnTpmNeJeAgAGJIoA= Date: Sat, 10 Aug 2013 22:15:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C43CA14@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <24FAAB9F-D014-4B84-BE41-91D43E5604DD@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+JvrW7LbrYgg/lNohafNn1ittg6Vchi 6vLHLA7MHgs2lXosWfKTyePj01ssAcxRXDYpqTmZZalF+nYJXBm3P69iLDjAWXHo/FPWBsYF nF2MnBwSAiYSN+5tZIGwxSQu3FvP1sXIxSEkcJhR4uKENkaQhJDAYkaJ9xvCuxg5ONgELCS6 /2mDhEUEQiRu/f7BBhJmFlCXuLo4CCQsLBAmsafjAQtESbjE+TenmSBsK4mJc2aB2SwCqhI/ 5y5iBbF5BXwlvlw4wAix9ga7xOW/+9hAEpwCgRLrbzWC2YxAt30/tQasmVlAXOLDwevMEDcL SCzZcx7KFpV4+fgfK4StJNG45AkrxG2aEut36UO0KkpM6X7IDrFXUOLkzCcsExjFZiGZOguh YxaSjllIOhYwsqxiZM9NzMxJLzfcxAiMloNbfuvuYDx1TuQQozQHi5I47ya9M4FCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGI3X9F8Qm7Vvilxjp0RBMG/Z/Wh3j27nOecEvr2z6bT3DOow jK98sPLYrilPV11av7DsvKV65QpXWZOVlvXPLDZ9lJv6d3O46YF/Yvv/a/Id3K9wiH2O/7fm bZZbaiNvqWgX9zCc+J6rvPRY5dm5yfbTt2QqXwtnWM/AJKf9U+/x1SfVN7e3+SmxFGckGmox FxUnAgAz/ijrZAIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 22:24:45 -0000 SGksDQoNCj4+IGIpIE9uY2UgeW91IGhhdmUgdGhlIGluaXRpYWwgYW5zd2VyLCB5b3Uga25vdyB3 aGV0aGVyIHRoZSBvdGhlciBzaWRlIHN1cHBvcnRzIEJVTkRMRSwgc28geW91IGNhbiB0YWtlIHRo ZSBhcHByb3ByaWF0ZSBhY3Rpb24gKGFuZCBzbyB0aGVyZSBpcyBubyBuZWVkIGZvciBidW5kbGUt b25seSkuDQo+Pg0KPj4gQ2hyaXN0ZXIncyBwcm9wb3NhbCBpcyB0byBzZW5kIHRoZSByZWd1bGFy IG0tbGluZXMsIGluY2x1ZGluZyByZWd1bGFyIGJ1bmRsZSBtLWxpbmVzLCBpbiB0aGUgaW5pdGlh bCBPZmZlci4gwqBUaGUgQW5zd2VyIGNvbWVzIGJhY2sgZm9yIHRob3NlLCBhbmQgdGVsbHMgeW91 IGlmIHRoZSBmYXItZW5kIGRvZXMgYnVuZGxlLiDCoFlvdSB0aGVuIHNlbmQgYW5vdGhlciBPZmZl ciwgd2l0aCBtb3JlICpidW5kbGUqIG0tbGluZXMuIMKgVGhlcmUgaXMgbm8gImJ1bmRsZS1vbmx5 IiBuZWVkZWQgYW55bW9yZS4NCj4NCj4gQWdyZWUgLSB0aGVyZSBpcyBubyBuZWVkIGZvciBidW5k bGUtb25seSB3aXRoIDIgTy9Bcy7CoA0KDQpUaGVyZSBtYXkgbm90IGJlIGEgbmVlZCBmb3IgYW4g ZXhwbGljaXQgYnVuZGxlLW9ubHkgYXR0cmlidXRlLCBidXQgdGhlIDIgTy9BIERPRVMgYWxsb3cg eW91IGFkZCBzZW5kIG0tIGxpbmVzIGFuZCByZXF1ZXN0IHRoZSByZWNlaXZlciB0byByZWplY3Qg dGhlbSB1bmxlc3MgdGhleSBhcmUgcHV0IGludG8gdGhlIEJVTkRMRSBncm91cCAtIHdoaWNoIGlz IGV4YWN0bHkgd2hhdCB5b3Ugd2FudCB0byBhY2hpZXZlIHdpdGggYnVuZGxlLW9ubHkgOikNCg0K U28sIHlvdSB3b3VsZCBzdGlsbCBoYXZlIHN1cHBvcnQgZm9yIHRoZSBidW5kbGUtb25seSBjb25j ZXB0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From ekr@rtfm.com Sat Aug 10 18:58:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9244B11E80C5 for ; Sat, 10 Aug 2013 18:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-ak1nC9MkWc for ; Sat, 10 Aug 2013 18:58:03 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7780D21F99E1 for ; Sat, 10 Aug 2013 18:52:46 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so485956qab.11 for ; Sat, 10 Aug 2013 18:52:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tqtXKDcLWCzHK+iltBrV2R+rsMFpvzEI6AxaJqyowO0=; b=pf84O4Tjc+ll6ue3JDmGmuFbDyKEfuA/bEGyjheI3sCBPlSp/cb3wcQDI8XC5/xv9k 4EttuZODcJiMEwALuoF5QK3iaF5fCxXzd3ckqW2C0qkR9fQA78HfPTm3hNOOAXS3gp2S y5jpo2ViylhKglNC9ZIat+VzpQ6YXd9rCmd/NAFSP8N9k3rQAtXyb+5//4m+h7676snq Iov09WnAL+Ru710L7GQ+52s1jZmaqnCkJ2jdmDG8P4gJ4abDRj+V9wqvNICYqWrfXp8k 1hbc6pck8fM7S1JN4ks1outOh4CTEIH6l2FIzex2u5kQQIAJ2o7Nb1QDxF7s2jSPUXBj YYuA== X-Gm-Message-State: ALoCoQmjUYcCrSooPNipoUtwNjY7ycfntRDeupCI0GQufzqSefSnfArLBLiYBaEbQ4+7Oi10et0O X-Received: by 10.49.104.163 with SMTP id gf3mr7671953qeb.73.1376185965883; Sat, 10 Aug 2013 18:52:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Sat, 10 Aug 2013 18:52:04 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C43BA02@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43BA02@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Sat, 10 Aug 2013 18:52:04 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b5da905a447b004e3a243fb Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 01:58:09 -0000 --047d7b5da905a447b004e3a243fb Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> Requiring a second offer to add the bundle-only m-lines defeats the > purpose of bundle-only. > >> We already require a second offer. I know that some people, including > yourself, want to change that, but that is nothing we have agreed on. > >> > >>> a) The delay to do an O/A will often exceed the time to allocate > candidates, for small numbers of streams; bundle-only was meant to avoid > this candidate latency. > >> You do not have to allocate ports for the bundle-only m- lines. > >> > >>> b) Once you have the initial answer, you know whether the other side > supports BUNDLE, so you can take the appropriate action (and so there is no > need for bundle-only). > >>> > >>> If SIP can't deal with the bundle-only concept, then WebRTC apps that > care about latency will have to decide whether they are running in > WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will > be bundled in the initial offer; in compatibility mode, 2 offer-answers > will be needed. > >> There are no "modes" in BUNDLE today :) > >> > > Of course there are. The handling in a reinvite case is distinct from > the initial offer, so that is modal behavior. > > Sure, but you were talking about "WebRTC-only mode" and "compatibility > mode", and my point is that currently the procedures for initial offers, > subsequent offers etc are the same. > > >>> This would be a somewhat unfortunate outcome, so I'd like to see > bundle-only (or something like it) work. > >> I don't think the second offer is going to cause any latency. Also, > keep in mind that you only need the 2nd Offer/Answer during the session > establishment. As agreed in Berlin, in mid-session changes you do NOT need > 2 offer/answers. > > > > Please provide support for this statement. It seems clear that a 2nd > offer adds _at least_ 1 RTT latency. > > Sure, but I don't think that is going to be a practical problem. > Well, I'd like to see a more convincing argument than "some middleboxes are sad" when you do that. First, there are deployed legacy SIP systems that use even more O/A > transactions during session establishment. And, in your case I assume you > are even going to use something more "lightweight" than SIP to carry your > Offer/Answers. > > Second, as WebRTC mandates usage of ICE, you are often going to need a > subsequent O/A anyway. > It's important to distinguish between round-trips that are in the critical path for media flowing and those which are not. -Ekr --047d7b5da905a447b004e3a243fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi,

>>> Requiring a second offer to add the bundle-only m-lines defeat= s the purpose of bundle-only.
>> We already require a second offer. I know that some people, includ= ing yourself, want to change that, but that is nothing we have agreed on. >>
>>> a) The delay to do an O/A will often exceed the time to alloca= te candidates, for small numbers of streams; bundle-only was meant to avoid= this candidate latency.
>> You do not have to allocate ports for the bundle-only m- lines.=A0=
>>
>>> b) Once you have the initial answer, you know whether the othe= r side supports BUNDLE, so you can take the appropriate action (and so ther= e is no need for bundle-only).
>>>
>>> If SIP can't deal with the bundle-only concept, then WebRT= C apps that care about latency will have to decide whether they are running= in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams wi= ll be bundled in the initial offer; in compatibility mode, 2 offer-answers = will be needed.
>> There are no "modes" in BUNDLE today :)
>>
> Of course there are. The handling in a reinvite case is distinct from = the initial offer, so that is modal behavior.=A0

Sure, but you were talking about "WebRTC-only mode" and &qu= ot;compatibility mode", and my point is that currently the procedures = for initial offers, subsequent offers etc are the same.

>>> This would be a somewhat unfortunate outcome, so I'd like = to see bundle-only (or something like it) work.
>> I don't think the second offer is going to cause any latency. = Also, keep in mind that you only need the 2nd Offer/Answer during the sessi= on establishment. As agreed in Berlin, in mid-session changes you do NOT ne= ed 2 offer/answers.
>
> Please provide support for this statement. It seems clear that a 2nd o= ffer adds _at least_ 1 RTT latency.=A0

Sure, but I don't think that is going to be a practical problem.<= br>

Well, I'd like to see a more convin= cing argument than "some middleboxes are sad" when you
do that.


First, there are deployed legacy SIP systems that use even more O/A transac= tions during session establishment. And, in your case I assume you are even= going to use something more "lightweight" than SIP to carry your= Offer/Answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a subs= equent O/A anyway.

It's important t= o distinguish between round-trips that are in the critical path for media
flowing and those which are not.

-Ekr

--047d7b5da905a447b004e3a243fb-- From christer.holmberg@ericsson.com Sun Aug 11 00:46:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAE811E80F0 for ; Sun, 11 Aug 2013 00:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[AWL=-1.385, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8990+VzMa1E for ; Sun, 11 Aug 2013 00:46:11 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0168E11E80F4 for ; Sun, 11 Aug 2013 00:39:48 -0700 (PDT) X-AuditID: c1b4fb38-b7fb48e000000a68-a2-52073fc26a0b Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B3.C4.02664.2CF37025; Sun, 11 Aug 2013 09:39:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Sun, 11 Aug 2013 09:39:46 +0200 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712YAAqfkAgABUDKCAABnkgIAAIrhg///pDwCAAZH/EIAAHt8AgACCrF0= Date: Sun, 11 Aug 2013 07:39:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43BA02@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C43DBA9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvre4he/Ygg1+rbCxWvD7HbrF1qpDF 1OWPWSxWbDjA6sDi8ff9ByaPBZtKPZYs+cnkMflxG3MASxSXTUpqTmZZapG+XQJXxpHL3xgL JjtW3Jqzna2BcbFZFyMnh4SAicSmy4uZIWwxiQv31rN1MXJxCAkcZZT4vWk/K4SzmFHi4qlN QBkODjYBC4nuf9ogDSICChK//pxgAbGZBQolZv7+B1YiLBAmMfVlCkRJuMThD9uYQMaICGxi lFj88RkTSIJFQFVi1Z1bYIt5BXwl7j35CbXrI4fE/ulzGUESnAKBEvcunANrYAS67vupNUwQ y8Qlbj2ZzwRxtYDEkj3noT4QlXj5+B8ryBHMAvkS627HQswXlDg58wnLBEaRWUi6ZyFUzUJS BVGiJ3Fj6hQ2CFtbYtnC18wQtq7EjH+HWJDFFzCyr2LkKE4tTspNNzLYxAiMr4NbflvsYLz8 1+YQozQHi5I47xa9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGGfXbp8kunQhv7a6SsH5 0soI3sj30zm7jl7xDuNdpfXpx9tNqRE/Jlp07NJO7hG6XWAgonvN6iT7hsJIm5k7L5xaxGYS 9Kve1EdG9pm/38845v15wekiK7/eu6Nx9tYcI/fvG3qMwp4+YcuPL3zQ8i3t8wrd60+ibV+J xHo4iqZP/yIoOP3lZSWW4oxEQy3mouJEAK5FB+t9AgAA Cc: "mmusic_ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 07:46:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C43DBA9ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I think making sure all entities have the correct port numbers is critical = in making sure the media will flow. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Eric Rescorla [ekr@rtfm.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; = Paul Kyzivat [pkyzivat@alum.mit.edu] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg > wrote: Hi, >>> Requiring a second offer to add the bundle-only m-lines defeats the pur= pose of bundle-only. >> We already require a second offer. I know that some people, including yo= urself, want to change that, but that is nothing we have agreed on. >> >>> a) The delay to do an O/A will often exceed the time to allocate candid= ates, for small numbers of streams; bundle-only was meant to avoid this can= didate latency. >> You do not have to allocate ports for the bundle-only m- lines. >> >>> b) Once you have the initial answer, you know whether the other side su= pports BUNDLE, so you can take the appropriate action (and so there is no n= eed for bundle-only). >>> >>> If SIP can't deal with the bundle-only concept, then WebRTC apps that c= are about latency will have to decide whether they are running in WebRTC-on= ly mode or compatibility mode. In WebRTC-only mode, streams will be bundled= in the initial offer; in compatibility mode, 2 offer-answers will be neede= d. >> There are no "modes" in BUNDLE today :) >> > Of course there are. The handling in a reinvite case is distinct from the= initial offer, so that is modal behavior. Sure, but you were talking about "WebRTC-only mode" and "compatibility mode= ", and my point is that currently the procedures for initial offers, subseq= uent offers etc are the same. >>> This would be a somewhat unfortunate outcome, so I'd like to see bundle= -only (or something like it) work. >> I don't think the second offer is going to cause any latency. Also, keep= in mind that you only need the 2nd Offer/Answer during the session establi= shment. As agreed in Berlin, in mid-session changes you do NOT need 2 offer= /answers. > > Please provide support for this statement. It seems clear that a 2nd offe= r adds _at least_ 1 RTT latency. Sure, but I don't think that is going to be a practical problem. Well, I'd like to see a more convincing argument than "some middleboxes are= sad" when you do that. First, there are deployed legacy SIP systems that use even more O/A transac= tions during session establishment. And, in your case I assume you are even= going to use something more "lightweight" than SIP to carry your Offer/Ans= wers. Second, as WebRTC mandates usage of ICE, you are often going to need a subs= equent O/A anyway. It's important to distinguish between round-trips that are in the critical = path for media flowing and those which are not. -Ekr --_000_7594FB04B1934943A5C02806D1A2204B1C43DBA9ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I think making sure all entities have the correct port numbers is crit= ical in making sure the media will flow.
 
Regards,
 
Christer
 
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf= .org]; Paul Kyzivat [pkyzivat@alum.mit.edu]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?



On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>>> Requiring a second offer to add the bundle-only m-lines defeat= s the purpose of bundle-only.
>> We already require a second offer. I know that some people, includ= ing yourself, want to change that, but that is nothing we have agreed on. >>
>>> a) The delay to do an O/A will often exceed the time to alloca= te candidates, for small numbers of streams; bundle-only was meant to avoid= this candidate latency.
>> You do not have to allocate ports for the bundle-only m- lines.&nb= sp;
>>
>>> b) Once you have the initial answer, you know whether the othe= r side supports BUNDLE, so you can take the appropriate action (and so ther= e is no need for bundle-only).
>>>
>>> If SIP can't deal with the bundle-only concept, then WebRTC ap= ps that care about latency will have to decide whether they are running in = WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will b= e bundled in the initial offer; in compatibility mode, 2 offer-answers will be needed.
>> There are no "modes" in BUNDLE today :)
>>
> Of course there are. The handling in a reinvite case is distinct from = the initial offer, so that is modal behavior. 

Sure, but you were talking about "WebRTC-only mode" and "com= patibility mode", and my point is that currently the procedures for in= itial offers, subsequent offers etc are the same.

>>> This would be a somewhat unfortunate outcome, so I'd like to s= ee bundle-only (or something like it) work.
>> I don't think the second offer is going to cause any latency. Also= , keep in mind that you only need the 2nd Offer/Answer during the session e= stablishment. As agreed in Berlin, in mid-session changes you do NOT need 2= offer/answers.
>
> Please provide support for this statement. It seems clear that a 2nd o= ffer adds _at least_ 1 RTT latency. 

Sure, but I don't think that is going to be a practical problem.

Well, I'd like to see a more convincing argument than "some middl= eboxes are sad" when you
do that.


First, there are deployed legacy SIP systems that use even more O/A transac= tions during session establishment. And, in your case I assume you are even= going to use something more "lightweight" than SIP to carry your= Offer/Answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a subs= equent O/A anyway.

It's important to distinguish between round-trips that are in the crit= ical path for media
flowing and those which are not.

-Ekr

--_000_7594FB04B1934943A5C02806D1A2204B1C43DBA9ESESSMB209erics_-- From ekr@rtfm.com Sun Aug 11 04:22:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173A921F9D0D for ; Sun, 11 Aug 2013 04:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.961 X-Spam-Level: X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj+z3J+PeL77 for ; Sun, 11 Aug 2013 04:22:07 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id CEB3721F9F70 for ; Sun, 11 Aug 2013 04:16:29 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 9so3063173qea.21 for ; Sun, 11 Aug 2013 04:16:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xdQEneO2jsEgIpO5zaKZFwUJoB9z66APi0NcBYvcnlU=; b=ZbN4neoCp8aRfWpqXj8yMEkvFkjTLKqoiuHzZ7L4SLBK/5BDWTsCUgATJcBn6Vijwt 1ceGfBKebp7WP+xEV2oT3m2R/80v7h7KS0VjJbQwgey9WANOdQibrFBgBvqmvGr6Ujop wP76ctyPFq1YK96TNx6dGJE3TOnxWeJU5Utt+VjQ3ryRYDR0DtSoarrua3+2n3V1jJv8 /PwJxIbRmFb7UbdHP9qr6F4Uk1IN1+g3g5NY982lDLDQ5Pf3aBQpdyxNdZTElCg8FWn2 iygcrfw1W7H9PAwM8v3on/ywALB37n9AuvXcJ/FDKZ5SuzGXzjNANrX8lKSL8BJ5QdI1 LFBQ== X-Gm-Message-State: ALoCoQle9MlfvFWGXkqvCMi+VqTBtFIH4EZ2ZfRkiko0Cz8F15ugg/LFv5soTEM0cHXXuFe6nGW3 X-Received: by 10.224.223.202 with SMTP id il10mr19096464qab.87.1376219789244; Sun, 11 Aug 2013 04:16:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Sun, 11 Aug 2013 04:15:49 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43BA02@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Sun, 11 Aug 2013 04:15:49 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2318eabcde404e3aa23c7 Cc: "mmusic_ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 11:22:13 -0000 --001a11c2318eabcde404e3aa23c7 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 11, 2013 at 12:39 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I think making sure all entities have the correct port numbers is critical > in making sure the media will flow. > There is a difference between "making sure the media will flow" and "before media can flow at all". For instance, Neither Firefox nor Chrome current does a second O/A transaction and yet media flows just fine in most cases, since they are operating in an unmediated environment. Obviously, this is a best-case scenario, but similarly there are going to be mediated environments which are perfectly happy with a second O/A exchange with non-zero ports. This argues against designing a system in which none of the secondary media flows without a second O/A exchange. -Ekr -----Original Message----- > *From:* Eric Rescorla [ekr@rtfm.com] > *To:* Christer Holmberg [christer.holmberg@ericsson.com] > *CC:* Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; > Paul Kyzivat [pkyzivat@alum.mit.edu] > *Subject:* Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for > bundle-only m- lines? > > > > On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >>> Requiring a second offer to add the bundle-only m-lines defeats the >> purpose of bundle-only. >> >> We already require a second offer. I know that some people, including >> yourself, want to change that, but that is nothing we have agreed on. >> >> >> >>> a) The delay to do an O/A will often exceed the time to allocate >> candidates, for small numbers of streams; bundle-only was meant to avoid >> this candidate latency. >> >> You do not have to allocate ports for the bundle-only m- lines. >> >> >> >>> b) Once you have the initial answer, you know whether the other side >> supports BUNDLE, so you can take the appropriate action (and so there is no >> need for bundle-only). >> >>> >> >>> If SIP can't deal with the bundle-only concept, then WebRTC apps that >> care about latency will have to decide whether they are running in >> WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will >> be bundled in the initial offer; in compatibility mode, 2 offer-answers >> will be needed. >> >> There are no "modes" in BUNDLE today :) >> >> >> > Of course there are. The handling in a reinvite case is distinct from >> the initial offer, so that is modal behavior. >> >> Sure, but you were talking about "WebRTC-only mode" and "compatibility >> mode", and my point is that currently the procedures for initial offers, >> subsequent offers etc are the same. >> >> >>> This would be a somewhat unfortunate outcome, so I'd like to see >> bundle-only (or something like it) work. >> >> I don't think the second offer is going to cause any latency. Also, >> keep in mind that you only need the 2nd Offer/Answer during the session >> establishment. As agreed in Berlin, in mid-session changes you do NOT need >> 2 offer/answers. >> > >> > Please provide support for this statement. It seems clear that a 2nd >> offer adds _at least_ 1 RTT latency. >> >> Sure, but I don't think that is going to be a practical problem. >> > > Well, I'd like to see a more convincing argument than "some middleboxes > are sad" when you > do that. > > > First, there are deployed legacy SIP systems that use even more O/A >> transactions during session establishment. And, in your case I assume you >> are even going to use something more "lightweight" than SIP to carry your >> Offer/Answers. >> >> Second, as WebRTC mandates usage of ICE, you are often going to need a >> subsequent O/A anyway. >> > > It's important to distinguish between round-trips that are in the > critical path for media > flowing and those which are not. > > -Ekr > > --001a11c2318eabcde404e3aa23c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 11, 2013 at 12:39 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,
=A0
I think making sure all entities have the correct port numbers is crit= ical in making sure the media will flow.

<= /div>
There is a difference between "making sure the media will fl= ow" and "before media can
flow at all". For instance, Neither Firefox nor Chrome current do= es a second O/A
transaction and yet media flows just fine in most= cases, since they are operating
in an unmediated environment. Ob= viously, this is a best-case scenario, but similarly
there are going to be mediated environments which are perfectly happy = with a second
O/A exchange with non-zero ports.

This argues against designing a system in which none of the seconda= ry media flows
without a second O/A exchange.

-Ekr
=


-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
To: Christer Holmberg [christer.holmberg@ericsson.com]
CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; Paul Kyzivat [<= a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank">pkyzivat@alum.mit= .edu]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundl= e-only m- lines?



On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>>> Requiring a second offer to add the bundle-only m-lines defeat= s the purpose of bundle-only.
>> We already require a second offer. I know that some people, includ= ing yourself, want to change that, but that is nothing we have agreed on. >>
>>> a) The delay to do an O/A will often exceed the time to alloca= te candidates, for small numbers of streams; bundle-only was meant to avoid= this candidate latency.
>> You do not have to allocate ports for the bundle-only m- lines.=A0=
>>
>>> b) Once you have the initial answer, you know whether the othe= r side supports BUNDLE, so you can take the appropriate action (and so ther= e is no need for bundle-only).
>>>
>>> If SIP can't deal with the bundle-only concept, then WebRT= C apps that care about latency will have to decide whether they are running= in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams wi= ll be bundled in the initial offer; in compatibility mode, 2 offer-answers will be needed.
>> There are no "modes" in BUNDLE today :)
>>
> Of course there are. The handling in a reinvite case is distinct from = the initial offer, so that is modal behavior.=A0

Sure, but you were talking about "WebRTC-only mode" and "com= patibility mode", and my point is that currently the procedures for in= itial offers, subsequent offers etc are the same.

>>> This would be a somewhat unfortunate outcome, so I'd like = to see bundle-only (or something like it) work.
>> I don't think the second offer is going to cause any latency. = Also, keep in mind that you only need the 2nd Offer/Answer during the sessi= on establishment. As agreed in Berlin, in mid-session changes you do NOT ne= ed 2 offer/answers.
>
> Please provide support for this statement. It seems clear that a 2nd o= ffer adds _at least_ 1 RTT latency.=A0

Sure, but I don't think that is going to be a practical problem.

Well, I'd like to see a more convincing argument than "some m= iddleboxes are sad" when you
do that.


First, there are deployed legacy SIP systems that use even more O/A transac= tions during session establishment. And, in your case I assume you are even= going to use something more "lightweight" than SIP to carry your= Offer/Answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a subs= equent O/A anyway.

It's important to distinguish between round-trips that are in the = critical path for media
flowing and those which are not.

-Ekr


--001a11c2318eabcde404e3aa23c7-- From christer.holmberg@ericsson.com Sun Aug 11 06:16:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A3621F9A98 for ; Sun, 11 Aug 2013 06:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.795 X-Spam-Level: X-Spam-Status: No, score=-5.795 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-jlhmKxQQ28 for ; Sun, 11 Aug 2013 06:16:35 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F0F3721E8050 for ; Sun, 11 Aug 2013 06:11:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-21-52078d6b393b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E8.61.03938.B6D87025; Sun, 11 Aug 2013 15:11:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Sun, 11 Aug 2013 15:11:07 +0200 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712YAAqfkAgABUDKCAABnkgIAAIrhg///pDwCAAZH/EIAAHt8AgACCrF2AABrXgIAAP9yf Date: Sun, 11 Aug 2013 13:11:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C440F3B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43BA02@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43DBA9@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+JvrW52L3uQwYJ76hYrXp9jt9g6Vchi 6vLHLBYrNhxgdWDx+Pv+A5PHgk2lHkuW/GTymPy4jTmAJYrLJiU1J7MstUjfLoErY+Pyp2wF O+Urbj/dxdbA2CjZxcjJISFgInHjxRwmCFtM4sK99WwgtpDAYUaJ6Sf0uhi5gOzFjBI7ry0H SnBwsAlYSHT/0wapERFQkPj15wQLiM0sUCgx8/c/sF5hgTCJeVvmMkPUhEsc/rCNCWSOiMA+ RomjK9YxgcxhEVCVuLDbDKSGV8BXYvOKvewQu/5wSrz81AU2lFMgUKK5pwXMZgQ67vupNUwQ y8Qlbj2ZD3W0gMSSPeeZIWxRiZeP/7GCzJcQUJRY3i8HUa4jsWD3JzYIW1ti2cLXzBB7BSVO znzCMoFRbBaSqbOQtMxC0jILScsCRpZVjOy5iZk56eWGmxiBUXRwy2/dHYynzokcYpTmYFES 592kdyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6MB64qdlZ9jhOVKpK6z1yyrv/e7bYZe xvsjmSxv/wdaqk9V6vet18nmj3l22cel7toFS84Vasnn/7SsfDCX472F1x9T5j9n0gwFXjCG qnJJ82sfOWkqcNPWXX61FVPuyRzBiWd9FPRiXNXZNp1ztQ853C4cklgVsPPK1pIbl9XO1Dhs NPpQpMRSnJFoqMVcVJwIAGc6vJdwAgAA Cc: "mmusic_ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 13:16:42 -0000 Hi, >> I think making sure all entities have the correct port numbers is critic= al in making sure the media will flow. > > There is a difference between "making sure the media will flow" and "befo= re media can > flow at all". > For instance, Neither Firefox nor Chrome current does a second O/A > transaction and yet media flows just fine in most cases, since they are o= perating > in an unmediated environment. Obviously, this is a best-case scenario, bu= t similarly > there are going to be mediated environments which are perfectly happy wit= h a second > O/A exchange with non-zero ports. There are also environements where a single offer, with identical port numb= ers, work just fine, because the receiver will be able to handle it even if= it doesn't support BUNDLE. However, we are defining a generic mechanism, supposed to work in different= environments.=20 But, sure, if the community thinks that we shall define different options, = depending on environments etc, we can do that...=20 Regards, Christer -----Original Message----- From: Eric Rescorla [ekr@rtfm.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; = Paul Kyzivat [pkyzivat@alum.mit.edu] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg wrote: Hi, >>> Requiring a second offer to add the bundle-only m-lines defeats the pur= pose of bundle-only. >> We already require a second offer. I know that some people, including yo= urself, want to change that, but that is nothing we have agreed on. >> >>> a) The delay to do an O/A will often exceed the time to allocate candid= ates, for small numbers of streams; bundle-only was meant to avoid this can= didate latency. >> You do not have to allocate ports for the bundle-only m- lines.=20 >> >>> b) Once you have the initial answer, you know whether the other side su= pports BUNDLE, so you can take the appropriate action (and so there is no n= eed for bundle-only). >>> >>> If SIP can't deal with the bundle-only concept, then WebRTC apps that c= are about latency will have to decide whether they are running in WebRTC-on= ly mode or compatibility mode. In WebRTC-only mode, streams will be bundled= in the initial offer; in compatibility mode, 2 offer-answers will be neede= d. >> There are no "modes" in BUNDLE today :) >> > Of course there are. The handling in a reinvite case is distinct from the= initial offer, so that is modal behavior.=20 Sure, but you were talking about "WebRTC-only mode" and "compatibility mode= ", and my point is that currently the procedures for initial offers, subseq= uent offers etc are the same. >>> This would be a somewhat unfortunate outcome, so I'd like to see bundle= -only (or something like it) work. >> I don't think the second offer is going to cause any latency. Also, keep= in mind that you only need the 2nd Offer/Answer during the session establi= shment. As agreed in Berlin, in mid-session changes you do NOT need 2 offer= /answers. > > Please provide support for this statement. It seems clear that a 2nd offe= r adds _at least_ 1 RTT latency.=20 Sure, but I don't think that is going to be a practical problem. Well, I'd like to see a more convincing argument than "some middleboxes are= sad" when you do that. First, there are deployed legacy SIP systems that use even more O/A transac= tions during session establishment. And, in your case I assume you are even= going to use something more "lightweight" than SIP to carry your Offer/Ans= wers. Second, as WebRTC mandates usage of ICE, you are often going to need a subs= equent O/A anyway. It's important to distinguish between round-trips that are in the critical = path for media flowing and those which are not. -Ekr= From hadriel.kaplan@oracle.com Sun Aug 11 06:31:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1521F99AD for ; Sun, 11 Aug 2013 06:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CGG+3osCkJz for ; Sun, 11 Aug 2013 06:31:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id DA85D21F85E3 for ; Sun, 11 Aug 2013 06:24:34 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7BDOXl5031511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Aug 2013 13:24:34 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7BDOWdL008482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Aug 2013 13:24:32 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7BDOVFK005451; Sun, 11 Aug 2013 13:24:31 GMT Received: from [192.168.2.10] (/184.61.127.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 11 Aug 2013 06:24:31 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Sun, 11 Aug 2013 09:24:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3749D352-BD3E-43B0-A060-5D8390F9B24C@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C0280! 6D1A2204B1C43BA02@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> To: Eric Rescorla X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 13:31:10 -0000 On Aug 11, 2013, at 7:15 AM, Eric Rescorla wrote: > There is a difference between "making sure the media will flow" and = "before media can > flow at all". For instance, Neither Firefox nor Chrome current does a = second O/A > transaction and yet media flows just fine in most cases, since they = are operating > in an unmediated environment. Obviously, this is a best-case scenario, = but similarly > there are going to be mediated environments which are perfectly happy = with a second > O/A exchange with non-zero ports. >=20 > This argues against designing a system in which none of the secondary = media flows > without a second O/A exchange. Actually I think it argues against designing a system which treats an = Application Programming Interface the same as an on-the-wire = Internet-wide negotiation mechanism, with a deployed infrastructure that = has been growing larger for the past 10 years. It also argues against = tying the fate of WebRTC to SIP, with regards to SDP O/A. One thing we could do, for example, is define BUNDLE as we've been = describing (which is essentially no change, afaik) and define its usage = for SDP O/A as we've been describing. But we put a "unless the sender = has specific knowledge otherwise, as it could in [jsep] for example". = Or something like that. Then the JSEP draft could say what to do for = WebRTC usage. Take a step back and ignore this particular port-numbering issue for a = second: in what context would it make sense for an API to need two = separate rounds of "Offer/Answer" between the Javascript and the = Browser? I.e., if we weren't using SDP at all, and had never heard of = RFC 3264, and just used a native Javascript API... what use-cases would = require the JS script and Browser to communicate multiple times between = each other for the same action? I think error cases might, for example. = And I think if the JS hooked into a callback for ICE transport = selection changes, then the Browser would need to tell it when those = things changed, for example. Can you think of any others? -hadriel From ekr@rtfm.com Sun Aug 11 07:57:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3348D21F997D for ; Sun, 11 Aug 2013 07:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkFkboO9O0Ra for ; Sun, 11 Aug 2013 07:57:36 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 341A521F9AD8 for ; Sun, 11 Aug 2013 07:51:22 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id u12so2939625qcx.7 for ; Sun, 11 Aug 2013 07:51:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0QGVZLsHiZiHR0NbDPGWplQ+ZvrtL+9NgVU27iIvXTw=; b=T8cB0S6uk8GDx1a/G7wbdsSSj3fezUwS6nD19CSq54Y0Ru9vqU0VCFPWmBG5FFJ3OP Mw9Vo1Jjr9rvhBsqmflOasPQp986Bn7wXaiES2yAFk+P9UU2gL2l8usfqXj8GMqSalz2 8iPPH3wBHBhgzl7qMfh/NIFpmKfh5bv7bg3WM6MQqcb1qlvtV4FCYKq2QjVP4VVQr2MG W+0HwHcFr2HqcORYGnsHSVv94EdzyyPCjm3+WOJNGCLRPVfexP8+hPZcVxIOjpR71d2+ sqDF+fsKHzDsjMJbOMvKt/nFmk1r+C7MVUJz2mD5FSDyiNa7XET5xWw1f+ev4kCX+8Xx ToVA== X-Gm-Message-State: ALoCoQkAumTnSauX9VhJoxdzZ0XxvEBybpk1H6uM0m1VVHm2DT4bGCdrmTAdoXUthS+3FoDfEGwD X-Received: by 10.49.12.11 with SMTP id u11mr20595301qeb.21.1376232681692; Sun, 11 Aug 2013 07:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.65.12 with HTTP; Sun, 11 Aug 2013 07:50:41 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C440F3B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43BA02@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C440F3B@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Sun, 11 Aug 2013 07:50:41 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7b6dc1201ef7a004e3ad24fa Cc: "mmusic_ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 14:57:42 -0000 --047d7b6dc1201ef7a004e3ad24fa Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> I think making sure all entities have the correct port numbers is > critical in making sure the media will flow. > > > > There is a difference between "making sure the media will flow" and > "before media can > > flow at all". > > For instance, Neither Firefox nor Chrome current does a second O/A > > transaction and yet media flows just fine in most cases, since they are > operating > > in an unmediated environment. Obviously, this is a best-case scenario, > but similarly > > there are going to be mediated environments which are perfectly happy > with a second > > O/A exchange with non-zero ports. > > There are also environements where a single offer, with identical port > numbers, work just fine, because the receiver will be able to handle it > even if it doesn't support BUNDLE. > > However, we are defining a generic mechanism, supposed to work in > different environments. > "different environments" != "arbitrary lossage by any middlebox in the universe" Again, you need to distinguish between *endpoints* and filtering middleboxes. > But, sure, if the community thinks that we shall define different options, > depending on environments etc, we can do that... > Which is not what I said. -Ekr Regards, > > Christer > > > > > -----Original Message----- > From: Eric Rescorla [ekr@rtfm.com] > To: Christer Holmberg [christer.holmberg@ericsson.com] > > CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; > Paul Kyzivat [pkyzivat@alum.mit.edu] > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only > m- lines? > > > > > > On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > >>> Requiring a second offer to add the bundle-only m-lines defeats the > purpose of bundle-only. > >> We already require a second offer. I know that some people, including > yourself, want to change that, but that is nothing we have agreed on. > >> > >>> a) The delay to do an O/A will often exceed the time to allocate > candidates, for small numbers of streams; bundle-only was meant to avoid > this candidate latency. > >> You do not have to allocate ports for the bundle-only m- lines. > >> > >>> b) Once you have the initial answer, you know whether the other side > supports BUNDLE, so you can take the appropriate action (and so there is no > need for bundle-only). > >>> > >>> If SIP can't deal with the bundle-only concept, then WebRTC apps that > care about latency will have to decide whether they are running in > WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will > be bundled in the initial offer; in compatibility mode, 2 offer-answers > will be needed. > >> There are no "modes" in BUNDLE today :) > >> > > Of course there are. The handling in a reinvite case is distinct from > the initial offer, so that is modal behavior. > > > Sure, but you were talking about "WebRTC-only mode" and "compatibility > mode", and my point is that currently the procedures for initial offers, > subsequent offers etc are the same. > > > >>> This would be a somewhat unfortunate outcome, so I'd like to see > bundle-only (or something like it) work. > >> I don't think the second offer is going to cause any latency. Also, > keep in mind that you only need the 2nd Offer/Answer during the session > establishment. As agreed in Berlin, in mid-session changes you do NOT need > 2 offer/answers. > > > > Please provide support for this statement. It seems clear that a 2nd > offer adds _at least_ 1 RTT latency. > > > Sure, but I don't think that is going to be a practical problem. > > > > Well, I'd like to see a more convincing argument than "some middleboxes > are sad" when you > do that. > > > > > First, there are deployed legacy SIP systems that use even more O/A > transactions during session establishment. And, in your case I assume you > are even going to use something more "lightweight" than SIP to carry your > Offer/Answers. > > Second, as WebRTC mandates usage of ICE, you are often going to need a > subsequent O/A anyway. > > > > It's important to distinguish between round-trips that are in the critical > path for media > flowing and those which are not. > > > -Ekr > --047d7b6dc1201ef7a004e3ad24fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg <c= hrister.holmberg@ericsson.com> wrote:
Hi,

>> I think making sure all entities have the correct port numbers is = critical in making sure the media will flow.
>
> There is a difference between "making sure the media will flow&qu= ot; and "before media can
> flow at all".
> For instance, Neither Firefox nor Chrome current does a second O/A
> transaction and yet media flows just fine in most cases, since they ar= e operating
> in an unmediated environment. Obviously, this is a best-case scenario,= but similarly
> there are going to be mediated environments which are perfectly happy = with a second
> O/A exchange with non-zero ports.

There are also environements where a single offer, with identical por= t numbers, work just fine, because the receiver will be able to handle it e= ven if it doesn't support BUNDLE.

However, we are defining a generic mechanism, supposed to work in different= environments.

"different environm= ents" !=3D "arbitrary lossage by any middlebox in the universe&qu= ot;

Again, you need to distinguish between *endpoints* and = filtering middleboxes.

=A0
But, sure, if the community thinks that we shall define different options, = depending on environments etc, we can do that...

<= /div>
Which is not what I said.

-Ekr

Regards,

Christer




-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
To: Christer Holmberg [ch= rister.holmberg@ericsson.com]

CC: Justin Uberti [juberti@google.com= ]; mmusic@ietf.org [mmusic@ietf.org]; Paul Kyzivat [pkyzivat@alum.mit.edu]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines?





On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:=

Hi,


>>> Requiring a second offer to add the bundle-only m-lines defeat= s the purpose of bundle-only.
>> We already require a second offer. I know that some people, includ= ing yourself, want to change that, but that is nothing we have agreed on. >>
>>> a) The delay to do an O/A will often exceed the time to alloca= te candidates, for small numbers of streams; bundle-only was meant to avoid= this candidate latency.
>> You do not have to allocate ports for the bundle-only m- lines. >>
>>> b) Once you have the initial answer, you know whether the othe= r side supports BUNDLE, so you can take the appropriate action (and so ther= e is no need for bundle-only).
>>>
>>> If SIP can't deal with the bundle-only concept, then WebRT= C apps that care about latency will have to decide whether they are running= in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams wi= ll be bundled in the initial offer; in compatibility mode, 2 offer-answers = will be needed.
>> There are no "modes" in BUNDLE today :)
>>
> Of course there are. The handling in a reinvite case is distinct from = the initial offer, so that is modal behavior.


Sure, but you were talking about "WebRTC-only mode" and "com= patibility mode", and my point is that currently the procedures for in= itial offers, subsequent offers etc are the same.


>>> This would be a somewhat unfortunate outcome, so I'd like = to see bundle-only (or something like it) work.
>> I don't think the second offer is going to cause any latency. = Also, keep in mind that you only need the 2nd Offer/Answer during the sessi= on establishment. As agreed in Berlin, in mid-session changes you do NOT ne= ed 2 offer/answers.
>
> Please provide support for this statement. It seems clear that a 2nd o= ffer adds _at least_ 1 RTT latency.


Sure, but I don't think that is going to be a practical problem.



Well, I'd like to see a more convincing argument than "some middle= boxes are sad" when you
do that.




First, there are deployed legacy SIP systems that use even more O/A transac= tions during session establishment. And, in your case I assume you are even= going to use something more "lightweight" than SIP to carry your= Offer/Answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a subs= equent O/A anyway.



It's important to distinguish between round-trips that are in the criti= cal path for media
flowing and those which are not.


-Ekr

--047d7b6dc1201ef7a004e3ad24fa-- From christer.holmberg@ericsson.com Sun Aug 11 09:34:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA811E813B for ; Sun, 11 Aug 2013 09:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vyjJv2kXpwb for ; Sun, 11 Aug 2013 09:34:45 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB521F867B for ; Sun, 11 Aug 2013 09:29:34 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-1f-5207bbec0d2f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 76.DD.19388.CEBB7025; Sun, 11 Aug 2013 18:29:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Sun, 11 Aug 2013 18:29:32 +0200 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlDHLQN7nRiDYV02hbFJeK66gpJmLcqaAgAAt4U3//+gtgIAAAS4AgAACXICAAAdHAIAAAUGAgAAAYQCAABMsgIAAAuWAgAASG4CAAI712YAAqfkAgABUDKCAABnkgIAAIrhg///pDwCAAZH/EIAAHt8AgACCrF2AABrXgIAAP9yf///8LIAAB0TOUA== Date: Sun, 11 Aug 2013 16:29:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C440FD8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43BA02@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C440F3B@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvre6b3exBBjuapCxWvD7HbrF1qpDF 1OWPWSxWbDjA6sDi8ff9ByaPBZtKPZYs+cnkMflxG3MASxSXTUpqTmZZapG+XQJXxsI9v1kK GlUq2p69YG1gvCzTxcjJISFgInHszTl2CFtM4sK99WxdjFwcQgKHGSXat/QyQjiLGSX+nDnJ 0sXIwcEmYCHR/U8bpEFEQEHi158TLCA2s0ChxMzf/9hASoQFwiT2v4yAKAmXOPxhGxPIGBGB c4wSl+avZwJJsAioSsxf2cAIYvMK+Eo87Z3JCrGrk1tiycIpYAlOgUCJ/T+/gzUwAl33/dQa Johl4hIfDl5nhrhaQGLJnvNQtqjEy8f/WCFsJYnGJU9YIep1JBbs/sQGYWtLLFv4mhlisaDE yZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyipE9NzEzJ73cfBMjMJIObvltsINx032xQ4zSHCxK 4ryb9c4ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDMNA5j9va47vRD6N+xbSqXoqSVv/oI hq6/dPxU89JHDgpiHd5TE2M/SmWxTtP9r3T2hfP+zGuX01Szvm2V2qlpL8fc5WkwZ7vUDEuG /Jf5nqry5Ye9tZo+iLRlnOkMWWz29G7o9dNFjgf3Tq2Re656/IxAo/BnbsENEvkff2Y4Sv3c Z+ry3U6JpTgj0VCLuag4EQDbdiV6cgIAAA== Cc: "mmusic_ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 16:34:52 -0000 Hi, >>>> I think making sure all entities have the correct port numbers is crit= ical in making sure the media will flow. >>> >>> There is a difference between "making sure the media will flow" and "be= fore media can >>> flow at all". >>> For instance, Neither Firefox nor Chrome current does a second O/A >>> transaction and yet media flows just fine in most cases, since they are= operating >>> in an unmediated environment. Obviously, this is a best-case scenario, = but similarly >>> there are going to be mediated environments which are perfectly happy w= ith a second >>> O/A exchange with non-zero ports. >> There are also environements where a single offer, with identical port n= umbers, work just fine, because the receiver will be able to handle it even= if it doesn't support BUNDLE. >> >> However, we are defining a generic mechanism, supposed to work in differ= ent environments. > > "different environments" !=3D "arbitrary lossage by any middlebox in the = universe" > > Again, you need to distinguish between *endpoints* and filtering middlebo= xes. It depends on what you mean by "filtering". If a middlebox removes stuff fr= om the signaling, there is nothing we can do about that. The most simple case I am thinking about is a middlebox forwarding media ba= sed on information in the SDP. > But, sure, if the community thinks that we shall define different options= , depending on environments etc, we can do that... > > Which is not what I said. You did talk about different environments. Wouldn't we need to define the p= rocedures for each environment? Regards, Christer -----Original Message----- From: Eric Rescorla [ekr@rtfm.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; = Paul Kyzivat [pkyzivat@alum.mit.edu] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only = m- lines? On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg wrote: Hi, >>> Requiring a second offer to add the bundle-only m-lines defeats the pur= pose of bundle-only. >> We already require a second offer. I know that some people, including yo= urself, want to change that, but that is nothing we have agreed on. >> >>> a) The delay to do an O/A will often exceed the time to allocate candid= ates, for small numbers of streams; bundle-only was meant to avoid this can= didate latency. >> You do not have to allocate ports for the bundle-only m- lines. >> >>> b) Once you have the initial answer, you know whether the other side su= pports BUNDLE, so you can take the appropriate action (and so there is no n= eed for bundle-only). >>> >>> If SIP can't deal with the bundle-only concept, then WebRTC apps that c= are about latency will have to decide whether they are running in WebRTC-on= ly mode or compatibility mode. In WebRTC-only mode, streams will be bundled= in the initial offer; in compatibility mode, 2 offer-answers will be neede= d. >> There are no "modes" in BUNDLE today :) >> > Of course there are. The handling in a reinvite case is distinct from the= initial offer, so that is modal behavior. Sure, but you were talking about "WebRTC-only mode" and "compatibility mode= ", and my point is that currently the procedures for initial offers, subseq= uent offers etc are the same. >>> This would be a somewhat unfortunate outcome, so I'd like to see bundle= -only (or something like it) work. >> I don't think the second offer is going to cause any latency. Also, keep= in mind that you only need the 2nd Offer/Answer during the session establi= shment. As agreed in Berlin, in mid-session changes you do NOT need 2 offer= /answers. > > Please provide support for this statement. It seems clear that a 2nd offe= r adds _at least_ 1 RTT latency. Sure, but I don't think that is going to be a practical problem. Well, I'd like to see a more convincing argument than "some middleboxes are= sad" when you do that. First, there are deployed legacy SIP systems that use even more O/A transac= tions during session establishment. And, in your case I assume you are even= going to use something more "lightweight" than SIP to carry your Offer/Ans= wers. Second, as WebRTC mandates usage of ICE, you are often going to need a subs= equent O/A anyway. It's important to distinguish between round-trips that are in the critical = path for media flowing and those which are not. -Ekr From christer.holmberg@ericsson.com Sun Aug 11 09:43:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6339611E8144 for ; Sun, 11 Aug 2013 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.803 X-Spam-Level: X-Spam-Status: No, score=-5.803 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkYbr8VhW1jU for ; Sun, 11 Aug 2013 09:43:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6C14B21F9EFF for ; Sun, 11 Aug 2013 09:35:17 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-75-5207bd445215 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8B.FD.19388.44DB7025; Sun, 11 Aug 2013 18:35:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Sun, 11 Aug 2013 18:35:15 +0200 From: Christer Holmberg To: Hadriel Kaplan , Eric Rescorla Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOlpcNJxAkNWX44UaWGCyoMvycbpmQMurA Date: Sun, 11 Aug 2013 16:35:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C440FEB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C0280! 6D1A2204B1C43BA02@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> <3749D352-BD3E-43B0-A060-5D8390F9B24C@oracle.com> In-Reply-To: <3749D352-BD3E-43B0-A060-5D8390F9B24C@oracle.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvra7LXvYgg8XdchYrXp9jt/i06ROz xdTlj1kcmD2WLPnJ5PHx6S0Wj8mP25gDmKO4bFJSczLLUov07RK4MjZtziyYJ1LRs/sCWwPj DIEuRg4OCQETicNnbLsYOYFMMYkL99azdTFycQgJHGaUWNBxlAXCWcwosWlqNzNIA5uAhUT3 P22QBhEBH4ntf34zg9jMAqoSr6d+ZwWxhQXCJPZ0PGCBqAmXOP/mNBOEbSQx+8dlMJsFqP76 iR6wGl4BX4l9E1YwgthCAlu4JN7d8wexOQXsJD6/mcEOYjMCHff91BomiF3iEh8OXmeGOFpA Ysme81C2qMTLx/9YIWwlicYlT1gh6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzUIydhaS lllIWmYhaVnAyLKKkT03MTMnvdx8EyMwZg5u+W2wg3HTfbFDjNIcLErivJv1zgQKCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYLTgdn3IOt3zyxGneeLVJzPDZlTkz6zsO/jQ5J/+xwfBvZ5/ Gl32vancIsN857z3DD9Dh68vHk41erhXa/q25qTS3bvOrDl3Z82KZV/LmB4tLVmhMfHLm8xV d5NWb9p2cWv4aZkfvB1SLc2XA/XWhjLuPaZbkBtg1/o/23Pys/bj2op3j3TPc1RXYinOSDTU Yi4qTgQAaV0zKGcCAAA= Cc: "mmusic_ietf.org" Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 16:43:21 -0000 Hi, >> There is a difference between "making sure the media will flow" and=20 >> "before media can flow at all". For instance, Neither Firefox nor=20 >> Chrome current does a second O/A transaction and yet media flows just=20 >> fine in most cases, since they are operating in an unmediated=20 >> environment. Obviously, this is a best-case scenario, but similarly=20 >> there are going to be mediated environments which are perfectly happy wi= th a second O/A exchange with non-zero ports. >>=20 >> This argues against designing a system in which none of the secondary=20 >> media flows without a second O/A exchange. > > Actually I think it argues against designing a system which treats an App= lication Programming Interface the same as an on-the-wire Internet-wide=20 > negotiation mechanism, with a deployed infrastructure that has been growi= ng larger for the past 10 years. It also argues against tying the fate of= =20 > WebRTC to SIP, with regards to SDP O/A. > > One thing we could do, for example, is define BUNDLE as we've been descri= bing (which is essentially no change, afaik) and define its usage for SDP O= /A as we've been describing. =20 > But we put a "unless the sender has specific knowledge otherwise, as it c= ould in [jsep] for example". Or something like that. Then the JSEP draft = could say what to do for WebRTC usage. You need to convince the people who have been against unless-the-sender-has= -specific-knowledge procedures :) > Take a step back and ignore this particular port-numbering issue for a se= cond: in what context would it make sense for an API to need two separate=20 > rounds of "Offer/Answer" between the Javascript and the Browser? I.e., i= f we weren't using SDP at all, and had never heard of RFC 3264, and just us= ed a=20 > native Javascript API... what use-cases would require the JS script and B= rowser to communicate multiple times between each other for the same action= ?=20 > I think error cases might, for example. And I think if the JS hooked int= o a callback for ICE transport selection changes, then the Browser would ne= ed to=20 > tell it when those things changed, for example. Can you think of any oth= ers? We need to remember that there is other information than the port in the SD= P. For example, there are attributes which will apply to the whole bundle, and= the value set for those attribute may depend on how many m- lines there wi= ll be in the bundle (which, obviously, you don't know until you get the fir= st answer). Regards, Christer From partha@parthasarathi.co.in Sun Aug 11 10:24:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AEB21F9C2D for ; Sun, 11 Aug 2013 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-vYIiKvbswn for ; Sun, 11 Aug 2013 10:24:38 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.236]) by ietfa.amsl.com (Postfix) with ESMTP id C611111E8140 for ; Sun, 11 Aug 2013 10:16:38 -0700 (PDT) Received: from userPC (unknown [122.179.44.66]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id A0C66638F1F; Sun, 11 Aug 2013 17:16:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1376241396; bh=nZCO0VdQp+z4AnMOx68YxIJVA11NoWps1sfxGsLYiGM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=let4kKGNcfOkFRikxQgliWrxlYs6t5Cx9oQdDAl2N+sOMyxFwtsAliaEfj+YX3VHc hMj4q2f/+hRvoXddhWgj7e+uqgAWKMxzbyIDHAYjb8LYqJheYrJmlhusaiElXX/vad H0lSPw5u7NRONT//6vOYLBaxSBnpC9Q6uXj9iwBs= From: "Parthasarathi R" To: "'Eric Rescorla'" , "'Christer Holmberg'" References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806 D1A2204B1C43BA02@ESESS MB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C440F3B@ESESSMB209.ericsson.se> In-Reply-To: Date: Sun, 11 Aug 2013 22:46:27 +0530 Message-ID: <002101ce96b6$8808b790$981a26b0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CE96E4.A1C0F390" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6WoycXRkr58VNlT5eGbrBy0UAVRwAEG6JA Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0208.5207C6F4.0058, 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: 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-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: "'mmusic_ietf.org'" , 'Paul Kyzivat' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 17:24:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01CE96E4.A1C0F390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric, Again, you need to distinguish between *endpoints* and filtering middleboxes. IMO, it is not possible to identify "endpoint" and "filtering middleboxes" based on the protocol exchanges. Both webrtc browser and webrtc gateway handles ICE, SRTP-DTLS, same codecs, SDP in the same way. There is no way to identify WebRTC browser to distinguish whether the remote side is a browser or media gateway during WebRTC session. Please explain in case it is possible to distinguish the remote side is WebRTC browser or WebRTC GW from the originating browser. Thanks Partha From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Sunday, August 11, 2013 8:21 PM To: Christer Holmberg Cc: mmusic_ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg wrote: Hi, >> I think making sure all entities have the correct port numbers is critical in making sure the media will flow. > > There is a difference between "making sure the media will flow" and "before media can > flow at all". > For instance, Neither Firefox nor Chrome current does a second O/A > transaction and yet media flows just fine in most cases, since they are operating > in an unmediated environment. Obviously, this is a best-case scenario, but similarly > there are going to be mediated environments which are perfectly happy with a second > O/A exchange with non-zero ports. There are also environements where a single offer, with identical port numbers, work just fine, because the receiver will be able to handle it even if it doesn't support BUNDLE. However, we are defining a generic mechanism, supposed to work in different environments. "different environments" != "arbitrary lossage by any middlebox in the universe" Again, you need to distinguish between *endpoints* and filtering middleboxes. But, sure, if the community thinks that we shall define different options, depending on environments etc, we can do that... Which is not what I said. -Ekr Regards, Christer -----Original Message----- From: Eric Rescorla [ekr@rtfm.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; Paul Kyzivat [pkyzivat@alum.mit.edu] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg wrote: Hi, >>> Requiring a second offer to add the bundle-only m-lines defeats the purpose of bundle-only. >> We already require a second offer. I know that some people, including yourself, want to change that, but that is nothing we have agreed on. >> >>> a) The delay to do an O/A will often exceed the time to allocate candidates, for small numbers of streams; bundle-only was meant to avoid this candidate latency. >> You do not have to allocate ports for the bundle-only m- lines. >> >>> b) Once you have the initial answer, you know whether the other side supports BUNDLE, so you can take the appropriate action (and so there is no need for bundle-only). >>> >>> If SIP can't deal with the bundle-only concept, then WebRTC apps that care about latency will have to decide whether they are running in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will be bundled in the initial offer; in compatibility mode, 2 offer-answers will be needed. >> There are no "modes" in BUNDLE today :) >> > Of course there are. The handling in a reinvite case is distinct from the initial offer, so that is modal behavior. Sure, but you were talking about "WebRTC-only mode" and "compatibility mode", and my point is that currently the procedures for initial offers, subsequent offers etc are the same. >>> This would be a somewhat unfortunate outcome, so I'd like to see bundle-only (or something like it) work. >> I don't think the second offer is going to cause any latency. Also, keep in mind that you only need the 2nd Offer/Answer during the session establishment. As agreed in Berlin, in mid-session changes you do NOT need 2 offer/answers. > > Please provide support for this statement. It seems clear that a 2nd offer adds _at least_ 1 RTT latency. Sure, but I don't think that is going to be a practical problem. Well, I'd like to see a more convincing argument than "some middleboxes are sad" when you do that. First, there are deployed legacy SIP systems that use even more O/A transactions during session establishment. And, in your case I assume you are even going to use something more "lightweight" than SIP to carry your Offer/Answers. Second, as WebRTC mandates usage of ICE, you are often going to need a subsequent O/A anyway. It's important to distinguish between round-trips that are in the critical path for media flowing and those which are not. -Ekr ------=_NextPart_000_0022_01CE96E4.A1C0F390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

<snip>

Again, you need to distinguish between *endpoints* = and filtering middleboxes.

</snip>

 

IMO, it is not possible to identify = “endpoint” and “filtering middleboxes” based on the protocol exchanges. = Both webrtc browser and webrtc gateway handles ICE, SRTP-DTLS, same codecs, = SDP in the same way. There is no way to identify WebRTC browser to distinguish = whether the remote side is a browser or media gateway during WebRTC session. = Please explain in case it is possible to distinguish the remote side is WebRTC = browser or WebRTC GW from the originating browser.

 

Thanks

Partha

 

From:= mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Eric Rescorla
Sent: Sunday, August 11, 2013 8:21 PM
To: Christer Holmberg
Cc: mmusic_ietf.org; Paul Kyzivat
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines?

 

 

 

On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

Hi,

>> I think making sure all entities have the correct port numbers = is critical in making sure the media will flow.
>
> There is a difference between "making sure the media will = flow" and "before media can
> flow at all".
> For instance, Neither Firefox nor Chrome current does a second = O/A
> transaction and yet media flows just fine in most cases, since they = are operating
> in an unmediated environment. Obviously, this is a best-case = scenario, but similarly
> there are going to be mediated environments which are perfectly = happy with a second
> O/A exchange with non-zero ports.

There are also environements where a single offer, = with identical port numbers, work just fine, because the receiver will be = able to handle it even if it doesn't support BUNDLE.

However, we are defining a generic mechanism, supposed to work in = different environments.

 

"different environments" !=3D = "arbitrary lossage by any middlebox in the universe"

 

Again, you need to distinguish between *endpoints* = and filtering middleboxes.

 

 

But, sure, if the community thinks that we shall = define different options, depending on environments etc, we can do = that...

 

Which is not what I said.

 

-Ekr

 

Regards,

Christer





-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
To: Christer Holmberg [christer.holmberg@ericsson= .com]

CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; Paul Kyzivat [pkyzivat@alum.mit.edu]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for = bundle-only m- lines?





On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:

Hi,


>>> Requiring a second offer to add the bundle-only m-lines = defeats the purpose of bundle-only.
>> We already require a second offer. I know that some people, = including yourself, want to change that, but that is nothing we have agreed = on.
>>
>>> a) The delay to do an O/A will often exceed the time to = allocate candidates, for small numbers of streams; bundle-only was meant to avoid = this candidate latency.
>> You do not have to allocate ports for the bundle-only m- = lines.
>>
>>> b) Once you have the initial answer, you know whether the = other side supports BUNDLE, so you can take the appropriate action (and so = there is no need for bundle-only).
>>>
>>> If SIP can't deal with the bundle-only concept, then WebRTC = apps that care about latency will have to decide whether they are running in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams = will be bundled in the initial offer; in compatibility mode, 2 offer-answers = will be needed.
>> There are no "modes" in BUNDLE today :)
>>
> Of course there are. The handling in a reinvite case is distinct = from the initial offer, so that is modal behavior.


Sure, but you were talking about "WebRTC-only mode" and "compatibility mode", and my point is that currently the = procedures for initial offers, subsequent offers etc are the same.


>>> This would be a somewhat unfortunate outcome, so I'd like = to see bundle-only (or something like it) work.
>> I don't think the second offer is going to cause any latency. = Also, keep in mind that you only need the 2nd Offer/Answer during the session establishment. As agreed in Berlin, in mid-session changes you do NOT = need 2 offer/answers.
>
> Please provide support for this statement. It seems clear that a = 2nd offer adds _at least_ 1 RTT latency.


Sure, but I don't think that is going to be a practical problem.



Well, I'd like to see a more convincing argument than "some = middleboxes are sad" when you
do that.




First, there are deployed legacy SIP systems that use even more O/A transactions during session establishment. And, in your case I assume = you are even going to use something more "lightweight" than SIP to = carry your Offer/Answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a subsequent O/A anyway.



It's important to distinguish between round-trips that are in the = critical path for media
flowing and those which are not.


-Ekr

 

------=_NextPart_000_0022_01CE96E4.A1C0F390-- From miguel.a.garcia@ericsson.com Mon Aug 12 06:02:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5E811E80E1 for ; Mon, 12 Aug 2013 06:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.79 X-Spam-Level: X-Spam-Status: No, score=-4.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC+wfl82nuJ6 for ; Mon, 12 Aug 2013 06:02:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A56D21F9A7D for ; Mon, 12 Aug 2013 05:51:06 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-60-5208da397cd3 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0C.06.03938.93AD8025; Mon, 12 Aug 2013 14:51:05 +0200 (CEST) Received: from [159.107.25.21] (153.88.183.16) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Mon, 12 Aug 2013 14:51:04 +0200 Message-ID: <5208DA37.7040305@ericsson.com> Date: Mon, 12 Aug 2013 14:51:03 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <520568C9.9010603@cisco.com> In-Reply-To: Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvra7lLY4gg2dXbCymdW5ltnh/Qdfi 06ZPzBZTlz9msTj36S6LA6vHlN8bWT2WLPnJ5HH31iUmj49Pb7F4TPiykiWANYrLJiU1J7Ms tUjfLoEro+/kbeaC9S4Vs5ZvZWxgnGPWxcjBISFgIvHxmWUXIyeQKSZx4d56ti5GLg4hgcOM Emsfv2CGcFYxSlx895UFpIpXQFui+UMXM0gzi4CqxMpZkiBhNgFzidaNG9lBbFGBKIkN2y9A lQtKnJz5hAWkXERAT+LoPU6QMLPAdEaJpkchIOOFBfYySfycvZcdYtcERokrjecZQRo4Bewk lpwSgGjQlbjwfwoLhC0vsf3tHGYQW0hAU2LyzaXMExgFZyFZNwtJyywkLQsYmVcxsucmZuak lxtuYgSG8sEtv3V3MJ46J3KIUZqDRUmcd5PemUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jOFbJB/tPa0ncud8586Td/+8+3d6vUjrNMmly5LlZjosN6074LUhx2nrus7lJnvyW8wTko6k ycjWHJ75Oqlc8brQsYoJbsb/7C+fitp55Wa4xCWvdGEp+0OHLzVxWr/WKFgU1mOtN1nTYmXN vzcf9Hem1QS+nn24pmCOatCM2yuP5H4vkuS3VlRiKc5INNRiLipOBABOsEA7MwIAAA== Cc: Flemming Andreasen , Andrew Allen , mmusic Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 13:02:38 -0000 Hi Hadriel:

As far as I remember, the history of the three mechanisms is kind of fuzzy. At some point in time in the past, 3GPP hadn't decided on the architecture to enable CS calls over SIP/SDP, and they were looking into it. The mechanisms were envisioned by the authors and comments on the mailing list, and put at 3GPP's disposal for a choice.

I concur with  your concern that just because we mandate to implement the 3 of them, these are not going to be implemented. I don't have any problem in removing from the draft those mechanisms that we envision they won't be used.

/Miguel
On 10/08/2013 1:28, Hadriel Kaplan wrote:
Wow.  I can kinda understand why they'd say that (interop reasons, presumably), but that's a big deal.  The 3 mechanisms are very different, with very different architectural and deployment implications.  I have a very hard time believing any of us would truly implement all three.  In fact, I don't truly believe anyone would.

So... I hate to do this, but can the authors summarize the history of how we got 3 mechanisms to begin with, and who would really implement them all?

Or to put it another way, instead of specifying all 3, would it be impossible to take a step back and reconsider the real motivating use-case (which as far as I know is 3GPP), and only specify the one they need/use?

-hadriel


On Aug 9, 2013, at 6:10 PM, Flemming Andreasen <fandreas@cisco.com> wrote:


Greetings MMUSIC

As you can see per the below, the IESG approved the Circuit-Switched Bearers draft for publication, however before doing so, they requested a couple of changes. The resulting approved document can be found at http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21

One of the changes introduced resulted in all 3 correlation mechanisms now being mandatory-to-implement (previously they were not):
<quote>
   Implementations MUST support the three correlation mechanisms
   specified in 
Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4
,
   and SHOULD include all supported mechanisms the initial Offer.

</quote>
Since this is a non-trivial change that has not been discussed by the WG (and we know of at least one person having expressed concerns with it off-line), we are hereby solicting the WG participants for input on changes introduced as a result of the IESG review with a focus on the above. In doing so, please keep in mind that we are developing standards that work in the general Internet. 


The following URL provides a diff-file showing the changes resulting from the IESG review:
    http://tools.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sdp-cs-18.txt&url2=draft-ietf-mmusic-sdp-cs-21.txt

Comments are due by August 23 (two weeks from today)

Thanks 

-- Flemming (MMUSIC co-chair)



-------- Original Message --------
Subject:	[MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)
Date:	Mon, 1 Jul 2013 11:56:23 -0700
From:	The IESG <iesg-secretary@ietf.org>
To:	IETF-Announce <ietf-announce@ietf.org>
CC:	mmusic chair <mmusic-chairs@tools.ietf.org>, mmusic mailing list <mmusic@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>

The IESG has approved the following document:
- 'Session Description Protocol (SDP) Extension For Setting Audio and
   Video Media Streams Over Circuit-Switched Bearers In The Public
   Switched Telephone Network (PSTN)'
  (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard

This document is the product of the Multiparty Multimedia Session Control
Working Group.

The IESG contact persons are Gonzalo Camarillo and Richard Barnes.

A URL of this Internet Draft is:

http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/





*Technical Summary
*

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

*Working Group Summary
*

The WG had some discussion around the format to use for E.164 numbers
and whether to align this with the existing definition in RFC 3108. The
RFC 3108 definition was seen as deficient and the WG agreed it was
better to align with relevant parts of the tel URI format defined in RFC
3966, not least since SDP address types are defined in the context of a
particular network type, and hence RFC 3108 compatibility is not a
concern (the implication is that the "E164" address type may differ
between network types in SDP).

*Document Quality
*

There are currently no known implementations of the draft, however the
draft is a dependency for 3GPP, so future implementations are expected.

The document has received good overall review in the WG, some of which
resulted in changes to the detailed specification. The document has been
reviewed in detail several times, including of the last few versions.
The major contributors to these as well as earlier discussions are
listed in the Acknowledgements section of the document.


*Personnel
*

Document Shepherd: Flemming Andreasen
Responsible AD: Gonzalo Camarillo 
_______________________________________________
mmusic mailing list

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

.




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

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



-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
From fandreas@cisco.com Mon Aug 12 09:03:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC1021F8607 for ; Mon, 12 Aug 2013 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaGY+me+jcZc for ; Mon, 12 Aug 2013 09:03:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6B09D21F9EEB for ; Mon, 12 Aug 2013 08:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5603; q=dns/txt; s=iport; t=1376320729; x=1377530329; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q8zhYXEEoBvTg8Bl5gjF5SibhVzSk2t6DG0ukWTJYNc=; b=XxTrjCZBzpmWY8N4ZLfeEcB9zON5GH9Q/f33XTc+AD+WWcQFAUSHbmnF aJ0CLQi3vZOzCot4Q3xd4j/i2vY/AnsQUINY82tz3DmsrX9O5z5hL0B8a oMZWg/lhcurbdtxFfzrjHWpzVRB1WLC15gCmvlzKYCZfZS31EZeyQb42T w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIz7CFKtJV2c/2dsb2JhbABbgwY1vySBGRZ0giQBAQEEAQEBNTYKAQwECxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBF4d1DLZFBI5/gTwHBoQLA5QNg1eRUYM3IIEs X-IronPort-AV: E=Sophos;i="4.89,862,1367971200"; d="scan'208,223";a="246370800" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 12 Aug 2013 15:18:33 +0000 Received: from bxb-fandreas-8812.cisco.com (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7CFIWiG014782; Mon, 12 Aug 2013 15:18:33 GMT Message-ID: <5208FCC8.6000200@cisco.com> Date: Mon, 12 Aug 2013 11:18:32 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B07DDFC@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07DDFC@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:03:48 -0000 From a chair point of view, the intent with "scope is WebRTC" was largely what Paul described as option 1) below although I'd change "solely" to "primarily" (intent being that WebRTC is the primary driver, but if we can trivially and without controversy provide solutions that apply beyond that, then that would be desirable). As Keith points out, this limited scope deliverable creates a new question in terms of scope for all the derived deliverables that have to be developed in the various WGs. It's not clear that we will have a single answer for all of these and taking BUNDLE as an example, it's currently an MMUSIC WG item, but its scope so far has not been limited to WebRTC (and I believe Colin argued in favor of keeping it that way at the Berlin meeting as well). Thanks -- Flemming On 8/7/13 1:26 PM, DRAGE, Keith (Keith) wrote: > I said that all the involved groups need to make a second step with all their deliverables, which is to decide whether what they are doing is used generally, or solely in the context of WEBRTC. > > Deciding whether it is 1) or 2) has not been defined in my understanding, and would really come under the scope of the second decision. > > I for one am hoping as much of this as possible comes out as being generally applicable, and obviously designed as such as a result, but the MMUSIC WG did not appear to be ready to say that last week. So some steps to get there. > > Keith > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 07 August 2013 14:41 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" >> >> On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote: >>> As one of those that used the term, my intention was that the initial >>> decision was to agree to define what RTCWEB needed. >>> >>> As each dependent working group looks at the extensions they need to do, >>> then they need to make the decision as to whether a wider scope of >>> possible, desirable, or dangerous. >>> >>> So the BUNDLE status at the moment is that any changes for the unified >>> plan should work for RTCWEB usage, but not for general. It would >>> probably make sense to make it more generally applicable, but that is >>> the next step in the decision process, and may need some other technical >>> decisions before it happens. >> I don't know how you intend the above to be parsed. Specifically, when >> you say: >> "any changes for the unified plan should work for RTCWEB usage" >> >> Do you mean: >> >> 1) that the changes should be designed solely with RTCWEB usage in mind? >> (But are still applicable in other environments that find them useful >> and choose to adopt them.) >> >> Or do you mean: >> >> 2) that those changes should not be used in any environment other than >> RTCWEB? >> >> I might be able to accept (1), but not (2). >> >> Thanks, >> Paul >> >> >>> Keith >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On >>> Behalf Of *Bernard Aboba >>> *Sent:* 07 August 2013 00:50 >>> *To:* Christer Holmberg; mmusic >>> *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" >>> >>> Christer said: >>> >>> "While cleaning up my MMUSIC notes today, I was listening to the audio >>> recording, in order to get a clarification regarding what "scope is >>> WEBRTC" really means. However, unless I missed something, I didn't get >>> a clear answer. >>> >>> Does it only cover the browser API (JSEP) or does it also cover >>> something that can be sent out on the wire (as long as it is not SIP) by >>> a browser? >>> >>> Feel free to tell me that it is a stupid question, and that the answer >>> is very clear :)" >>> >>> [BA] I actually think it is a good question :) >>> >>> One interpretation of "scope is WebRTC" is that the SDP in "Unified >>> Plan" applies to use within the JSEP API. As a result, one >>> might expect the SDP used in createOffer, setLocalDescription and >>> setRemoteDescription to resemble that in the "Unified Plan" document. >>> Since signaling is out of scope for WebRTC, applications that use the >>> JSEP API might or might not use the "Unified Plan" SDP in signaling on >>> the wire. >>> >>> However, "Unified Plan" includes normative references to published SDP >>> specifications that were developed for general use, and the adoption of >>> "Unified Plan" (or even an applicability statement within the "Unified >>> Plan" document) doesn't change the applicability of those documents. >>> >>> Also, there may be some specifications that are part of the "Unified >>> Plan" workload that may have applicability beyond WebRTC (e.g. a=group: >>> SIMULCAST) >>> >>> Ultimately, I am expecting the work involved in "Unified Plan" to span >>> multiple documents, and to clarify the applicability, those individual >>> documents will need to explain what they apply to (just WebRTC use or >>> more general use). >>> >>> >>> >>> _______________________________________________ >>> 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 fandreas@cisco.com Mon Aug 12 09:05:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795A721F8640 for ; Mon, 12 Aug 2013 09:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLkb4nRH-0sW for ; Mon, 12 Aug 2013 09:05:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACD921F9BB1 for ; Mon, 12 Aug 2013 08:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35462; q=dns/txt; s=iport; t=1376320861; x=1377530461; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=UMpqlNbL06F9QZYyuA1KuQHZD6osrL7F7i7P/Nctpfk=; b=BqstcmOF/sT4zcob1JYOThcBxiGdpDC+VMQb7S5jJ5LYQYbG0QESo6LJ 9GsB9seHOJz/oxyGb6bRpPJP2ayHFcjyN2wfPnGKC4beOx2Iyyanqw4Or O/zI62kR04SSWuw7XR7GcVGWiyO1VTwwACE7h6rfqOmU/VRZNqAo3XWSA I=; X-IronPort-AV: E=Sophos;i="4.89,862,1367971200"; d="scan'208,217";a="246307601" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 12 Aug 2013 15:20:51 +0000 Received: from bxb-fandreas-8812.cisco.com (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7CFKo65009129; Mon, 12 Aug 2013 15:20:50 GMT Message-ID: <5208FD51.2020906@cisco.com> Date: Mon, 12 Aug 2013 11:20:49 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C421552@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C42157D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C42157D@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------020102070404090600080709" Cc: Flemming Andreasen , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:05:20 -0000 This is a multi-part message in MIME format. --------------020102070404090600080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 8/7/13 11:27 AM, Christer Holmberg wrote: > > If everyone has the same understanding, I would ask the chairs to make > it *very clear* in the final minutes ;) > I think the minutes should only reflect what was actually discussed in the meeting so I'm not sure we can record it there. However if we can conclude this thread with general agreement on the interpretation, then we can add a pointer/note to that effect. Thanks -- Flemming > Regards, > > Christer > > *Lähettäjä:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Lähetetty:* 7. elokuuta 2013 18:25 > *Vastaanottaja:* Christer Holmberg > *Kopio:* Paul Kyzivat; mmusic@ietf.org > *Aihe:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > > On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg > > wrote: > > Hi, > > Ok, so what is "RTCWEB usage" then? :) > > For example, if I implement a JavaScript SIP app, and want to use the > UP with SIP on the wire, would that be a "RTCWEB usage"? My > understanding is that it would NOT be. > > My personal understanding of the scope is: > > [MB] That is also my understanding. [/MB] > > 1)JSEP; and > > 2)Browser-to-browser cases where we KNOW there are no > intermediaries etc in between. > > Regards, > > Christer > > *Lähettäjä:*mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org > ] *Puolesta *Mary Barnes > *Lähetetty:* 7. elokuuta 2013 17:56 > *Vastaanottaja:* Paul Kyzivat > *Kopio:* mmusic@ietf.org > *Aihe:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > > On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat > > wrote: > > On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote: > > As one of those that used the term, my intention was that the > initial > decision was to agree to define what RTCWEB needed. > > As each dependent working group looks at the extensions they > need to do, > then they need to make the decision as to whether a wider scope of > possible, desirable, or dangerous. > > So the BUNDLE status at the moment is that any changes for the > unified > plan should work for RTCWEB usage, but not for general. It would > probably make sense to make it more generally applicable, but > that is > the next step in the decision process, and may need some other > technical > decisions before it happens. > > I don't know how you intend the above to be parsed. > Specifically, when you say: > > > "any changes for the unified plan should work for RTCWEB usage" > > Do you mean: > > 1) that the changes should be designed solely with RTCWEB > usage in mind? (But are still applicable in other environments > that find them useful and choose to adopt them.) > > Or do you mean: > > 2) that those changes should not be used in any environment > other than RTCWEB? > > I might be able to accept (1), but not (2). > > [MB] I would agree with your (1), however, not with the > parenthetical part. I would suggest that be "But MAY still be > applicable in other environments... " My concern is that at this > point in time, you can't say that the changes ARE applicable to > other environments .... [/MB] > > > Thanks, > Paul > > Keith > > ------------------------------------------------------------------------ > > *From:*mmusic-bounces@ietf.org > > [mailto:mmusic-bounces@ietf.org > ] *On > Behalf Of *Bernard Aboba > *Sent:* 07 August 2013 00:50 > *To:* Christer Holmberg; mmusic > *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > > > > Christer said: > > "While cleaning up my MMUSIC notes today, I was listening to > the audio > recording, in order to get a clarification regarding what > "scope is > WEBRTC" really means. However, unless I missed something, I > didn't get > a clear answer. > > Does it only cover the browser API (JSEP) or does it also cover > something that can be sent out on the wire (as long as it is > not SIP) by > a browser? > > Feel free to tell me that it is a stupid question, and that > the answer > is very clear :)" > > [BA] I actually think it is a good question :) > > One interpretation of "scope is WebRTC" is that the SDP in > "Unified > Plan" applies to use within the JSEP API. As a result, one > might expect the SDP used in createOffer, setLocalDescription and > setRemoteDescription to resemble that in the "Unified Plan" > document. > Since signaling is out of scope for WebRTC, applications that > use the > JSEP API might or might not use the "Unified Plan" SDP in > signaling on > the wire. > > However, "Unified Plan" includes normative references to > published SDP > specifications that were developed for general use, and the > adoption of > "Unified Plan" (or even an applicability statement within the > "Unified > Plan" document) doesn't change the applicability of those > documents. > > Also, there may be some specifications that are part of the > "Unified > Plan" workload that may have applicability beyond WebRTC (e.g. > a=group: > SIMULCAST) > > Ultimately, I am expecting the work involved in "Unified Plan" > to span > multiple documents, and to clarify the applicability, those > individual > documents will need to explain what they apply to (just WebRTC > use or > more general use). > > _______________________________________________ > 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 --------------020102070404090600080709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/7/13 11:27 AM, Christer Holmberg wrote:

If everyone has the same understanding, I would ask the chairs to make it very clear in the final minutes ;)

 

I think the minutes should only reflect what was actually discussed in the meeting so I'm not sure we can record it there. However if we can conclude this thread with general agreement on the interpretation, then we can add a pointer/note to that effect.

Thanks

-- Flemming


Regards,

 

Christer

 

 

 

Lähettäjä: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Lähetetty: 7. elokuuta 2013 18:25
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; mmusic@ietf.org
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

 

 

 

On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 

Ok, so what is ”RTCWEB usage” then? :)

 

For example, if I implement a JavaScript SIP app, and want to use the UP with SIP on the wire, would that be a “RTCWEB usage”? My understanding is that it would NOT be.

 

My personal understanding of the scope is:

[MB] That is also my understanding. [/MB] 

 

1)      JSEP; and

2)      Browser-to-browser cases where we KNOW there are no intermediaries etc in between.

 

Regards,

 

Christer

 

Lähettäjä: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Puolesta Mary Barnes
Lähetetty: 7. elokuuta 2013 17:56
Vastaanottaja: Paul Kyzivat
Kopio: mmusic@ietf.org
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

 

On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:

As one of those that used the term, my intention was that the initial
decision was to agree to define what RTCWEB needed.

As each dependent working group looks at the extensions they need to do,
then they need to make the decision as to whether a wider scope of
possible, desirable, or dangerous.

So the BUNDLE status at the moment is that any changes for the unified
plan should work for RTCWEB usage, but not for general. It would
probably make sense to make it more generally applicable, but that is
the next step in the decision process, and may need some other technical
decisions before it happens.

 

I don't know how you intend the above to be parsed. Specifically, when you say:


  "any changes for the unified plan should work for RTCWEB usage"

Do you mean:

1) that the changes should be designed solely with RTCWEB usage in mind? (But are still applicable in other environments that find them useful and choose to adopt them.)

Or do you mean:

2) that those changes should not be used in any environment other than RTCWEB?

I might be able to accept (1), but not (2).

[MB] I would agree with your (1), however, not with the parenthetical part.  I would suggest that be "But MAY still be applicable in other environments... "   My concern is that at this point in time, you can't say that the changes ARE applicable to other environments ....  [/MB]

 


        Thanks,
        Paul

Keith

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

*From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On
Behalf Of *Bernard Aboba
*Sent:* 07 August 2013 00:50
*To:* Christer Holmberg; mmusic
*Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"



Christer said:

"While cleaning up my MMUSIC notes today, I was listening to the audio
recording, in order to get a clarification regarding what "scope is
WEBRTC" really means.  However, unless I missed something, I didn't get
a clear answer.

Does it only cover the browser API (JSEP) or does it also cover
something that can be sent out on the wire (as long as it is not SIP) by
a browser?

Feel free to tell me that it is a stupid question, and that the answer
is very clear :)"

[BA]  I actually think it is a good question :)

One interpretation of "scope is WebRTC"  is that the  SDP in "Unified
Plan" applies to use within  the JSEP API.    As a result, one
might expect the SDP used in createOffer, setLocalDescription and
setRemoteDescription to resemble that in the "Unified Plan" document.
Since signaling is out of scope for WebRTC, applications that use the
JSEP API might or might not use the "Unified Plan" SDP in signaling on
the wire.

However, "Unified Plan" includes normative references to published SDP
specifications that were developed for general use, and the adoption of
"Unified Plan" (or even an applicability statement within the "Unified
Plan" document) doesn't change the applicability of those documents.

Also, there may be some specifications that are part of the "Unified
Plan" workload that may have applicability beyond WebRTC (e.g. a=group:
SIMULCAST)

Ultimately, I am expecting the work involved in "Unified Plan" to span
multiple documents, and to clarify the applicability,  those individual
documents will need to explain what they apply to (just WebRTC use or
more general use).

_______________________________________________
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

--------------020102070404090600080709-- From ron.even.tlv@gmail.com Mon Aug 12 23:59:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468D311E8142 for ; Mon, 12 Aug 2013 23:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6dy5s0mMbj2 for ; Mon, 12 Aug 2013 23:59:05 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1376111E8118 for ; Mon, 12 Aug 2013 23:59:04 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id f14so713933wiw.2 for ; Mon, 12 Aug 2013 23:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=sIP3E46elGZ98CktUOkJUm6w/Y+shHv/dgEbLrkANxU=; b=t9wkVyxNEyrukqmJtLV0+enC2uGKT+spraJ8f5HY4HDFKWd/waetMh6AgjZ0ck16LY +46DISLj2SELdqcTlgt3pzON79JnPv520WJDWK23BUEkB2Uu5S9g5Eg7SWare0UJkj49 93jPJJamXMHx5xAwqkLGbRO8C8RJdviXtd+nrwRCH8wI+aZloYhIMz/4ccR+uqLimbrM Uj1StuLwXMRBw2Hc47qF2VpIRG+6PEib4ssOcs2pVvauED5xe7yytOX/tM7XHqs2OBx1 x8zkCw+cdHdCateucCrNVyXLY2Ao2Wr8BM4zTqv09/ThPlWkUz5NNBeEN1vkpROmnNvi EHvw== X-Received: by 10.180.9.69 with SMTP id x5mr1647906wia.41.1376377144159; Mon, 12 Aug 2013 23:59:04 -0700 (PDT) Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id eb3sm1234744wic.10.2013.08.12.23.59.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 12 Aug 2013 23:59:03 -0700 (PDT) From: "Roni Even" To: "'Flemming Andreasen'" , "'DRAGE, Keith \(Keith\)'" References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B07DDFC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5208FCC8.6000200@cisco.com> In-Reply-To: <5208FCC8.6000200@cisco.com> Date: Tue, 13 Aug 2013 09:56:50 +0300 Message-ID: <008801ce97f2$4b4620d0$e1d26270$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHw5bHJknmCM9q3FFXt/gD98lUVTQI3E7SjAnqJDWEBoUTLkQFaTbZUAlt2n9OY/dG+oA== Content-Language: en-us Cc: mmusic@ietf.org, 'Paul Kyzivat' Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 06:59:06 -0000 Hi, I agree with Paul's first option. I think that section 2 of the UP draft provides the solution overview and some of the points are solely RTCweb while some of the points may be used by other solution. One important point made in the presentation was that this does not change RFC3264 so others can choose different solution, for example, instead of the first two bullet items in section 2 while not changing RFC3264 . Since this solution does not change RFC3264 I see no problem on the scope of work in other WG. It just need to be clear about the applicability of the work and having it address both RFC3264 and UP. Roni Even > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Flemming Andreasen > Sent: 12 August, 2013 6:19 PM > To: DRAGE, Keith (Keith) > Cc: mmusic@ietf.org; Paul Kyzivat > Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > > From a chair point of view, the intent with "scope is WebRTC" was largely > what Paul described as option 1) below although I'd change "solely" to > "primarily" (intent being that WebRTC is the primary driver, but if we can > trivially and without controversy provide solutions that apply beyond that, > then that would be desirable). > > As Keith points out, this limited scope deliverable creates a new question in > terms of scope for all the derived deliverables that have to be developed in > the various WGs. It's not clear that we will have a single answer for all of > these and taking BUNDLE as an example, it's currently an MMUSIC WG item, > but its scope so far has not been limited to WebRTC (and I believe Colin > argued in favor of keeping it that way at the Berlin meeting as well). > > Thanks > > -- Flemming > > > On 8/7/13 1:26 PM, DRAGE, Keith (Keith) wrote: > > I said that all the involved groups need to make a second step with all their > deliverables, which is to decide whether what they are doing is used > generally, or solely in the context of WEBRTC. > > > > Deciding whether it is 1) or 2) has not been defined in my understanding, > and would really come under the scope of the second decision. > > > > I for one am hoping as much of this as possible comes out as being > generally applicable, and obviously designed as such as a result, but the > MMUSIC WG did not appear to be ready to say that last week. So some steps > to get there. > > > > Keith > > > > > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: 07 August 2013 14:41 > >> To: mmusic@ietf.org > >> Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > >> > >> On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote: > >>> As one of those that used the term, my intention was that the > >>> initial decision was to agree to define what RTCWEB needed. > >>> > >>> As each dependent working group looks at the extensions they need to > >>> do, then they need to make the decision as to whether a wider scope > >>> of possible, desirable, or dangerous. > >>> > >>> So the BUNDLE status at the moment is that any changes for the > >>> unified plan should work for RTCWEB usage, but not for general. It > >>> would probably make sense to make it more generally applicable, but > >>> that is the next step in the decision process, and may need some > >>> other technical decisions before it happens. > >> I don't know how you intend the above to be parsed. Specifically, > >> when you say: > >> "any changes for the unified plan should work for RTCWEB usage" > >> > >> Do you mean: > >> > >> 1) that the changes should be designed solely with RTCWEB usage in > mind? > >> (But are still applicable in other environments that find them useful > >> and choose to adopt them.) > >> > >> Or do you mean: > >> > >> 2) that those changes should not be used in any environment other > >> than RTCWEB? > >> > >> I might be able to accept (1), but not (2). > >> > >> Thanks, > >> Paul > >> > >> > >>> Keith > >>> > >>> -------------------------------------------------------------------- > >>> ---- > >>> > >>> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] > *On > >>> Behalf Of *Bernard Aboba > >>> *Sent:* 07 August 2013 00:50 > >>> *To:* Christer Holmberg; mmusic > >>> *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > >>> > >>> Christer said: > >>> > >>> "While cleaning up my MMUSIC notes today, I was listening to the > >>> audio recording, in order to get a clarification regarding what > >>> "scope is WEBRTC" really means. However, unless I missed something, > >>> I didn't get a clear answer. > >>> > >>> Does it only cover the browser API (JSEP) or does it also cover > >>> something that can be sent out on the wire (as long as it is not > >>> SIP) by a browser? > >>> > >>> Feel free to tell me that it is a stupid question, and that the > >>> answer is very clear :)" > >>> > >>> [BA] I actually think it is a good question :) > >>> > >>> One interpretation of "scope is WebRTC" is that the SDP in "Unified > >>> Plan" applies to use within the JSEP API. As a result, one > >>> might expect the SDP used in createOffer, setLocalDescription and > >>> setRemoteDescription to resemble that in the "Unified Plan" document. > >>> Since signaling is out of scope for WebRTC, applications that use > >>> the JSEP API might or might not use the "Unified Plan" SDP in > >>> signaling on the wire. > >>> > >>> However, "Unified Plan" includes normative references to published > >>> SDP specifications that were developed for general use, and the > >>> adoption of "Unified Plan" (or even an applicability statement > >>> within the "Unified Plan" document) doesn't change the applicability of > those documents. > >>> > >>> Also, there may be some specifications that are part of the "Unified > >>> Plan" workload that may have applicability beyond WebRTC (e.g. > a=group: > >>> SIMULCAST) > >>> > >>> Ultimately, I am expecting the work involved in "Unified Plan" to > >>> span multiple documents, and to clarify the applicability, those > >>> individual documents will need to explain what they apply to (just > >>> WebRTC use or more general use). > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 internet-drafts@ietf.org Tue Aug 13 05:13:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7AF11E8179; Tue, 13 Aug 2013 05:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGvRrbTfD6+P; Tue, 13 Aug 2013 05:13:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0AA21E80AE; Tue, 13 Aug 2013 05:13:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130813121332.12135.94185.idtracker@ietfa.amsl.com> Date: Tue, 13 Aug 2013 05:13:32 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:13:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Cross Session Stream Identification in the Session Descr= iption Protocol Author(s) : Harald Alvestrand Filename : draft-ietf-mmusic-msid-01.txt Pages : 14 Date : 2013-08-13 Abstract: This document specifies a 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-msid-01 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 harald@alvestrand.no Tue Aug 13 05:24:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F1221F87B7 for ; Tue, 13 Aug 2013 05:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzTS5unBhLAV for ; Tue, 13 Aug 2013 05:24:12 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFD711E816D for ; Tue, 13 Aug 2013 05:24:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EA0D39E246 for ; Tue, 13 Aug 2013 14:24:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgz2081Vx8aE for ; Tue, 13 Aug 2013 14:24:05 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6BC6439E170 for ; Tue, 13 Aug 2013 14:24:05 +0200 (CEST) Message-ID: <520A2564.7090404@alvestrand.no> Date: Tue, 13 Aug 2013 14:24:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mmusic@ietf.org" References: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> In-Reply-To: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000203050105000906080708" Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:24:26 -0000 This is a multi-part message in MIME format. --------------000203050105000906080708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The auto-poster doesn't seem to want to tell mmusic about this.... this is updated according to Unified-plan. Since it was only 1 day before the old version had expired, the proofreading might be a little light - please point out places where I had missed changing "SSRC" to "m-line"! I retained some description of the old mechanism (using a=ssrc) in an appendix. Please state opinions on whether this should be retained as informative, promoted to normative, or removed entirely in the next version. Hope this informs! Harald -------- Original Message -------- Subject: New Version Notification for draft-ietf-mmusic-msid-01.txt Date: Tue, 13 Aug 2013 05:13:42 -0700 From: internet-drafts@ietf.org To: Harald T. Alvestrand , Harald Alvestrand A new version of I-D, draft-ietf-mmusic-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-ietf-mmusic-msid Revision: 01 Title: Cross Session Stream Identification in the Session Description Protocol Creation date: 2013-08-13 Group: mmusic Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid Htmlized: http://tools.ietf.org/html/draft-ietf-mmusic-msid-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01 Abstract: This document specifies a 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. 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 --------------000203050105000906080708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit The auto-poster doesn't seem to want to tell mmusic about this....

this is updated according to Unified-plan. Since it was only 1 day before the old version had expired, the proofreading might be a little light - please point out places where I had missed changing "SSRC" to "m-line"!

I retained some description of the old mechanism (using a=ssrc) in an appendix. Please state opinions on whether this should be retained as informative, promoted to normative, or removed entirely in the next version.

Hope this informs!

       Harald


-------- Original Message --------
Subject: New Version Notification for draft-ietf-mmusic-msid-01.txt
Date: Tue, 13 Aug 2013 05:13:42 -0700
From: internet-drafts@ietf.org
To: Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand <harald@alvestrand.no> 


A new version of I-D, draft-ietf-mmusic-msid-01.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Filename:	 draft-ietf-mmusic-msid
Revision:	 01
Title:		 Cross Session Stream Identification in the Session Description Protocol
Creation date:	 2013-08-13
Group:		 mmusic
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid
Htmlized:        http://tools.ietf.org/html/draft-ietf-mmusic-msid-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01

Abstract:
   This document specifies a 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.


                                                                                  


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


--------------000203050105000906080708-- From magnus.westerlund@ericsson.com Tue Aug 13 06:09:17 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414E911E8162 for ; Tue, 13 Aug 2013 06:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGwyY9EIiNoT for ; Tue, 13 Aug 2013 06:09:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9077311E8167 for ; Tue, 13 Aug 2013 06:09:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-02-520a2ff2f4e8 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 66.1D.03938.2FF2A025; Tue, 13 Aug 2013 15:09:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Tue, 13 Aug 2013 15:09:05 +0200 Message-ID: <520A302E.7010508@ericsson.com> Date: Tue, 13 Aug 2013 15:10:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= References: <20130718161212.19084.19711.idtracker@ietfa.amsl.com> <51F61F88.1000503@ericsson.com> In-Reply-To: <51F61F88.1000503@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VveTPleQQccDcYv3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZZx7dJ+t4JVwxarL7SwNjG/5uxg5OSQETCQW vNzJBGGLSVy4t56ti5GLQ0jgMKNE369vjBDOckaJj/33mEGqeAW0JV4vaWQFsVkEVCVaej6y gdhsAhYSN380gtmiAsES7du/skHUC0qcnPmEBcQWEbCW6DzyHKyXWcBVYtWu2UAzOTiEBaok ji01BwkLCSRKdC76yQ5icwroSJx89ZsN4jhJiW2LjrFDtGpKtG7/DWXLSzRvnc0M0ast0dDU wTqBUWgWks2zkLTMQtKygJF5FSN7bmJmTnq54SZGYKAe3PJbdwfjqXMihxilOViUxHk36Z0J FBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCYXVjO2+els62eYyo3k1b2HuWf2kvvF/ZdtfWf vExZ8WFQ2owH6ys+Xi3m6pnQI/P0kOydCdZTdO44X6oKUp7Y+9k+J/JMZpL/puWMPydmHO9d 3ffj4PEnAnwq5ybxHLkt45qRZb7+9aSkXTkHQhdoTvkbe892fVfJtl+iHe+T2XktxSQZPNYr sRRnJBpqMRcVJwIA3LHAhCICAAA= Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] New Liaison Statement, "LS on Missing IANA Registration Information on SDP Attributes in RFC 2326" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 13:09:17 -0000 On 2013-07-29 09:53, Ari Keränen wrote: > MMUSIC, > > We have received a liaison statement from 3GPP regarding missing SDP > attributes at the IANA registry (see the e-mail below for details). > > As the statement says: >> SA4 has identified that IANA registrations of three SDP attributes >> defined in RFC 2326, namely ‘control’, ‘range’ and ‘etag’, are missing > > As a solution, the RTSP 2.0 draft already registers 'control' and > 'range' for RFC 2326 and RFC 2326bis > (http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-34#section-22.15). > However, in RFC2326bis 'etag' is renamed into 'mtag'. > > Hence, it seems that we should also register 'etag' but for that > reference RTSP 1.0 (RFC 2326) only. > > Please review the liaison statement and our proposed solution and send > your comments to us and to the list. WG, I volunteer to send an email registering these SDP attributes to IANA so that a respond can be sent to 3GPP SA4 that they attribute has been registered. I propose to include all attributes in that registration. I can clarify in the RFC 2326bis draft that the SDP registrations are an update to what we put in at this stage. I have also chosen to put "etag" in the both category due to that is what has been done in the RFC2326bis draft as the original text is far from clear if it is a session only or not. Thus I propose to send the below to IANA on Monday (19th of Aug) unless someone disagree. > Dear IANA, > > It has come to our attention that the SDP attributes defined in RFC 2326 > are not registered in the SDP attributes registry, i.e. related to RFC > 4566 found at: > www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml > > In registry: att-field (both session and media level) > > Please add the following SDP Attributes: > > SDP Name: control > Reference: RFC 2326 > > SDP Name: range > Reference: RFC 2326 > > SDP Name: etag > Reference: RFC 2326 > > Contact: Authors of RFC 2326 > > Thanks > > Magnus Westerlund Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fluffy@cisco.com Tue Aug 13 15:54:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB60F21F99F4 for ; Tue, 13 Aug 2013 15:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG1NGs822bya for ; Tue, 13 Aug 2013 15:54:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8F21F86D2 for ; Tue, 13 Aug 2013 15:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2734; q=dns/txt; s=iport; t=1376434455; x=1377644055; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EMmCwmnSMlvkxSD8TlFpaNi13VO9Wv68ayxeMVY1dS4=; b=Q+KfPrO9U/Am2zQFck1HSbs9/1NP1Sv5Wj3P9eIzBdYWL9USDxtogoEs CLhOujYQGcSrvu8A5FWPUMFFovA8YEvKoiUdhWytooxh34bM4CZMvl2dW VLkLeoK9ZNK9BaOuQVZxFL5MN/z2wq3p42D1RYjlY0I1AxL8yw2FwPoIg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAOq3ClKtJV2Y/2dsb2JhbABSCYMGNVC+YoEkFnSCJAEBAQMBAQEBawsFBwQCAQgVAgEKJCcLFwEFCAIEDgUIiAIGDLg0jnYDgRACMQcGgxV2A4h1oECDG4FoQg X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246956096" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2013 22:54:11 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7DMsBRF007791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 22:54:11 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 17:54:11 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] UP: Can a partial offer be a full offer? Thread-Index: AQHOmHgF5DCVxsS/xE6h7VSvSxBlBw== Date: Tue, 13 Aug 2013 22:54:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <24B4EB410FC3624D93FBD04F5AE94F9C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:54:30 -0000 You only want to send the m blocks that have changed because if you send ot= her ones, you up the chances of both sides sending the same m block at the = same time and being back into the glare problem.=20 It seems to me the options are either 1 or 2 would make sense=20 1) the sender SHOULD only send m m blocks with a change (which might be al= l of them) and receiver MUST be prepared to receive any number.=20 2) you can only send one m block in a partial Off or Ans - but you can hav= e several outstanding at a time On Aug 5, 2013, at 10:35 AM, Christer Holmberg wrote: > Hi, > =20 > I see no issue with multiple m- lines - just wanted to verify that it wou= ld be allowed :) > =20 > Regards, > =20 > Christer > =20 >=20 >=20 > Sent from Windows using TouchDown (www.nitrodesk.com) >=20 > -----Original Message----- > From: Hadriel Kaplan [hadriel.kaplan@oracle.com] > To: Christer Holmberg [christer.holmberg@ericsson.com] > CC: mmusic [mmusic@ietf.org] > Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? >=20 > On Aug 5, 2013, at 11:17 AM, Christer Holmberg wrote: >=20 > > Note that my re-INVITE/UPDATE example is based on the assumption that o= ne can use partial offers/answers with SIP, on the wire. Not sure if that w= as part of the agreed scope for the UP. >=20 > Definitely NOT agreed on. Doesn't mean it won't happen in the future, bu= t the scope of UP was limited to WebRTC for now. We can debate which parts= of UP are generically applicable, and which not. For SIP, this isn't the = right WG for that debate. >=20 >=20 > > But, even without that, I think the question on including all m- lines = on a partial offer still applies :) >=20 > I don't see why WebRTC would restrict itself in any way regarding the num= ber of m-lines in a partial offer/answer. Nothing "breaks" if all m-lines = are in it, does it? The real question is if it can be greater than *one* m= -line. If it can, and I think it can, then I can't see how the exact quant= ity of them matters. The only downside is you increase the chance of glare= , I assume. >=20 > Afaik, the 'mid' attribute is there to identity which m-lines in the part= ial offer correspond to which m-lines in the full ordered set. (the 'mid' c= ould have even been an index number, except it's also used to avoid glare w= hen adding m-lines, which a numeric index wouldn't have done) So what's th= e issue with one or multiple m-lines? >=20 > -hadriel >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Tue Aug 13 15:55:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129D321F9B25 for ; Tue, 13 Aug 2013 15:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHmGUzQXUTQd for ; Tue, 13 Aug 2013 15:55:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6E86421F99DD for ; Tue, 13 Aug 2013 15:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1219; q=dns/txt; s=iport; t=1376434547; x=1377644147; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h/7RApNMIspXdCcVcVaOtfMN/8iu+2hHjJ8TB4f8fag=; b=OxRliQh1Z/LsivWfgYaVen26NkBTcGH9J+4VwnhjyVD1OU2GYuNcjt+t +gvIfVad6bKJsf0MwQsE58uaxBJxb9Iiiqz/Fy5ZVcCSlzFpmL8MTusWl hnZQq51EfMNS3/R1ZCDREyq0/HFWaEQFYY+m6hwit5/dQItfN6h4pxFOB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABa5ClKtJXHA/2dsb2JhbABbgwY1UL5igSQWdIIkAQEBAwEBAQFrCxACAQgiJCcLFwENAgQOBQiIAgYMuDSQCQIxB4MbdgOIdaBAgxuCKg X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246956693" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2013 22:55:47 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7DMtkmK012314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 22:55:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 17:55:46 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers Thread-Index: AQHOmHg+qXhJDQ8zikGj6XYHE/Q+mA== Date: Tue, 13 Aug 2013 22:55:45 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8276B7F50AE1B54998C7A08F923F4B08@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:55:55 -0000 On Aug 6, 2013, at 10:14 AM, Christer Holmberg wrote: >=20 > Hi, > =20 > It has been indicated that POFs (partial offers) and PANs (partial answer= s) form a stand-alone mechanism, instead of being an extension of RFC3264. uh, I don't think so. THey seem sot be an optional extension to 3264 >=20 > Now, assuming that is true, we still need to describe the interaction bet= ween POFs, PANs and 3264 Offer/Answers. > =20 > Because, if I send a POF, and then receive a 3264 Offer (including the sa= me m- line as the POF), there is a glare and I need to reject the 3264 Off= er. > =20 > In the same way, if I send a 3264 Offer, and receive a POF (including the= same m- line as the 3264 Offer), there is a glare and I need to reject the= POF. > =20 > I ASSUME the above is clear to everyone, including the authors of the UP,= but IF someone has a different opinion I'd like to hear about it :) > =20 > Regards, > =20 > Christer > =20 > =20 >=20 > Sent from Windows using TouchDown (www.nitrodesk.com) > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fluffy@cisco.com Tue Aug 13 15:58:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A803921F9B12 for ; Tue, 13 Aug 2013 15:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvZJMKiTEM5j for ; Tue, 13 Aug 2013 15:58:18 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CCCA121F9B28 for ; Tue, 13 Aug 2013 15:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=485; q=dns/txt; s=iport; t=1376434698; x=1377644298; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5gOQxrDwrW8X49v0cJNW08M6d7P+Nd+3PgPPMlr4io0=; b=SWjpQAKoZO7Fz+tPENW/WDGy5IJYlHU/X8x33zPasGls7cdqTSgndYBa ASWfSdT2Y8O6AApNJon+969itY1eujuh93oqosijemT+wWHTwNOaoMK62 tHocB7zq9EQbrnwGcYW788nXbfgAIbE5GE/jkQpBO9M0VEKI8xNaz4Y94 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAFK5ClKtJV2c/2dsb2JhbABbgwaBBYJRvBGBJBZ0giQBAQEDATo/BQsCAQgiFBAhESUCBA4FCId2AwkGr1YNiF6NRYJEAjEHgxt2A5QNgW6OE4UngxuCKg X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246967350" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 13 Aug 2013 22:58:13 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7DMwCso014039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 22:58:13 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 17:58:12 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [MMUSIC] unified plan glareless atomicity improvement Thread-Index: AQHOmHiW0Yvg/Bi3eUufcMux4yZpCg== Date: Tue, 13 Aug 2013 22:58:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:58:37 -0000 On Jul 31, 2013, at 6:16 AM, Martin Thomson wrot= e: > I think that the only guidance needed is something like: > "Implementations MAY choose to exclusively use m-lines with a=3Dsendonly > or a=3Drecvonly in order to further reduce the probably of encountering > glare." that can't be the default for non bundle lines or it won't work with existi= ng stuff which was the whole point of this. It's not clear it helps reduce = glare in general. From fluffy@cisco.com Tue Aug 13 16:03:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAC021F9E51 for ; Tue, 13 Aug 2013 16:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcDAimBJEqJV for ; Tue, 13 Aug 2013 16:03:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 018DC21F9E3A for ; Tue, 13 Aug 2013 16:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=422; q=dns/txt; s=iport; t=1376434982; x=1377644582; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lFaL4msPQgdFj8DxGsHhWSWiaDIWjt7828QhrN560l0=; b=dYB8EeJVxOemet8BJgXuNM6+MB4vpi93m919wo/zjDMzGIBfWmrwJ79m 28D4CBzFsOpZ6V/0I8zAMDFHtVwiCW5N38GLxJmEAM81HvyVu83HD05th IyH4SQqgWO2n9NRX/vQtXVX+85w7MvPUdxP8Q2iPBSzU+NNMqw2f8cLNq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPe6ClKtJXHA/2dsb2JhbABbgwaBBYJRvBGBJRZ0giQBAQEDATo/BQsCAQgiFAULMiUCBA4FCIgCBrhBkAkCMQeDG3YDqTWBYYE6gio X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246945516" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 13 Aug 2013 23:02:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7DN2kkH024360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 23:02:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 18:02:46 -0500 From: "Cullen Jennings (fluffy)" To: Parthasarathi R Thread-Topic: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) Thread-Index: AQHOmHk54lNJQqUf4UidS6d0cE4jXw== Date: Tue, 13 Aug 2013 23:02:45 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <52011AF8.10003@alum.mit.edu> <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C4216BD@ESESSMB209.ericsson.se> <18CF11C2-B5C7-4895-A58B-308F76B94CED@oracle.com> <00e901ce93b8$22bbed90$6833c8b0$@co.in> In-Reply-To: <00e901ce93b8$22bbed90$6833c8b0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:03:07 -0000 On Aug 7, 2013, at 3:50 PM, Parthasarathi R wr= ote: > Hi all, >=20 > It is a concern area for UP plan in case it works only for WebRTC and not > for SIP/general. The changing current BUNDLE approach breaks interop with > SIP/legacy endpoints.=20 >=20 > Thanks > Partha I disagree. The whole point was to make it work and I believe it does with = the stuff I have tested.=20 From fluffy@cisco.com Tue Aug 13 16:10:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5674921E805A for ; Tue, 13 Aug 2013 16:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFDgdh4B6ief for ; Tue, 13 Aug 2013 16:09:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 171D621E8180 for ; Tue, 13 Aug 2013 16:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2974; q=dns/txt; s=iport; t=1376435398; x=1377644998; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jV0NoZcqRgQIoU63Dzg/s+O+0lWNclipvSKehfXXtLU=; b=hmcRnzjhCVY9NouA6V/J+113ULKSFaABKqj9mkxsw6o2q5CzlT58/s/D cZdRMppnap9HgPOzy40b1aoBBjmZ88gcfBjrzDDH7TvrOOT9z+Yw29axe HOUeXashXgk1D7h1EMG+tFsy/40pSUNZBZ/mr5sdSrhyliO353Y1Jp1n7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAFa8ClKtJV2c/2dsb2JhbABbgwY1UL5igSUWdIIkAQEBAwEBAQEJPSUGBQ4CAgEIGAoZBAcbDAsUEQIEDgUIARKHbwYMuDUEgxGLWhCBCgIxB4MbdgOZEYkHhx2BYYE6gXE5 X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246990342" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 13 Aug 2013 23:09:57 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7DN9v5L029061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 23:09:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 18:09:57 -0500 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund Thread-Topic: [MMUSIC] New Liaison Statement, "LS on Missing IANA Registration Information on SDP Attributes in RFC 2326" Thread-Index: AQHOmHo507qOXT5k+0qudm2fHfsl6w== Date: Tue, 13 Aug 2013 23:09:56 +0000 Message-ID: References: <20130718161212.19084.19711.idtracker@ietfa.amsl.com> <51F61F88.1000503@ericsson.com> <520A302E.7010508@ericsson.com> In-Reply-To: <520A302E.7010508@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <84050471D80624469968D3B42124C653@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] New Liaison Statement, "LS on Missing IANA Registration Information on SDP Attributes in RFC 2326" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:10:03 -0000 Sounds reasonable to me. On Aug 13, 2013, at 7:10 AM, Magnus Westerlund wrote: >=20 >=20 > On 2013-07-29 09:53, Ari Ker=E4nen wrote: >> MMUSIC, >>=20 >> We have received a liaison statement from 3GPP regarding missing SDP >> attributes at the IANA registry (see the e-mail below for details). >>=20 >> As the statement says: >>> SA4 has identified that IANA registrations of three SDP attributes >>> defined in RFC 2326, namely =91control=92, =91range=92 and =91etag=92, = are missing >>=20 >> As a solution, the RTSP 2.0 draft already registers 'control' and >> 'range' for RFC 2326 and RFC 2326bis >> (http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-34#section-22.1= 5). >> However, in RFC2326bis 'etag' is renamed into 'mtag'. >>=20 >> Hence, it seems that we should also register 'etag' but for that >> reference RTSP 1.0 (RFC 2326) only. >>=20 >> Please review the liaison statement and our proposed solution and send >> your comments to us and to the list. >=20 > WG, >=20 > I volunteer to send an email registering these SDP attributes to IANA so > that a respond can be sent to 3GPP SA4 that they attribute has been > registered. I propose to include all attributes in that registration. I > can clarify in the RFC 2326bis draft that the SDP registrations are an > update to what we put in at this stage. I have also chosen to put "etag" > in the both category due to that is what has been done in the RFC2326bis > draft as the original text is far from clear if it is a session only or n= ot. >=20 > Thus I propose to send the below to IANA on Monday (19th of Aug) unless > someone disagree. >=20 >=20 >> Dear IANA, >>=20 >> It has come to our attention that the SDP attributes defined in RFC 2326 >> are not registered in the SDP attributes registry, i.e. related to RFC >> 4566 found at: >> www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml >>=20 >> In registry: att-field (both session and media level) >>=20 >> Please add the following SDP Attributes: >>=20 >> SDP Name: control >> Reference: RFC 2326 >>=20 >> SDP Name: range >> Reference: RFC 2326 >>=20 >> SDP Name: etag >> Reference: RFC 2326 >>=20 >> Contact: Authors of RFC 2326 >>=20 >> Thanks >>=20 >> Magnus Westerlund >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Tue Aug 13 16:27:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BD021E8186 for ; Tue, 13 Aug 2013 16:27:29 -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=-2.599, J_CHICKENPOX_18=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJchL1aMtZAd for ; Tue, 13 Aug 2013 16:27:28 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93321F9980 for ; Tue, 13 Aug 2013 16:27:28 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so7150119wes.2 for ; Tue, 13 Aug 2013 16:27:27 -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=2sHv+3xBNn2iaMkG5worKSWcd0OYUkdpL6R26zUWzr4=; b=gu13Qw21PFkS2mRAhyLlZudNOaDm+61qy+/r2/CP4X7Fv/g6iRj+LKFIJA4w1Jcz0v J5Z18y1OYMybfXRQFyW5XfNQIWDTdwH1Df5DNxyAk/gz4p7AiEb0EXoBtZSTzH+CUHvm 6xtUo8lar7qrp7Zs1cFUxEuUrcl4zaX3ttSxMgIEA1Ncau4SP611slbHpSX26OcqfjZ1 mM+XC0ht3e3B2Ha/wTT8hMhfmOjJE0lyrvOH7i9rWDF1WwpIkl5d255VVOAXkR4yJbi2 ITDXvEU4IMiCq0EygFILF2xOWJPims7nPoTMkQjG1rKWe6EeZfu9b+lcMAxAplS7oVKA 5Csw== MIME-Version: 1.0 X-Received: by 10.180.11.200 with SMTP id s8mr4304050wib.10.1376436447488; Tue, 13 Aug 2013 16:27:27 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Tue, 13 Aug 2013 16:27:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Aug 2013 00:27:27 +0100 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:27:29 -0000 On 13 August 2013 23:58, Cullen Jennings (fluffy) wrote: > > On Jul 31, 2013, at 6:16 AM, Martin Thomson wrote: > >> I think that the only guidance needed is something like: >> "Implementations MAY choose to exclusively use m-lines with a=sendonly >> or a=recvonly in order to further reduce the probably of encountering >> glare." > > that can't be the default for non bundle lines or it won't work with existing stuff which was the whole point of this. It's not clear it helps reduce glare in general. You are somewhat correct. I'm sure that it will "work" for some value of "work", but that might not correspond with anything useful. I was operating under the assumption that partial offers/answers wouldn't reach old stuff. From fluffy@cisco.com Tue Aug 13 16:28:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DBF21E8198 for ; Tue, 13 Aug 2013 16:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSlwATx3ym6b for ; Tue, 13 Aug 2013 16:28:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BA1F721F99A1 for ; Tue, 13 Aug 2013 16:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=874; q=dns/txt; s=iport; t=1376436508; x=1377646108; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t7MyFlwwNbEeS3Ns9ZyKYEDEUBT7+BDMLlKDMZgb67U=; b=cr8l325qCyiS+XaiAIR/7F8fV+0jqusajSoPd32qUAZAENcTh8UkbA16 NGH7fW3rwCvHdm2KEj1qpNW2dTNPuH8xXJlOGN5Yk3HXkYrXscLbgrtk6 YxJS6q5ALR6Qj/uoUdIqIyTa2zdeBzw1Ce/IZOMAWcOpi3JA8tagYehzf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAFfAClKtJV2a/2dsb2JhbABbgwaBBYJRvBGBJRZ0giQBAQEDAXkQAgEIIiQyJQIEDgUIE4dvBrg/kAkCMQeDG3YDiHWgQIMbgio X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246786312" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 13 Aug 2013 23:28:26 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7DNSPQi015213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 23:28:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 18:28:25 -0500 From: "Cullen Jennings (fluffy)" To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOmHzOHo94Af59ikuaH/W55gKghQ== Date: Tue, 13 Aug 2013 23:28:25 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6B42FEF251CCCA459314AD824F3CDE80@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:28:35 -0000 On Aug 8, 2013, at 12:18 AM, Christer Holmberg wrote: > =20 > As has been indicated, bundle-only can only be used when one knows that t= he receiver, and possible intermediaries etc, support it. > =20 >=20 I don't think that is the case. It can be used in an offer regardless of if= you know the answer can support it or not.=20 Related to other messages on the thread. Yes, I understand that ICE will ha= ve a "clean up O/A" to fix all the ports to be the ones actually in use but= media flows before that "clean up". I have zero interest in exploding all = this again to discuss a solution that would require more round trips before= media could flow and be less likely to work with existing SIP stuff. I thi= nk the current design is better than one that would require multiple O/A to= get media to flow.=20 From fluffy@cisco.com Tue Aug 13 16:28:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFAA21F99A1 for ; Tue, 13 Aug 2013 16:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2rgwl9m90BF for ; Tue, 13 Aug 2013 16:28:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1B07421E81A7 for ; Tue, 13 Aug 2013 16:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=517; q=dns/txt; s=iport; t=1376436518; x=1377646118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yF21JVs1GHw/mtyxJCg6c4gNM6AdWKzNR+ex8VXsa1g=; b=LOMofukU36FLEfx9ogfE68yzBvoYrIpqlrmG47XMJbyPT3kbJ0fu/nBe iC5haM/pS+F2tFa/W4tCjzs0lFUpWan0rMFc86C8F/Wgoy/A+6u9C33O/ 3RJu6g/vQKqIu5zRUS/cFos81reMn6NC5QrfQ2nBlqPq8IAPdmT5+Cwts U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAM3AClKtJV2b/2dsb2JhbABbgwaBBYJRvBGBJRZ0giQBAQEDATo/BQsCAQgiFBAyJQIEDgUIiAIGuD+QCQIxB4MbdgOpNYMbgio X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246975920" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 13 Aug 2013 23:28:31 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7DNSV8l025948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 23:28:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 18:28:30 -0500 From: "Cullen Jennings (fluffy)" To: Parthasarathi R Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOmHzRKhPenv+lz0620AA+309SKg== Date: Tue, 13 Aug 2013 23:28:30 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <009d01ce951b$d52aa340$7f7fe9c0$@co.in> In-Reply-To: <009d01ce951b$d52aa340$7f7fe9c0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <116A20F0F9EAD14BBD53C9B6EF2028C1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic WG Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:28:44 -0000 On Aug 9, 2013, at 10:16 AM, Parthasarathi R w= rote: > This approach also > Violates Sec 8.2 of RFC 3264 requirement >=20 > " A stream that is offered with a port of zero MUST be marked with port > zero in the answer." No this would not be violated. When one side was 3264 only, this would stil= l happen. But when both sides support bundle-only, then this restriction no= longer holds. The bundle draft as an extension to 3264 needs to clearly de= fine all that.=20 From pkyzivat@alum.mit.edu Tue Aug 13 16:32:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42BC11E80D1 for ; Tue, 13 Aug 2013 16:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qETjAezKtTdl for ; Tue, 13 Aug 2013 16:32:37 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCE221F9AEB for ; Tue, 13 Aug 2013 16:32:36 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta12.westchester.pa.mail.comcast.net with comcast id CBDy1m0041GhbT85CPYayZ; Tue, 13 Aug 2013 23:32:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id CPYa1m00W3ZTu2S3TPYaPC; Tue, 13 Aug 2013 23:32:34 +0000 Message-ID: <520AC210.7030703@alum.mit.edu> Date: Wed, 14 Aug 2013 01:32:32 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> 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=q20121106; t=1376436754; bh=yO2YwFLMq79QlZYjCEXHae357fEMoLXeKMatxMppQNU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Qukhp/9nfrgf4eHv1A6J6JS2cwHsJFHgFK1WSxC4NBG8EZCVWe1hxqmUjHoXv/IRb iemEg9473Ls7YQFtWcVdihqS+vlic+CKxsdBggq+oJAQvBbxr5CCH0etCjk7FWzL3o 5cog1XSynPfv1bx+UHw6/Ui/4NtLTzX0SebSEeAduiAjiS+++H/cUqbma0cGriI3cS KAmgFdjfq1LuyfUlF9oeC+qCQ23IXu7729IWeJ97fDX7KntLv6U5phpljH+HOH6966 3TPTAk0s9hngmSil+9iUXVrfv41q5Gar4OCFGoy6EAZnu6v3zduOgZKPDDLdbdw0oA 0PrcPUNkHMTdQ== Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:32:41 -0000 A related thing that affects this: session level attributes that affect each media level. E.g., session level c-line. Do we assume that you must send a full offer to change such things? (Of course you might choose to avoid this.) Another thing: ISTM that every POF and PAN whould carry an o-line. That will indicate what it updates. And each one then needs to increment the sequence number. Thanks, Paul On 8/14/13 12:54 AM, Cullen Jennings (fluffy) wrote: > > You only want to send the m blocks that have changed because if you send other ones, you up the chances of both sides sending the same m block at the same time and being back into the glare problem. > > It seems to me the options are either 1 or 2 would make sense > > 1) the sender SHOULD only send m m blocks with a change (which might be all of them) and receiver MUST be prepared to receive any number. > > 2) you can only send one m block in a partial Off or Ans - but you can have several outstanding at a time > > > > On Aug 5, 2013, at 10:35 AM, Christer Holmberg wrote: > >> Hi, >> >> I see no issue with multiple m- lines - just wanted to verify that it would be allowed :) >> >> Regards, >> >> Christer >> >> >> >> Sent from Windows using TouchDown (www.nitrodesk.com) >> >> -----Original Message----- >> From: Hadriel Kaplan [hadriel.kaplan@oracle.com] >> To: Christer Holmberg [christer.holmberg@ericsson.com] >> CC: mmusic [mmusic@ietf.org] >> Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? >> >> On Aug 5, 2013, at 11:17 AM, Christer Holmberg wrote: >> >>> Note that my re-INVITE/UPDATE example is based on the assumption that one can use partial offers/answers with SIP, on the wire. Not sure if that was part of the agreed scope for the UP. >> >> Definitely NOT agreed on. Doesn't mean it won't happen in the future, but the scope of UP was limited to WebRTC for now. We can debate which parts of UP are generically applicable, and which not. For SIP, this isn't the right WG for that debate. >> >> >>> But, even without that, I think the question on including all m- lines on a partial offer still applies :) >> >> I don't see why WebRTC would restrict itself in any way regarding the number of m-lines in a partial offer/answer. Nothing "breaks" if all m-lines are in it, does it? The real question is if it can be greater than *one* m-line. If it can, and I think it can, then I can't see how the exact quantity of them matters. The only downside is you increase the chance of glare, I assume. >> >> Afaik, the 'mid' attribute is there to identity which m-lines in the partial offer correspond to which m-lines in the full ordered set. (the 'mid' could have even been an index number, except it's also used to avoid glare when adding m-lines, which a numeric index wouldn't have done) So what's the issue with one or multiple m-lines? >> >> -hadriel >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Tue Aug 13 16:39:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3397721E804C for ; Tue, 13 Aug 2013 16:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8wrkWsFDWad for ; Tue, 13 Aug 2013 16:39:42 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 436C511E80D2 for ; Tue, 13 Aug 2013 16:39:42 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta14.westchester.pa.mail.comcast.net with comcast id CNwf1m0061vXlb85EPfhZw; Tue, 13 Aug 2013 23:39:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id CPfh1m00Q3ZTu2S3dPfhqw; Tue, 13 Aug 2013 23:39:41 +0000 Message-ID: <520AC3BC.5030708@alum.mit.edu> Date: Wed, 14 Aug 2013 01:39:40 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <52011AF8.10003@alum.mit.edu> <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.com> In-Reply-To: <10264979-C7D2-4834-B5CC-ADD27B29774D@oracle.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=q20121106; t=1376437181; bh=6Nbr3bNRdJuDx1d/vvBqc8O5UZL9GlXmrssoH0d+nuY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ikcHmpa0tmNK37NKE/oKyGvMBKfQfPWdqYjZI2UcD9wWBcUTZqFe73i6M/PmiTu5p 6pRphY8B/AyhL2tkX7ubW5+R5EAZTh7mo/tbiyKf8x/Gj7r1KY+y4IolPh7cI7JQgR R9VckoHXWTLMw+bskO0MQW3MKKNKYE/MNdC7slfKVu8nlM+tSwKVdWNt4/47jxZRyw eYBcqvK61KAFjvgY88hiwMIetxl4LGelkoZ0zTS5UryGm5L3goyElgfQ57gmDXYet2 8Q4GSXqOkyR5s8I+tgIwjsrm/6+g6n8Nzrj/oBIWlbvftfGUm0AsI8wQaEFUg0d4rr 7AN5KBe2HXybQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:39:48 -0000 On 8/7/13 7:52 PM, Hadriel Kaplan wrote: > > On Aug 6, 2013, at 11:49 AM, Paul Kyzivat wrote: > >> I don't really understand the "only for WebRTC" agreement. >> I do see how defining extensions to O/A might be done only for WebRTC and not for 3264. (I don't *agree*, but I do *understand* that.) >> >> But BUNDLE is a change to SDP, and SDP extensions are required to specify how they interact with O/A. > > Is that actually true? I don't see that requirement in RFC 4566 IANA registration procedures, nor in IANA's SDP parameters registry. I don't know if it is written anywhere or not, but as a member of the SDP directorate *I* assume that SDP extensions need to discuss the O/A impact. Even before the SDP directorate we have been bugging authors about that. Sometimes that impact may be *none*. I suppose it is conceivable that there would be an SDP extension that isn't intended to be used in any O/A context. But if that is the case, then I would expect *that* to be specified. Thanks, Paul >> I don't think it makes any sense to say that such changes only apply to WebRTC. They should apply to anything that chooses to claim support to the BUNDLE draft. > > OK, but in a SIP-based usage, I think it's dangerous to offer port=0 media lines and negotiate to use those media lines with the far end due to an answer containing a new bundle attribute, without sending another offer indicating you're using those media lines. > > So I think if we want to use BUNDLE in SIP as well, we should really require it to do another offer/answer round. In a WebRTC usage (ie, in Javascript API and JSEP), it can avoid the second round. > > One way to describe this in a BUNDLE RFC, I think, is to say it MUST do another offer/answer exchange, except when used in [draft-jsep] or as an application programming interface. (or something like that) > > -hadriel > > From pkyzivat@alum.mit.edu Tue Aug 13 16:43:58 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8506C21F9B85 for ; Tue, 13 Aug 2013 16:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv54YMZ8X6zs for ; Tue, 13 Aug 2013 16:43:52 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 94DAD21E804C for ; Tue, 13 Aug 2013 16:43:52 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id CBJD1m0030SCNGk5APjsfH; Tue, 13 Aug 2013 23:43:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id CPjr1m01Q3ZTu2S3VPjsy7; Tue, 13 Aug 2013 23:43:52 +0000 Message-ID: <520AC4B6.8070108@alum.mit.edu> Date: Wed, 14 Aug 2013 01:43:50 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 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=q20121106; t=1376437432; bh=6w+Vo00CVTRuewFu5HLcgFIUtvf92xbhTTUeYmGlV5U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jdVZMnVcQZS3ErlP9WQ8aeYPVZJ1nbj+gjBvJe4nhvqGR7C7PC3e0woEjUMvd20Yi o73b5WCRumWILz/91LbRLkFwMlvU9FTVxYal4fs3aF/IVKJllvL+1hOAVZifYCCWaz GXOgvieGFm2NoZG8KyLSdhqnmzfM5YVIryG+r6EZg1KNKh5Iv7rmKsrhNs7PxM0R5N eZ3Y8+IstziospSt8JMHbPtGt998yf2APLS0h5VgCYhKXSorkTePAT84UkgMZsIAcg iNU49YTXVpzQ2XujEE+jJ9NL0b2zLRS3//Lrb678yj7D2zZ8YmNdIxK3pDpV7Tu2IU TP1+ApZH9+tgQ== Subject: [MMUSIC] Will partial offers/answers leak to legacy stuff? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:43:58 -0000 On 8/14/13 1:27 AM, Martin Thomson wrote: > I was operating under the assumption that partial offers/answers > wouldn't reach old stuff. Well, when we hear others assert such things in other contexts we give them a very hard time, and tell them that in spite of all their best intentions things will leak. E.g., private network addresses, asserted identity. Thanks, Paul From fluffy@cisco.com Tue Aug 13 16:46:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A804021E804C for ; Tue, 13 Aug 2013 16:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEM3ebzIaru1 for ; Tue, 13 Aug 2013 16:46:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5DB21F9BAD for ; Tue, 13 Aug 2013 16:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=497; q=dns/txt; s=iport; t=1376437605; x=1377647205; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=d1F0mk1Y7+CUrVrnq8ckqIX+UHVQIhcG8NLEfoXlJbw=; b=K8jG7EHb9vP5pDgXr0C/R9/D3QdwoZF9UAqNZLV80q65ZiCWJlYHXQiS do9bBbulLZw8so+782notVxj7nWdPFXc8ghkM1CMwW6wXjjp1ja+J0L3r xlX27V4XoAaUYHla0cz3A49nzYdQvksnyKrg7X1uza/CedRaTFlaElR/z w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANjEClKtJXHA/2dsb2JhbABbgwaBBYJRvBGBJRZ0giQBAQEDAXkFCwIBCCIkIRElAgQOBQiHdgMJBq9aDYhejUWCRAIxB4MbdgOIdYsYgW6OE4UngxuCKg X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246972137" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2013 23:46:44 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7DNki47003549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 23:46:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 18:46:43 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: AQHOmH9d3pu7nj+w8UGtFsQJ9+qy9w== Date: Tue, 13 Aug 2013 23:46:42 +0000 Message-ID: References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.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.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:46:50 -0000 On Jul 31, 2013, at 8:34 AM, Martin Thomson wrot= e: > This formula is just a recommendation (a SHOULD, to be fair) I think you need to read 2119 and understand the analysis was done when des= igning ICE and came to the conclusion there were order of checks needs to b= e coordinated between the two sides.=20 (I'm not saying that we can't find a way to improve on 5245, I'm just sayin= g pretending you can ignore it because it has a SHOULD won't work) From fluffy@cisco.com Tue Aug 13 16:46:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE04D21E81A0 for ; Tue, 13 Aug 2013 16:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFP59UM1h-6V for ; Tue, 13 Aug 2013 16:46:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 02AE721E804C for ; Tue, 13 Aug 2013 16:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1955; q=dns/txt; s=iport; t=1376437612; x=1377647212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=grS8QIMXk+tN19hrHYNmpH/yVknSwlpdky5PHOSQWng=; b=dyW/J34blMAITwl4G85A+tWJBo1RWcvmuYKyQJJATWulSFpM9GxTSc+y PsrTlj4/GRO1H6XJSihZCWec78R1UR2UrSyMzLo2Xch6gf1nwnZDpggli iSmdUhERBuoXdsHNoNiJN/TkurRMNc/6e21spvJq8HoRbxCconEhsYMsX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAAzFClKtJV2b/2dsb2JhbABbgwY1RAy+YoElFnSCJAEBAQMBAQEBawsFCwIBCBgKJCEGCyUCBA4FCId2AwkGDK9ODYhaBI1FgTWBDwIxB4MbdgOIdY0GjhOFJ4MbgWlB X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246981965" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 13 Aug 2013 23:46:40 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7DNkdgW012731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 23:46:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 18:46:39 -0500 From: "Cullen Jennings (fluffy)" To: "Pal Martinsen (palmarti)" Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: AQHOmH9a8+GjGzWOQ0aIFFgplLwgiA== Date: Tue, 13 Aug 2013 23:46:38 +0000 Message-ID: References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> <04179E80-2AF6-4150-B083-01289438BC0A@vidyo.com> <51F933A8.2060504@ericsson.com> <1373AC9C23D80E44856F5CF6F883ACAB1144E3A4@xmb-rcd-x06.cisco.com> In-Reply-To: <1373AC9C23D80E44856F5CF6F883ACAB1144E3A4@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2D4C6F18459ADF458E16C3DDB1CEE9C1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:46:56 -0000 On some NATs it was clear that from the source code that the rate limit was= caused by how fast the NAT could actually create new connections and it wa= s the same code path for all address families. So at least in some cases, t= he fact that the address family changed does not speed up the number of map= ping per second the NAT can create. Hard do know how general this is.=20 Jonathan's Teredo point is very insightful.=20 On Aug 1, 2013, at 2:19 AM, Pal Martinsen (palmarti) w= rote: > Hi, >=20 > I want to revisit a discussion from an earlier version of the draft.=20 >=20 > An earlier version of the draft suggested to do IPv4 and IPv6 checks in p= arallel. I like that idea because: >=20 > 1. It really speeds up the connectivity check phase > 2. Should have no impact on the NAT port allocation problem. (Or is there= a way for an IPv6 conn check to have a negative impact on the IPv4 NAT?) > 3. Easy to implement. I would just change the way I traverse the the orde= red checklist. Send first available IPv6 test, then search the list for the= first available IPv4 check. To avoid timing issues a ice-option might be u= sed to say that the checklist is done in parallel if it contains different = address types. (Do we want to support IPv7.. :-) ) >=20 > .-. > P=E5l-Erik >=20 > On Jul 31, 2013, at 18:16 PM, Martin Thomson > wrote: >=20 >> On 31 July 2013 17:56, Ari Ker=E4nen wrote: >>> overly complex >>=20 >> Yes. Given that this is a very small part of a spec that already fits >> that description, we need to be careful. >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Tue Aug 13 16:52:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C3121E8197 for ; Tue, 13 Aug 2013 16:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNeeqPt+eVf4 for ; Tue, 13 Aug 2013 16:52:38 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 5835821E8053 for ; Tue, 13 Aug 2013 16:52:38 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id CMlF1m00216LCl058Psdfr; Tue, 13 Aug 2013 23:52:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id CPsd1m00q3ZTu2S3SPsdB7; Tue, 13 Aug 2013 23:52:37 +0000 Message-ID: <520AC6C5.4010109@alum.mit.edu> Date: Wed, 14 Aug 2013 01:52:37 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> 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=q20121106; t=1376437957; bh=i4cj5YyVi3NyOadWuhqARVplEbGos2K65G9ekVAy0ZQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rl63fC0QPnKwIEukqYBKSWAJLifF9XIYmv9OLuykW293eCc3FlIdlowrcSOku9XNt VEhjH8dBGpUfSFxnPFd4fh8a22nUJuV22JowZLY4X8fcbRQeQDzTGIaJC7kURoDTV1 1+KBFSqsDBYFuATbyCO+EHmRpoeFycM7Aw6p4YVzKdQolM8Y9o5U6ql93Mpls9F6Pz Z7i0a18LISS5O8XJVpJw7xkKFy7KdAYRDcRRF5RKtNmXGeTxUgpp+E33I/6UfO2Wi0 NjLA6MqmnYA2uGg87KhHmtDyLgfIkC98p2c4tBwIykLgiDy6us0ZLB1h0PFwzEzMBV 9zfXkX2PrHncQ== Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 23:52:55 -0000 On 8/14/13 1:28 AM, Cullen Jennings (fluffy) wrote: > > On Aug 8, 2013, at 12:18 AM, Christer Holmberg wrote: > >> >> As has been indicated, bundle-only can only be used when one knows that the receiver, and possible intermediaries etc, support it. >> >> > > I don't think that is the case. It can be used in an offer regardless of if you know the answer can support it or not. Agreed. > Related to other messages on the thread. Yes, I understand that ICE will have a "clean up O/A" to fix all the ports to be the ones actually in use but media flows before that "clean up". It may in some cases, not in others. (When intermediaries gate flows based on the answer then the media may not flow immediately. Or maybe it will if the intermediary is sufficiently bundle-aware. > I have zero interest in exploding all this again to discuss a solution that would require more round trips before media could flow and be less likely to work with existing SIP stuff. I think the current design is better than one that would require multiple O/A to get media to flow. Exploring *what* again? Its not like bundle-only has had such deep discussion. What's clear is that bundle-only is a somewhat complex mechanism. It isn't required if you are willing to do a 2nd o/a for the m-lines that would otherwise be bundle-only. It would indeed require another round trip before media could flow for *those* m-lines. Presumably they are "lower priority", so is that really a big deal? Is the extra machinery of bundle-only justified for this case? Thanks, Paul From fluffy@cisco.com Tue Aug 13 17:05:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11EE21E8056 for ; Tue, 13 Aug 2013 17:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfb1U4nkZZQ3 for ; Tue, 13 Aug 2013 17:05:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EDE5911E80D1 for ; Tue, 13 Aug 2013 17:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5096; q=dns/txt; s=iport; t=1376438747; x=1377648347; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YaVrWniuzeD13PinZrR3euu4cUdJnNfi8op9HCfJkgc=; b=jPTG6e7mIAo6Pi8KogdyFKA3sNw3atp3cHJFW6UYXgbUt/4oH7//yyRd hARTychxt5f/EljkFh3p6cxGSkSfonrKRbd4L5fjEgDba7CekNiy8/NnH Vpb2YVPAAbIC0MCm3DbzwKSQ64dv2T5t99vjaktwiHGZ1DpvnyuCLLXAI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAAbJClKtJXG+/2dsb2JhbABbgwY1UL5igSUWdIIkAQEBAwEBAQFrEAcEAgEIEQMBAgsZCycLHQgCBBMIiAIGDLg2kAkCOAaDFXYDiHWQHJAkgWGBOoIq X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="247006014" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2013 00:05:41 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7E05e2W002431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 14 Aug 2013 00:05:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 19:05:40 -0500 From: "Cullen Jennings (fluffy)" To: mmusic Thread-Topic: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Pr... Thread-Index: AQHOmIICNSWQ8Vb7Cka66yZwRn+Uow== Date: Wed, 14 Aug 2013 00:05:39 +0000 Message-ID: References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <520568C9.9010603@cisco.com> In-Reply-To: <520568C9.9010603@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3A1441520296114E9D969B9A6B4B8C2F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Pr... X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 00:05:53 -0000 The DTMF approach is spectacularly irritating. The user often gets an earfu= l of DTMF and is really confused about why they got DTMF.=20 I don't care about the MUST implement all three but I think it is a bad ide= a to say that the offer SHOULD use DTMF. I'd like to see DTMF be a "MAY" us= e in the offer.=20 On uuie, it's might be worth noting that a valid reason not to use uuie in = the offer is that something else has already used theses bits.=20 On Aug 9, 2013, at 4:10 PM, Flemming Andreasen wrote: > Greetings MMUSIC >=20 > As you can see per the below, the IESG approved the Circuit-Switched Bear= ers draft for publication, however before doing so, they requested a couple= of changes. The resulting approved document can be found at http://tools.i= etf.org/html/draft-ietf-mmusic-sdp-cs-21 >=20 > One of the changes introduced resulted in all 3 correlation mechanisms no= w being mandatory-to-implement (previously they were not): > > Implementations MUST support the three correlation mechanisms > specified in=20 > Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4 > , > and SHOULD include all supported mechanisms the initial Offer. >=20 > > Since this is a non-trivial change that has not been discussed by the WG = (and we know of at least one person having expressed concerns with it off-l= ine), we are hereby solicting the WG participants for input on changes intr= oduced as a result of the IESG review with a focus on the above. In doing s= o, please keep in mind that we are developing standards that work in the ge= neral Internet.=20 >=20 >=20 > The following URL provides a diff-file showing the changes resulting from= the IESG review: > http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sdp-cs-18.txt&= url2=3Ddraft-ietf-mmusic-sdp-cs-21.txt >=20 > Comments are due by August 23 (two weeks from today) >=20 > Thanks=20 >=20 > -- Flemming (MMUSIC co-chair) >=20 >=20 >=20 > -------- Original Message -------- > Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Ex= tension For Setting Audio and Video Media Streams Over Circuit-Switched Bea= rers In The Public Switched Telephone Network (PSTN)' to Proposed Standard = (draft-ietf-mmusic-sdp-cs-21.txt) > Date: Mon, 1 Jul 2013 11:56:23 -0700 > From: The IESG > To: IETF-Announce > CC: mmusic chair , mmusic mailing list , RFC Editor >=20 > The IESG has approved the following document: > - 'Session Description Protocol (SDP) Extension For Setting Audio and > Video Media Streams Over Circuit-Switched Bearers In The Public > Switched Telephone Network (PSTN)' > (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard >=20 > This document is the product of the Multiparty Multimedia Session Control > Working Group. >=20 > The IESG contact persons are Gonzalo Camarillo and Richard Barnes. >=20 > A URL of this Internet Draft is: >=20 > http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >=20 >=20 >=20 >=20 >=20 > *Technical Summary > * >=20 > The document describes use cases, requirements, and protocol extensions > for using the Session Description Protocol (SDP) Offer/Answer model for > establishing audio and video media streams over circuit-switched bearers > in the Publich Switched Telephone Network (PSTN) >=20 > *Working Group Summary > * >=20 > The WG had some discussion around the format to use for E.164 numbers > and whether to align this with the existing definition in RFC 3108. The > RFC 3108 definition was seen as deficient and the WG agreed it was > better to align with relevant parts of the tel URI format defined in RFC > 3966, not least since SDP address types are defined in the context of a > particular network type, and hence RFC 3108 compatibility is not a > concern (the implication is that the "E164" address type may differ > between network types in SDP). >=20 > *Document Quality > * >=20 > There are currently no known implementations of the draft, however the > draft is a dependency for 3GPP, so future implementations are expected. >=20 > The document has received good overall review in the WG, some of which > resulted in changes to the detailed specification. The document has been > reviewed in detail several times, including of the last few versions. > The major contributors to these as well as earlier discussions are > listed in the Acknowledgements section of the document. >=20 >=20 > *Personnel > * >=20 > Document Shepherd: Flemming Andreasen > Responsible AD: Gonzalo Camarillo=20 > _______________________________________________ > mmusic mailing list >=20 > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 > . >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Tue Aug 13 17:15:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EAC21F9A57 for ; Tue, 13 Aug 2013 17:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2mOI6ozJANT for ; Tue, 13 Aug 2013 17:15:56 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id DB16221F9CA2 for ; Tue, 13 Aug 2013 17:15:55 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f14so1314214wiw.15 for ; Tue, 13 Aug 2013 17:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y7ZdD9CX7NzNa4eImpXEnxjAGCHAjZu6I8lTLqOYaTk=; b=QBNEUa4i8bk7Yzp325hlKKDkqOTEcxQ68lfvgOgblUa6yWGhal1gLXQZ435f8L0Pie CsMrRdhrG9CqZ9BSX4eqKA+1Czew5NczaurXstZq9RvEta5DQ3tj6avFwc78CjupMXyK NsawZxm+WbzcXUanBPbHycAcfWToZeelcLp0Z8ws8E2eUjEfBGBjJubu7uFzWmftXtNJ Z1/arlQ0RFKbCNc15HzuDy739vdmue41s0AAb0/JJvjadbDegXjGtOX531JiiUoRjWzc vFg0H4Dmn4G0cHShNXEQtVZTWh6oMvyH1rCwNjJtXEGH8alcirl4SpVYIQgR1CZWm9eR hM7w== MIME-Version: 1.0 X-Received: by 10.180.109.10 with SMTP id ho10mr349978wib.14.1376439355013; Tue, 13 Aug 2013 17:15:55 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Tue, 13 Aug 2013 17:15:54 -0700 (PDT) In-Reply-To: References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.cisco.com> Date: Wed, 14 Aug 2013 01:15:54 +0100 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 00:15:57 -0000 On 14 August 2013 00:46, Cullen Jennings (fluffy) wrote: >> This formula is just a recommendation (a SHOULD, to be fair) > > I think you need to read 2119 and understand the analysis was done when designing ICE and came to the conclusion there were order of checks needs to be coordinated between the two sides. I think that you misunderstand. That particular requirement is addressed by a MUST in Section 5.7.2 (http://tools.ietf.org/html/rfc5245#section-5.7.2), which provides the ordering guarantee. The text in 4.1.2.1 uses SHOULD, and I'm aware of implementations that choose not to follow this guidance for the exact same reasons that this draft (the eyeballs draft, that is) was created. From martin.thomson@gmail.com Tue Aug 13 17:23:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1C021F9DC9 for ; Tue, 13 Aug 2013 17:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFqRk60wSvLh for ; Tue, 13 Aug 2013 17:23:51 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2681B21F9DBE for ; Tue, 13 Aug 2013 17:23:49 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q54so7195899wes.19 for ; Tue, 13 Aug 2013 17:23:43 -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=k788WJd43kVXlB8ela5eevDhfLkaho2h0B/4I8Gk3wg=; b=X0yMnofdxUAmSddZob8wVOVS3K/oHcL2AJd5lfpQNoYAmt4YckJ7xKPBLjdpj31n18 wus9N62PSBcwx9yafBo3LNysVKoJJLYF5YmsL0RdV/jLVtYsSmSoyU+L+mSE6RjvNuAC Mw9KFNAP8wkUeQNQptxrcwKkYT6ozM8HmbWaq6bKfSJOHWCqNB8ZGHNQGTNvjMeEJW4f 1mG85suLApavYixVdYM7VPGiHxHetmekSaHdqT3fx+AnlkG/beiZYjXNg1ywZGCE/uRW ID7U9SUzQRuDe5TpcCf4rcG3Obr38/4B6YWsxoQ3Yf4OBMPomUfuEAzRtoNrE6YFRKZ7 A21w== MIME-Version: 1.0 X-Received: by 10.180.183.19 with SMTP id ei19mr93743wic.10.1376439823328; Tue, 13 Aug 2013 17:23:43 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Tue, 13 Aug 2013 17:23:43 -0700 (PDT) In-Reply-To: <520AC4B6.8070108@alum.mit.edu> References: <520AC4B6.8070108@alum.mit.edu> Date: Wed, 14 Aug 2013 01:23:43 +0100 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Will partial offers/answers leak to legacy stuff? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 00:23:57 -0000 On 14 August 2013 00:43, Paul Kyzivat wrote: > On 8/14/13 1:27 AM, Martin Thomson wrote: > >> I was operating under the assumption that partial offers/answers >> wouldn't reach old stuff. > > > Well, when we hear others assert such things in other contexts we give them > a very hard time, and tell them that in spite of all their best intentions > things will leak. This is an interesting point, but I'm not sure if it's relevant without knowing more about how people intend to standardize the use of these things. If you send them in SIP INVITE messages, then I'm willing to entertain the discussion about leakage - we have to worry at that point. Until that happens, I will regard these partial thingies as square pegs and SIP as a round hole. And, while I expect that someone will come along with a hammer shortly, allow me at least that brief time to avoid worrying about these sorts of crazy things. --Martin From fluffy@cisco.com Tue Aug 13 17:32:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC34111E80E1 for ; Tue, 13 Aug 2013 17:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9GzJEvMZrnE for ; Tue, 13 Aug 2013 17:32:29 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2632111E80D2 for ; Tue, 13 Aug 2013 17:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1052; q=dns/txt; s=iport; t=1376440349; x=1377649949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z+Zt+Pfw90AdLtvAlG9u/2rCzVnDBI6CP+cIfBQKFcw=; b=cbpIbL9LST4SnJCsdTfl7Zm+xe3LAd4b3WuEbfZLEQ/SapWgLmuVP2Bo p5WoVEfjL02E2xxFmq8QyGepy/D9kGhZ1e+zSC3tzUmSp9F2Gn2qDp6BO lIW+D3G+e71r31MAwHecCANtcy6769A5txh+ggJr51SvGYvzhuLDvtJiJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKvOClKtJV2a/2dsb2JhbABbgwY1UL5igSUWdIIkAQEBAwEBAQFrCwULAgEIGAokIQYLJQIEDgUIh3YDCQYMr0oNiF6NRYJEAjEHgxt2A4h1ixiBboMWin2FJ4Mbgio X-IronPort-AV: E=Sophos;i="4.89,873,1367971200"; d="scan'208";a="246970830" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 14 Aug 2013 00:32:27 +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 r7E0WR0J025841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 00:32:27 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 19:32:26 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis Thread-Index: AQHOmIN4OwCKfqlDjkeUVVfQGC6lkJmULkoA Date: Wed, 14 Aug 2013 00:32:26 +0000 Message-ID: References: <51F8D6B6.6080109@ericsson.com> <913383AAA69FF945B8F946018B75898A19008F0E@xmb-rcd-x10.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.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4E89AAF1AA5A3C40914372678BBD617A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "mmusic@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 00:32:34 -0000 Sorry, thought you were talking about the other thing.=20 On Aug 13, 2013, at 6:15 PM, Martin Thomson wrot= e: > On 14 August 2013 00:46, Cullen Jennings (fluffy) wrot= e: >>> This formula is just a recommendation (a SHOULD, to be fair) >>=20 >> I think you need to read 2119 and understand the analysis was done when = designing ICE and came to the conclusion there were order of checks needs t= o be coordinated between the two sides. >=20 > I think that you misunderstand. That particular requirement is > addressed by a MUST in Section 5.7.2 > (http://tools.ietf.org/html/rfc5245#section-5.7.2), which provides the > ordering guarantee. The text in 4.1.2.1 uses SHOULD, and I'm aware of > implementations that choose not to follow this guidance for the exact > same reasons that this draft (the eyeballs draft, that is) was > created. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Tue Aug 13 19:24:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919F821F9425 for ; Tue, 13 Aug 2013 19:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZGdCxHo5uIa for ; Tue, 13 Aug 2013 19:24:16 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id C57A721F9097 for ; Tue, 13 Aug 2013 19:24:15 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id CSKN1m0040ldTLk54SQFPs; Wed, 14 Aug 2013 02:24:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id CSQE1m00b3ZTu2S01SQExR; Wed, 14 Aug 2013 02:24:15 +0000 Message-ID: <520AEA4D.2050706@alum.mit.edu> Date: Wed, 14 Aug 2013 04:24:13 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <520568C9.9010603@cisco.com> 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=q20121106; t=1376447055; bh=fPcP4cKuL0EOqrrs982kA0w08ZkQMY/7d58qTgNIEIc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GA4EN2NRnKGVviuSawxtFEUTIQSqHAVgF9Lb90ci84GscRClFUDi7u7ZRYQH9zcnZ GRFtA2ghLbFeGSft50lxOZDs5dLkx4LKzZ/UJ2UwOG7bNFIM6WDc7FBAOXyDY1+Pru emwqhJ51UK46rnGftt3Uj0jgJH75Tb77QbNjClmf9vWq01JLDIQYRTy3HuyA58sYVK 408dUNQWHN4ZD9DgyIL/DMqpFCMxrIJD/0rAypxg2uGVZj7hd34ly0nvUtFvbkO0Kl ymeGq8BLOhtVcTti+EIFXPZgCntfrknlfi1Npsy1hq4P08UNp0STW/68sUqxt4m5Ke dw08Sz1yTl4WQ== Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Pr... X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 02:24:20 -0000 I have no idea how these choices ended up in the draft. IIRC they are the same choices used in VIPR. At least there I thought the point was that none of them are guaranteed to work, so having multiple choices increases the chances of success. But I think that means offering them all and then trying them successively until one works, or until one fails in a way that convinces you not to try any more. Thanks, Paul On 8/14/13 2:05 AM, Cullen Jennings (fluffy) wrote: > > > The DTMF approach is spectacularly irritating. The user often gets an earful of DTMF and is really confused about why they got DTMF. > > I don't care about the MUST implement all three but I think it is a bad idea to say that the offer SHOULD use DTMF. I'd like to see DTMF be a "MAY" use in the offer. > > > On uuie, it's might be worth noting that a valid reason not to use uuie in the offer is that something else has already used theses bits. > > > > > On Aug 9, 2013, at 4:10 PM, Flemming Andreasen wrote: > >> Greetings MMUSIC >> >> As you can see per the below, the IESG approved the Circuit-Switched Bearers draft for publication, however before doing so, they requested a couple of changes. The resulting approved document can be found at http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21 >> >> One of the changes introduced resulted in all 3 correlation mechanisms now being mandatory-to-implement (previously they were not): >> >> Implementations MUST support the three correlation mechanisms >> specified in >> Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4 >> , >> and SHOULD include all supported mechanisms the initial Offer. >> >> >> Since this is a non-trivial change that has not been discussed by the WG (and we know of at least one person having expressed concerns with it off-line), we are hereby solicting the WG participants for input on changes introduced as a result of the IESG review with a focus on the above. In doing so, please keep in mind that we are developing standards that work in the general Internet. >> >> >> The following URL provides a diff-file showing the changes resulting from the IESG review: >> http://tools.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sdp-cs-18.txt&url2=draft-ietf-mmusic-sdp-cs-21.txt >> >> Comments are due by August 23 (two weeks from today) >> >> Thanks >> >> -- Flemming (MMUSIC co-chair) >> >> >> >> -------- Original Message -------- >> Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt) >> Date: Mon, 1 Jul 2013 11:56:23 -0700 >> From: The IESG >> To: IETF-Announce >> CC: mmusic chair , mmusic mailing list , RFC Editor >> >> The IESG has approved the following document: >> - 'Session Description Protocol (SDP) Extension For Setting Audio and >> Video Media Streams Over Circuit-Switched Bearers In The Public >> Switched Telephone Network (PSTN)' >> (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard >> >> This document is the product of the Multiparty Multimedia Session Control >> Working Group. >> >> The IESG contact persons are Gonzalo Camarillo and Richard Barnes. >> >> A URL of this Internet Draft is: >> >> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >> >> >> >> >> >> *Technical Summary >> * >> >> The document describes use cases, requirements, and protocol extensions >> for using the Session Description Protocol (SDP) Offer/Answer model for >> establishing audio and video media streams over circuit-switched bearers >> in the Publich Switched Telephone Network (PSTN) >> >> *Working Group Summary >> * >> >> The WG had some discussion around the format to use for E.164 numbers >> and whether to align this with the existing definition in RFC 3108. The >> RFC 3108 definition was seen as deficient and the WG agreed it was >> better to align with relevant parts of the tel URI format defined in RFC >> 3966, not least since SDP address types are defined in the context of a >> particular network type, and hence RFC 3108 compatibility is not a >> concern (the implication is that the "E164" address type may differ >> between network types in SDP). >> >> *Document Quality >> * >> >> There are currently no known implementations of the draft, however the >> draft is a dependency for 3GPP, so future implementations are expected. >> >> The document has received good overall review in the WG, some of which >> resulted in changes to the detailed specification. The document has been >> reviewed in detail several times, including of the last few versions. >> The major contributors to these as well as earlier discussions are >> listed in the Acknowledgements section of the document. >> >> >> *Personnel >> * >> >> Document Shepherd: Flemming Andreasen >> Responsible AD: Gonzalo Camarillo >> _______________________________________________ >> 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 fippo@goodadvice.pages.de Tue Aug 13 23:54:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E4521F9AC4 for ; Tue, 13 Aug 2013 23:54:47 -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=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waPS3kwKJl9w for ; Tue, 13 Aug 2013 23:54:43 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 7A64821F9ACA for ; Tue, 13 Aug 2013 23:54:32 -0700 (PDT) Received: from [192.168.168.243] (p4FE59DFB.dip0.t-ipconnect.de [79.229.157.251]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r7E6sNv7020589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Aug 2013 08:54:30 +0200 Message-ID: <520B299F.9060409@goodadvice.pages.de> Date: Wed, 14 Aug 2013 08:54:23 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RFC 5245: ice-ufrags of length 256 vs stun maximum username length of 512 bytes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 06:54:47 -0000 It seems that there is a minor inconsistency between the maximum username length in STUN and the way ice-ufrag is defined... 5245 allows ufrags of up to 256 characters: -- http://tools.ietf.org/html/rfc5245#section-15.4 The STUN username is formed as RFRAG:LFRAG http://tools.ietf.org/html/rfc5245#section-7.1.2.3 If both sides use 256 characters for their ufrags this would result in a 513 byte STUN username. However, 5389 says the username has to be "less than 513 bytes". -- http://tools.ietf.org/html/rfc5389#section-15.3 Off by one? For ice-pwd this isn't a problem, right? From hadriel.kaplan@oracle.com Wed Aug 14 07:31:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880FB11E816F for ; Wed, 14 Aug 2013 07:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.658 X-Spam-Level: X-Spam-Status: No, score=-5.658 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk93Zc+sNvrh for ; Wed, 14 Aug 2013 07:31:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 78FA011E8166 for ; Wed, 14 Aug 2013 07:31:44 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7EEVbOJ012507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Aug 2013 14:31:38 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EEVZWp012482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 14:31:37 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EEVYgM015781; Wed, 14 Aug 2013 14:31:34 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Aug 2013 07:31:34 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5208DA37.7040305@ericsson.com> Date: Wed, 14 Aug 2013 10:31:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <520568C9.9010603@cisco.com> <5208DA37.7040305@ericsson.com> To: "" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: mmusic Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:31:50 -0000 I propose we remove the UUI and DTMF correlation options, and just leave = it as the callerid one only for now. We can leave the ABNF with the current 'ext-mech' so that a future spec = could define something else if need be, and the IANA registration = procedures for doing so are already documented in this = draft-ietf-mmusic-sdp-cs-21. -hadriel On Aug 12, 2013, at 8:51 AM, Miguel A. Garcia = wrote: > Hi Hadriel: >=20 > As far as I remember, the history of the three mechanisms is kind of = fuzzy. At some point in time in the past, 3GPP hadn't decided on the = architecture to enable CS calls over SIP/SDP, and they were looking into = it. The mechanisms were envisioned by the authors and comments on the = mailing list, and put at 3GPP's disposal for a choice. >=20 > I concur with your concern that just because we mandate to implement = the 3 of them, these are not going to be implemented. I don't have any = problem in removing from the draft those mechanisms that we envision = they won't be used. >=20 > /Miguel >=20 > On 10/08/2013 1:28, Hadriel Kaplan wrote: >> Wow. I can kinda understand why they'd say that (interop reasons, = presumably), but that's a big deal. The 3 mechanisms are very = different, with very different architectural and deployment = implications. I have a very hard time believing any of us would truly = implement all three. In fact, I don't truly believe anyone would. >>=20 >> So... I hate to do this, but can the authors summarize the history of = how we got 3 mechanisms to begin with, and who would really implement = them all? >>=20 >> Or to put it another way, instead of specifying all 3, would it be = impossible to take a step back and reconsider the real motivating = use-case (which as far as I know is 3GPP), and only specify the one they = need/use? >>=20 >> -hadriel >>=20 >>=20 >> On Aug 9, 2013, at 6:10 PM, Flemming Andreasen=20 >> >> wrote: >>=20 >>=20 >>> Greetings MMUSIC >>>=20 >>> As you can see per the below, the IESG approved the Circuit-Switched = Bearers draft for publication, however before doing so, they requested a = couple of changes. The resulting approved document can be found at=20 >>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21 >>>=20 >>>=20 >>> One of the changes introduced resulted in all 3 correlation = mechanisms now being mandatory-to-implement (previously they were not): >>> >>> Implementations MUST support the three correlation mechanisms >>> specified in=20 >>> Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4 >>> , >>> and SHOULD include all supported mechanisms the initial Offer. >>>=20 >>> >>> Since this is a non-trivial change that has not been discussed by = the WG (and we know of at least one person having expressed concerns = with it off-line), we are hereby solicting the WG participants for input = on changes introduced as a result of the IESG review with a focus on the = above. In doing so, please keep in mind that we are developing standards = that work in the general Internet.=20 >>>=20 >>>=20 >>> The following URL provides a diff-file showing the changes resulting = from the IESG review: >>> =20 >>> = http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sdp-cs-18.txt&url2=3D= draft-ietf-mmusic-sdp-cs-21.txt >>>=20 >>>=20 >>> Comments are due by August 23 (two weeks from today) >>>=20 >>> Thanks=20 >>>=20 >>> -- Flemming (MMUSIC co-chair) >>>=20 >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: [MMUSIC] Protocol Action: 'Session Description Protocol = (SDP) Extension For Setting Audio and Video Media Streams Over = Circuit-Switched Bearers In The Public Switched Telephone Network = (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt) >>> Date: Mon, 1 Jul 2013 11:56:23 -0700 >>> From: The IESG=20 >>> >>>=20 >>> To: IETF-Announce=20 >>> >>>=20 >>> CC: mmusic chair=20 >>> , mmusic mailing list = , RFC Editor >>>=20 >>>=20 >>> The IESG has approved the following document: >>> - 'Session Description Protocol (SDP) Extension For Setting Audio = and >>> Video Media Streams Over Circuit-Switched Bearers In The Public >>> Switched Telephone Network (PSTN)' >>> (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard >>>=20 >>> This document is the product of the Multiparty Multimedia Session = Control >>> Working Group. >>>=20 >>> The IESG contact persons are Gonzalo Camarillo and Richard Barnes. >>>=20 >>> A URL of this Internet Draft is: >>>=20 >>>=20 >>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> *Technical Summary >>> * >>>=20 >>> The document describes use cases, requirements, and protocol = extensions >>> for using the Session Description Protocol (SDP) Offer/Answer model = for >>> establishing audio and video media streams over circuit-switched = bearers >>> in the Publich Switched Telephone Network (PSTN) >>>=20 >>> *Working Group Summary >>> * >>>=20 >>> The WG had some discussion around the format to use for E.164 = numbers >>> and whether to align this with the existing definition in RFC 3108. = The >>> RFC 3108 definition was seen as deficient and the WG agreed it was >>> better to align with relevant parts of the tel URI format defined in = RFC >>> 3966, not least since SDP address types are defined in the context = of a >>> particular network type, and hence RFC 3108 compatibility is not a >>> concern (the implication is that the "E164" address type may differ >>> between network types in SDP). >>>=20 >>> *Document Quality >>> * >>>=20 >>> There are currently no known implementations of the draft, however = the >>> draft is a dependency for 3GPP, so future implementations are = expected. >>>=20 >>> The document has received good overall review in the WG, some of = which >>> resulted in changes to the detailed specification. The document has = been >>> reviewed in detail several times, including of the last few = versions. >>> The major contributors to these as well as earlier discussions are >>> listed in the Acknowledgements section of the document. >>>=20 >>>=20 >>> *Personnel >>> * >>>=20 >>> Document Shepherd: Flemming Andreasen >>> Responsible AD: Gonzalo Camarillo=20 >>> _______________________________________________ >>> mmusic mailing list >>>=20 >>>=20 >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>>=20 >>> . >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >>=20 >>=20 >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain >=20 From pkyzivat@alum.mit.edu Wed Aug 14 07:39:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C74621F99E1 for ; Wed, 14 Aug 2013 07:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33VUFlC+VqId for ; Wed, 14 Aug 2013 07:39:20 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 17C0D21F9655 for ; Wed, 14 Aug 2013 07:39:18 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta07.westchester.pa.mail.comcast.net with comcast id CeXJ1m0090cZkys57efH9c; Wed, 14 Aug 2013 14:39:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id CefH1m00u3ZTu2S3WefHaj; Wed, 14 Aug 2013 14:39:17 +0000 Message-ID: <520B9694.50503@alum.mit.edu> Date: Wed, 14 Aug 2013 16:39:16 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <520568C9.9010603@cisco.com> <5208DA37.7040305@ericsson.com> 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=q20121106; t=1376491157; bh=z7RJHxfnmB7dVDqK3pOG1X3IskG9BrftgopD7JrZ200=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pSlr2IC6Lw9G6VWQyR+1hws7gPMYZBt7OlxufCNZkVOIZdFwOIQgZALggrDSkGX5G mCPYgRW/kHtd8yR171cmM9OWnXJ7GSBHfEajM6aEN8ETIKEUR96Gj47cxwJtGgMCz+ Zh/TvfAk8QYYhiPdV61KJrvsfxSTE8FRfJK8xPRG5kYNEmZcmYn3JvC3JUyMCVDW0d WveUwkMH8e8enTeyx/z4ev9vH2DV+5pmbGXnj8ITCTwL3mzb+5HvkicIVwk27i05gy mAJOtBc2nRkV65sauW++7XZsETW4eSogKWXow6v8l2eMxK4UDD/yUTUpbVk8R2jsPm Ck6rrXPKI2T5Q== Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:39:24 -0000 On 8/14/13 4:31 PM, Hadriel Kaplan wrote: > > I propose we remove the UUI and DTMF correlation options, and just leave it as the callerid one only for now. > > We can leave the ABNF with the current 'ext-mech' so that a future spec could define something else if need be, and the IANA registration procedures for doing so are already documented in this draft-ietf-mmusic-sdp-cs-21. I don't think it makes sense to make such a change without some discussion whether the result will meet the needs that people have for the intended uses of this mechanism. Thanks, Paul > -hadriel > > > On Aug 12, 2013, at 8:51 AM, Miguel A. Garcia wrote: > >> Hi Hadriel: >> >> As far as I remember, the history of the three mechanisms is kind of fuzzy. At some point in time in the past, 3GPP hadn't decided on the architecture to enable CS calls over SIP/SDP, and they were looking into it. The mechanisms were envisioned by the authors and comments on the mailing list, and put at 3GPP's disposal for a choice. >> >> I concur with your concern that just because we mandate to implement the 3 of them, these are not going to be implemented. I don't have any problem in removing from the draft those mechanisms that we envision they won't be used. >> >> /Miguel >> >> On 10/08/2013 1:28, Hadriel Kaplan wrote: >>> Wow. I can kinda understand why they'd say that (interop reasons, presumably), but that's a big deal. The 3 mechanisms are very different, with very different architectural and deployment implications. I have a very hard time believing any of us would truly implement all three. In fact, I don't truly believe anyone would. >>> >>> So... I hate to do this, but can the authors summarize the history of how we got 3 mechanisms to begin with, and who would really implement them all? >>> >>> Or to put it another way, instead of specifying all 3, would it be impossible to take a step back and reconsider the real motivating use-case (which as far as I know is 3GPP), and only specify the one they need/use? >>> >>> -hadriel >>> >>> >>> On Aug 9, 2013, at 6:10 PM, Flemming Andreasen >>> >>> wrote: >>> >>> >>>> Greetings MMUSIC >>>> >>>> As you can see per the below, the IESG approved the Circuit-Switched Bearers draft for publication, however before doing so, they requested a couple of changes. The resulting approved document can be found at >>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21 >>>> >>>> >>>> One of the changes introduced resulted in all 3 correlation mechanisms now being mandatory-to-implement (previously they were not): >>>> >>>> Implementations MUST support the three correlation mechanisms >>>> specified in >>>> Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4 >>>> , >>>> and SHOULD include all supported mechanisms the initial Offer. >>>> >>>> >>>> Since this is a non-trivial change that has not been discussed by the WG (and we know of at least one person having expressed concerns with it off-line), we are hereby solicting the WG participants for input on changes introduced as a result of the IESG review with a focus on the above. In doing so, please keep in mind that we are developing standards that work in the general Internet. >>>> >>>> >>>> The following URL provides a diff-file showing the changes resulting from the IESG review: >>>> >>>> http://tools.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sdp-cs-18.txt&url2=draft-ietf-mmusic-sdp-cs-21.txt >>>> >>>> >>>> Comments are due by August 23 (two weeks from today) >>>> >>>> Thanks >>>> >>>> -- Flemming (MMUSIC co-chair) >>>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt) >>>> Date: Mon, 1 Jul 2013 11:56:23 -0700 >>>> From: The IESG >>>> >>>> >>>> To: IETF-Announce >>>> >>>> >>>> CC: mmusic chair >>>> , mmusic mailing list , RFC Editor >>>> >>>> >>>> The IESG has approved the following document: >>>> - 'Session Description Protocol (SDP) Extension For Setting Audio and >>>> Video Media Streams Over Circuit-Switched Bearers In The Public >>>> Switched Telephone Network (PSTN)' >>>> (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard >>>> >>>> This document is the product of the Multiparty Multimedia Session Control >>>> Working Group. >>>> >>>> The IESG contact persons are Gonzalo Camarillo and Richard Barnes. >>>> >>>> A URL of this Internet Draft is: >>>> >>>> >>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> *Technical Summary >>>> * >>>> >>>> The document describes use cases, requirements, and protocol extensions >>>> for using the Session Description Protocol (SDP) Offer/Answer model for >>>> establishing audio and video media streams over circuit-switched bearers >>>> in the Publich Switched Telephone Network (PSTN) >>>> >>>> *Working Group Summary >>>> * >>>> >>>> The WG had some discussion around the format to use for E.164 numbers >>>> and whether to align this with the existing definition in RFC 3108. The >>>> RFC 3108 definition was seen as deficient and the WG agreed it was >>>> better to align with relevant parts of the tel URI format defined in RFC >>>> 3966, not least since SDP address types are defined in the context of a >>>> particular network type, and hence RFC 3108 compatibility is not a >>>> concern (the implication is that the "E164" address type may differ >>>> between network types in SDP). >>>> >>>> *Document Quality >>>> * >>>> >>>> There are currently no known implementations of the draft, however the >>>> draft is a dependency for 3GPP, so future implementations are expected. >>>> >>>> The document has received good overall review in the WG, some of which >>>> resulted in changes to the detailed specification. The document has been >>>> reviewed in detail several times, including of the last few versions. >>>> The major contributors to these as well as earlier discussions are >>>> listed in the Acknowledgements section of the document. >>>> >>>> >>>> *Personnel >>>> * >>>> >>>> Document Shepherd: Flemming Andreasen >>>> Responsible AD: Gonzalo Camarillo >>>> _______________________________________________ >>>> mmusic mailing list >>>> >>>> >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>>> >>>> . >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From martin.thomson@gmail.com Wed Aug 14 09:10:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740DC21E80D5 for ; Wed, 14 Aug 2013 09:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnqgXCojGd7E for ; Wed, 14 Aug 2013 09:10:51 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 13A3021E80CC for ; Wed, 14 Aug 2013 09:10:50 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hq12so2162886wib.4 for ; Wed, 14 Aug 2013 09:10:48 -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=foKRBCxeWwKqZFdqaQLW5ALY2yq5JC6irnaBgkyAM4o=; b=WY/rdXEhtGUI51MWWz27GOz3l17A7QWb/U7pnqnVwjOCpM3nZKF3GighYU5FvbQLrb a08n0gFSpP8WEeTJyc4fErjym23jwVoZ1ZJn/SS7fH6MxbrWmeXgR3b+rTn/Zi2yOEfd +fMwJaMUW5r7vj8uxccPdknwidP08KwhVu95ZdIGXA39Qoi3/dD7iyG1S798wDSq8qYD z/PYuX0yuDh7Uuo2qkPGP7eEg1Fpf2uZ0NSfIcUBtnIVgKtXTLrYAUtAMQLWipfU1Pd0 Zjmit3mqSAEE9Y6vR31ngCQfOVU2g54HBissPt7sM351daZsx5voSBG7aFcUXGuNx1XN rkEw== MIME-Version: 1.0 X-Received: by 10.180.212.51 with SMTP id nh19mr5865211wic.14.1376496648102; Wed, 14 Aug 2013 09:10:48 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Wed, 14 Aug 2013 09:10:48 -0700 (PDT) In-Reply-To: <520B299F.9060409@goodadvice.pages.de> References: <520B299F.9060409@goodadvice.pages.de> Date: Wed, 14 Aug 2013 17:10:48 +0100 Message-ID: From: Martin Thomson To: Philipp Hancke Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245: ice-ufrags of length 256 vs stun maximum username length of 512 bytes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:10:52 -0000 On 14 August 2013 07:54, Philipp Hancke wrote: > > Off by one? Maybe. It certainly looks like an off-by-one error in the specs, though you could technically argue that both sets of length restrictions apply, since they are independent. After all, not all users of the STUN username attribute are also doing ICE. > For ice-pwd this isn't a problem, right? This doesn't transit the network in STUN packets. In SDP, the maximum size is 256 characters, but that's not a limit that other signaling protocols need to respect. From pkyzivat@alum.mit.edu Wed Aug 14 10:28:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BC711E8156 for ; Wed, 14 Aug 2013 10:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UXkgbKCRWIK for ; Wed, 14 Aug 2013 10:28:14 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 7928521F9A78 for ; Wed, 14 Aug 2013 10:28:14 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id CcpB1m0020SCNGk51hUDAL; Wed, 14 Aug 2013 17:28:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id ChUD1m01A3ZTu2S3VhUD6D; Wed, 14 Aug 2013 17:28:13 +0000 Message-ID: <520BBE2D.5000604@alum.mit.edu> Date: Wed, 14 Aug 2013 19:28:13 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> <520A2564.7090404@alvestrand.no> In-Reply-To: <520A2564.7090404@alvestrand.no> 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=q20121106; t=1376501293; bh=K2u4kfEYUAg4nj90yL+u57VMxsCbltJGd0MEH1KU4Ig=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GXu+HUi0jg6rTZg2BFDnl0IFMaaRKKDJVeQ9SUmLMdp/ekb3x8ec8gogPMf/nxjL1 8p9bl5nwU++fdObIN6mfv9w9DuhzedU84/7cTTOCLqV86oob2e/E7TBuVSbXXwzMrC xJC01VI0m9hnwtHp1iiQOcvZkZtqQVtCiRfBrOMKvdwjeON2ZR6t59BIkD1JemBbeI fAgLhdnODLrZsWkvEVAAxueuBEpZqKXM6g1QwCQCPdOt4bnWM3a9qinWHbtZGjwzdC Obt1i+DlskHbi/Z/Jwakfc+0Vi1ax4zy9vXbia1pVSNjtHT7/CNxuFiGfA59G2MbI3 Ovq5GSGHZm80A== Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:28:19 -0000 I have a fundamental question about this draft: With Unified Plan we have a unique m-line for every MediaStreamTrack. Given that, why do we need the msid attribute? Isn't it sufficient to define a new semantic ("mediastream"?) for the grouping framework? (RFC3388). There would still be need for a way to convey the application data, but that can be done via another attribute ("mediastream-data"?) associated with the m-line. Thanks, Paul On 8/13/13 2:24 PM, Harald Alvestrand wrote: > The auto-poster doesn't seem to want to tell mmusic about this.... > > this is updated according to Unified-plan. Since it was only 1 day > before the old version had expired, the proofreading might be a little > light - please point out places where I had missed changing "SSRC" to > "m-line"! > > I retained some description of the old mechanism (using a=ssrc) in an > appendix. Please state opinions on whether this should be retained as > informative, promoted to normative, or removed entirely in the next version. > > Hope this informs! > > Harald > > > -------- Original Message -------- > Subject: New Version Notification for draft-ietf-mmusic-msid-01.txt > Date: Tue, 13 Aug 2013 05:13:42 -0700 > From: internet-drafts@ietf.org > To: Harald T. Alvestrand , Harald Alvestrand > > > > > A new version of I-D, draft-ietf-mmusic-msid-01.txt > has been successfully submitted by Harald Alvestrand and posted to the > IETF repository. > > Filename: draft-ietf-mmusic-msid > Revision: 01 > Title: Cross Session Stream Identification in the Session Description Protocol > Creation date: 2013-08-13 > Group: mmusic > Number of pages: 14 > URL:http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt > Status:http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid > Htmlized:http://tools.ietf.org/html/draft-ietf-mmusic-msid-01 > Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01 > > Abstract: > This document specifies a 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 > ismmusic@ietf.org. > > > > > > 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 ari.keranen@ericsson.com Thu Aug 15 05:11:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5786011E8197 for ; Thu, 15 Aug 2013 05:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X8Chqc6S0Mk for ; Thu, 15 Aug 2013 05:11:06 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 21B4421F9DF7 for ; Thu, 15 Aug 2013 05:11:05 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-20-520cc558b751 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3D.FC.03802.855CC025; Thu, 15 Aug 2013 14:11:05 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.19) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.328.9; Thu, 15 Aug 2013 14:11: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 8C183110233; Thu, 15 Aug 2013 15:11:04 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 42B5855AD0; Thu, 15 Aug 2013 15:10:59 +0300 (EEST) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EC39A555E2; Thu, 15 Aug 2013 15:10:58 +0300 (EEST) Message-ID: <520CC557.7010402@ericsson.com> Date: Thu, 15 Aug 2013 15:11:03 +0300 From: =?UTF-8?B?QXJpIEtlcsOkbmVu?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Magnus Westerlund References: <20130718161212.19084.19711.idtracker@ietfa.amsl.com> <51F61F88.1000503@ericsson.com> <520A302E.7010508@ericsson.com> In-Reply-To: <520A302E.7010508@ericsson.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvrW7kUZ4gg7vLWSzeX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfFySmDBKtGK7wd/sDQwtgt2MXJySAiYSMxo /8YIYYtJXLi3nq2LkYtDSOAwo8SrU1OZIJz1jBLfPu9nhXD2Mkr09fxlgXDWMUpMavzGDuGs YJTY9PkGC8gwXgFtiWXvFwIN5uBgEVCVeLTZCiTMJmArsfrVTbASUYFkib1LTzNDlAtKnJz5 BCwuImAm8XDCfjYQm1nAVWLVrtnMIGOEBaokji01h1jVyChxrvEaK0gNp4COxObm3VD1FhKL 3xxkh7DlJZq3zmaG+E1N4uq5TWC2ENA5V/+9YpzAKDoLyepZSNpnIWlfwMi8ipE9NzEzJ73c aBMjMOgPbvmtuoPxzjmRQ4zSHCxK4ryb9c4ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC0 lkzmWLS55dYbicmfsvetd1D8wSh3o0LOWlihad8vI1f+5F7HzJxp0VLidu8MC/wf3vivN+0S 7/MXTfb79mlLMAc03p9eeVvEwfVa2JU8LuOelWoiFVl/Hn/RLDt35/qByombhAWMLJy97qrf FlF4si321Apjo8KHCt1VBUfs7Q/ONN2Y1avEUpyRaKjFXFScCAAVxkzwSAIAAA== Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] New Liaison Statement, "LS on Missing IANA Registration Information on SDP Attributes in RFC 2326" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 12:11:12 -0000 This looks good to me. Thanks Magnus! Cheers, Ari On 8/13/13 4:10 PM, Magnus Westerlund wrote: > > > On 2013-07-29 09:53, Ari Keränen wrote: >> MMUSIC, >> >> We have received a liaison statement from 3GPP regarding missing SDP >> attributes at the IANA registry (see the e-mail below for details). >> >> As the statement says: >>> SA4 has identified that IANA registrations of three SDP attributes >>> defined in RFC 2326, namely ‘control’, ‘range’ and ‘etag’, are missing >> >> As a solution, the RTSP 2.0 draft already registers 'control' and >> 'range' for RFC 2326 and RFC 2326bis >> (http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-34#section-22.15). >> However, in RFC2326bis 'etag' is renamed into 'mtag'. >> >> Hence, it seems that we should also register 'etag' but for that >> reference RTSP 1.0 (RFC 2326) only. >> >> Please review the liaison statement and our proposed solution and send >> your comments to us and to the list. > > WG, > > I volunteer to send an email registering these SDP attributes to IANA so > that a respond can be sent to 3GPP SA4 that they attribute has been > registered. I propose to include all attributes in that registration. I > can clarify in the RFC 2326bis draft that the SDP registrations are an > update to what we put in at this stage. I have also chosen to put "etag" > in the both category due to that is what has been done in the RFC2326bis > draft as the original text is far from clear if it is a session only or not. > > Thus I propose to send the below to IANA on Monday (19th of Aug) unless > someone disagree. > > >> Dear IANA, >> >> It has come to our attention that the SDP attributes defined in RFC 2326 >> are not registered in the SDP attributes registry, i.e. related to RFC >> 4566 found at: >> www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml >> >> In registry: att-field (both session and media level) >> >> Please add the following SDP Attributes: >> >> SDP Name: control >> Reference: RFC 2326 >> >> SDP Name: range >> Reference: RFC 2326 >> >> SDP Name: etag >> Reference: RFC 2326 >> >> Contact: Authors of RFC 2326 >> >> Thanks >> >> Magnus Westerlund > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From harald@alvestrand.no Thu Aug 15 07:59:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79311E816B for ; Thu, 15 Aug 2013 07:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib55-yGW2wEj for ; Thu, 15 Aug 2013 07:58:58 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8563421F9F84 for ; Thu, 15 Aug 2013 07:58:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A250239EA7B for ; Thu, 15 Aug 2013 16:58:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VI260Xxgqqv for ; Thu, 15 Aug 2013 16:58:40 +0200 (CEST) Received: from [172.28.249.38] (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EC27D39E3F4 for ; Thu, 15 Aug 2013 16:58:39 +0200 (CEST) Message-ID: <520CEC9F.9010807@alvestrand.no> Date: Thu, 15 Aug 2013 16:58:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> <520A2564.7090404@alvestrand.no> <520BBE2D.5000604@alum.mit.edu> In-Reply-To: <520BBE2D.5000604@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:59:12 -0000 On 08/14/2013 07:28 PM, Paul Kyzivat wrote: > I have a fundamental question about this draft: > > With Unified Plan we have a unique m-line for every MediaStreamTrack. > Given that, why do we need the msid attribute? Isn't it sufficient to > define a new semantic ("mediastream"?) for the grouping framework? > (RFC3388). > > There would still be need for a way to convey the application data, > but that can be done via another attribute ("mediastream-data"?) > associated with the m-line. I wondered about that too. We have two IDs to convey: - The ID of the MediaStream. The grouping can be a new semantic for the grouping framework, but the actual ID value has to be carried somewhere - it has to be associated with the group, so it can't be a session-level attribute. - The ID of the MediaStreamTrack. Now that MediaStreamTracks correspond to m-lines, it makes sense to carry this in a media-level attribute. I'm sure we can design another scheme for carrying those IDs around. But I do wonder what the positive value of restructuring this is. > > Thanks, > Paul > > On 8/13/13 2:24 PM, Harald Alvestrand wrote: >> The auto-poster doesn't seem to want to tell mmusic about this.... >> >> this is updated according to Unified-plan. Since it was only 1 day >> before the old version had expired, the proofreading might be a little >> light - please point out places where I had missed changing "SSRC" to >> "m-line"! >> >> I retained some description of the old mechanism (using a=ssrc) in an >> appendix. Please state opinions on whether this should be retained as >> informative, promoted to normative, or removed entirely in the next >> version. >> >> Hope this informs! >> >> Harald >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ietf-mmusic-msid-01.txt >> Date: Tue, 13 Aug 2013 05:13:42 -0700 >> From: internet-drafts@ietf.org >> To: Harald T. Alvestrand , Harald Alvestrand >> >> >> >> >> A new version of I-D, draft-ietf-mmusic-msid-01.txt >> has been successfully submitted by Harald Alvestrand and posted to the >> IETF repository. >> >> Filename: draft-ietf-mmusic-msid >> Revision: 01 >> Title: Cross Session Stream Identification in the Session >> Description Protocol >> Creation date: 2013-08-13 >> Group: mmusic >> Number of pages: 14 >> URL:http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt >> Status:http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid >> Htmlized:http://tools.ietf.org/html/draft-ietf-mmusic-msid-01 >> Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01 >> >> Abstract: >> This document specifies a 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 >> ismmusic@ietf.org. >> >> >> >> >> >> 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 martin.thomson@gmail.com Thu Aug 15 08:32:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B93D11E8197 for ; Thu, 15 Aug 2013 08:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB8oont1cuq3 for ; Thu, 15 Aug 2013 08:32:37 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2EF11E8194 for ; Thu, 15 Aug 2013 08:32:33 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so671057wgh.5 for ; Thu, 15 Aug 2013 08:32:32 -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=/9HMFOelO1q5nZuHkph/eProzgl7J/MTG4xoaSpI2VQ=; b=L7oSaLj6md4XFyfell3XtbVkn2IHF+s1XwpmoBU+TAgH6oLqYV1ROpPGORx3HNqLI9 wEXC7WEBAOswMVTKv/WK7v/ECqT71YwsEM9jl7lcB06WVOJuF0F7BCjdNzA0mNZSfwxa /NfXPIH8/4enl3cGkxG4yjCiAx6j/2h5TpEkNfnzdnRXvPCtGOPVbmIG+hegxsEA+G0q qBqOL4G8ErgYlid9SkVPulIh9Jp03VRXgQE1/yeBkVtR9QPsl5vhPcUuQ4H25Tzhzz98 PxDdTN8C/hmk+bO1o4ZiBAS96wWbTH79ZehvmdpmBnQ9eEvYIBKjkRPfnjyhA54NK6e/ 0Fcg== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr2139729wic.65.1376580751320; Thu, 15 Aug 2013 08:32:31 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Thu, 15 Aug 2013 08:32:31 -0700 (PDT) In-Reply-To: <520CEC9F.9010807@alvestrand.no> References: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> <520A2564.7090404@alvestrand.no> <520BBE2D.5000604@alum.mit.edu> <520CEC9F.9010807@alvestrand.no> Date: Thu, 15 Aug 2013 16:32:31 +0100 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 15:32:40 -0000 On 15 August 2013 15:58, Harald Alvestrand wrote: > I wondered about that too. > We have two IDs to convey: > > - The ID of the MediaStream. The grouping can be a new semantic for the > grouping framework, but the actual ID value has to be carried somewhere > - it has to be associated with the group, so it can't be a session-level > attribute. > > - The ID of the MediaStreamTrack. Now that MediaStreamTracks correspond > to m-lines, it makes sense to carry this in a media-level attribute. > > I'm sure we can design another scheme for carrying those IDs around. > But I do wonder what the positive value of restructuring this is. The MediaStream identifier gets lost if the grouping framework is used. Unless you define some sort of new mapping attribute, which could end up looking like a=msid if you aren't careful. The MediaStreamTrack identifier could be doubled onto the a=mid value. I've always been lukewarm on transmitting identifiers in this fashion, but I find it hard to find a better (i.e., cleaner, more obvious, less redundant) solution than msid, except perhaps this one: a=appgroup:MediaStreamId Track1 Track2 a=group:LS Track1 Track2 m=... a=mid:Track1 m=... a=mid:Track2 --Martin From partha@parthasarathi.co.in Thu Aug 15 09:48:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EF711E81E4 for ; Thu, 15 Aug 2013 09:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53swX3EOAA63 for ; Thu, 15 Aug 2013 09:48:32 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id D695811E81D9 for ; Thu, 15 Aug 2013 09:48:32 -0700 (PDT) Received: from userPC (unknown [122.172.186.109]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id F29AB1908180; Thu, 15 Aug 2013 16:48:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1376585311; bh=enkJ3M7ctteNi/SdfArKplA43YPGQTkQVDooolA74uc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ic8F2fFIexU5HUPJqz4+fD0NPrJ8LJE7HMUHsIxii5GYntd+bBQjQ546kl+14tqwS gCWE4zdhcJ2tYDuP1jT76pIMBSmXaAUuCvTwgxpD1/AMY3KVs1Z9K+rJPljEc5GYW9 jsmpAVsxpCnGCzdiHFJ4/9RE/F8Agbcodvi5bHDI= From: "Parthasarathi R" To: "'Cullen Jennings \(fluffy\)'" References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com>, <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <009d01ce951b$d52aa340$7f7fe9c0$@co.in> In-Reply-To: Date: Thu, 15 Aug 2013 22:18:19 +0530 Message-ID: <001b01ce99d7$425295d0$c6f7c170$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOmHzRKhPenv+lz0620AA+309SKpmWeNgw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0201.520D065F.008B, 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: 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 70.87.28.138 Cc: 'mmusic WG' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 16:48:37 -0000 Cullen, The violation of RFC 3264 happens as follows: 1) In case m line has port "0" and bundle-only attribute exists in the Answer, it is possible to interpret by the offerer in two ways as a) Answer is rejected by the answerer wherein bundle-only attribute has to be ignored. This in inline with RFC 3264. Here, there is a need for extra offer/answer to confirm bundle is supported or not. b) Answer is rejected by the answerer wherein bundle-only attribute is supported. Here, there is no need of one more offer/answer but the interop issues with SIP entities will happen. 2) There are middle-boxes which provides QoS based on the current offer/answer. In case of WebRTC, the simplified topology shall be "Browser----SIP server-----Browser/SIP UA" In these scenario, SIP server initiates Qos based on offer/answer exchange between browsers. These SIP servers will fail in case an optional attribute like "bundle-only" updates RFC 3264 behavior like offer with port 0 and answer with proper port. Thanks Partha > -----Original Message----- > From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Sent: Wednesday, August 14, 2013 4:59 AM > To: Parthasarathi R > Cc: mmusic WG > Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle- > only m- lines? > > > On Aug 9, 2013, at 10:16 AM, Parthasarathi R > wrote: > > > This approach also > > Violates Sec 8.2 of RFC 3264 requirement > > > > " A stream that is offered with a port of zero MUST be marked with > port > > zero in the answer." > > No this would not be violated. When one side was 3264 only, this would > still happen. But when both sides support bundle-only, then this > restriction no longer holds. The bundle draft as an extension to 3264 > needs to clearly define all that. From partha@parthasarathi.co.in Thu Aug 15 10:13:48 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5FC11E81E9 for ; Thu, 15 Aug 2013 10:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSrnRR9rKwq0 for ; Thu, 15 Aug 2013 10:13:43 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9D91711E81DB for ; Thu, 15 Aug 2013 10:13:43 -0700 (PDT) Received: from userPC (unknown [122.172.186.109]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 685A0190824B; Thu, 15 Aug 2013 17:13:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1376586821; bh=NPJW0DpoEN+2mo6Ucu2qDxXF0t7R+0GVw9DQW56kYWw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=i836jAbNYEYj8sG8OiY1f6Iw/60Dm3T75qwFVtifnBJLAnDBcpIWcj8zky/ET9wc4 VMlVbs/yZ06Z6gw6CJ5FYQD3q61u6dmKN8o1PARfbo9ktaAKm8it4Rlc7GTXuQmol4 XQLLt6rnqasLTVpV2Z9QnfjPkVLOanRAzi7Q05ts= From: "Parthasarathi R" To: "'Eric Rescorla'" , "'Christer Holmberg'" References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> <9AA75667-A597-4EB1-87B4-FA79A2F35C3C@oracle.com> <5203D7E7.4070207@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422522@ESESSMB209.ericsson.se> <1687A002-7B01-4468-85DD-FF19BDFDAE14@oracle.com> <5203EB64.70605@nostrum.com> <65BCA443-98E1-4843-9522-248DD5B4ED68@oracle.com> <5203F37A.8030204@nostrum.com> <33EF0E51-D7E2-42BC-98AA-1A96E2E3CB4D@oracle.com> <5203F4D8.9040904@nostrum.com> <9BB1DB2F-32DB-453E-BAEF-3E600EAD3413@oracle.com> <5204075B.1080108@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C422D7D@ESESSMB209.ericsson.se> <52051D0C.2070106@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C42339E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C427679@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806 D1A2204B1C43BA02@ESESS MB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C43DBA9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C440F3B@ESESSMB209.ericsson.se> In-Reply-To: Date: Thu, 15 Aug 2013 22:43:26 +0530 Message-ID: <002301ce99da$c5d56560$51803020$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CE9A08.DF8DA160" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6WoycXRkr58VNlT5eGbrBy0UAVRwDNj3jA Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0204.520D0C44.0149, 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: 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 70.87.28.138 Cc: "'mmusic_ietf.org'" , 'Paul Kyzivat' Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 17:13:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0024_01CE9A08.DF8DA160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric, > For instance, Neither Firefox nor Chrome current does a second O/A > transaction and yet media flows just fine in most cases, since they are operating > in an unmediated environment. Till now, my understanding is that Firefox & Chrome provides the running code which is not fully compliant with all WebRTC specification. In fact, I had come across the scenario wherein it is not clear in the signaling which candidate pair is selected by the browser for media. Please correct me in case the specification is not mandated to perform second O/A to confirm the port selected for the media. Thanks Partha From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Sunday, August 11, 2013 8:21 PM To: Christer Holmberg Cc: mmusic_ietf.org; Paul Kyzivat Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg wrote: Hi, >> I think making sure all entities have the correct port numbers is critical in making sure the media will flow. > > There is a difference between "making sure the media will flow" and "before media can > flow at all". > For instance, Neither Firefox nor Chrome current does a second O/A > transaction and yet media flows just fine in most cases, since they are operating > in an unmediated environment. Obviously, this is a best-case scenario, but similarly > there are going to be mediated environments which are perfectly happy with a second > O/A exchange with non-zero ports. There are also environements where a single offer, with identical port numbers, work just fine, because the receiver will be able to handle it even if it doesn't support BUNDLE. However, we are defining a generic mechanism, supposed to work in different environments. "different environments" != "arbitrary lossage by any middlebox in the universe" Again, you need to distinguish between *endpoints* and filtering middleboxes. But, sure, if the community thinks that we shall define different options, depending on environments etc, we can do that... Which is not what I said. -Ekr Regards, Christer -----Original Message----- From: Eric Rescorla [ekr@rtfm.com] To: Christer Holmberg [christer.holmberg@ericsson.com] CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; Paul Kyzivat [pkyzivat@alum.mit.edu] Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg wrote: Hi, >>> Requiring a second offer to add the bundle-only m-lines defeats the purpose of bundle-only. >> We already require a second offer. I know that some people, including yourself, want to change that, but that is nothing we have agreed on. >> >>> a) The delay to do an O/A will often exceed the time to allocate candidates, for small numbers of streams; bundle-only was meant to avoid this candidate latency. >> You do not have to allocate ports for the bundle-only m- lines. >> >>> b) Once you have the initial answer, you know whether the other side supports BUNDLE, so you can take the appropriate action (and so there is no need for bundle-only). >>> >>> If SIP can't deal with the bundle-only concept, then WebRTC apps that care about latency will have to decide whether they are running in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams will be bundled in the initial offer; in compatibility mode, 2 offer-answers will be needed. >> There are no "modes" in BUNDLE today :) >> > Of course there are. The handling in a reinvite case is distinct from the initial offer, so that is modal behavior. Sure, but you were talking about "WebRTC-only mode" and "compatibility mode", and my point is that currently the procedures for initial offers, subsequent offers etc are the same. >>> This would be a somewhat unfortunate outcome, so I'd like to see bundle-only (or something like it) work. >> I don't think the second offer is going to cause any latency. Also, keep in mind that you only need the 2nd Offer/Answer during the session establishment. As agreed in Berlin, in mid-session changes you do NOT need 2 offer/answers. > > Please provide support for this statement. It seems clear that a 2nd offer adds _at least_ 1 RTT latency. Sure, but I don't think that is going to be a practical problem. Well, I'd like to see a more convincing argument than "some middleboxes are sad" when you do that. First, there are deployed legacy SIP systems that use even more O/A transactions during session establishment. And, in your case I assume you are even going to use something more "lightweight" than SIP to carry your Offer/Answers. Second, as WebRTC mandates usage of ICE, you are often going to need a subsequent O/A anyway. It's important to distinguish between round-trips that are in the critical path for media flowing and those which are not. -Ekr ------=_NextPart_000_0024_01CE9A08.DF8DA160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

<snip>

> For instance, Neither Firefox nor Chrome = current does a second O/A
> transaction and yet media flows just fine in most cases, since they = are operating
> in an unmediated environment.

<snip>

 

Till now, my understanding is that Firefox & = Chrome provides the running code which is not fully compliant with all WebRTC = specification. In fact, I had come across the scenario wherein it is not clear in the signaling which candidate pair is selected by the browser for media. = Please correct me in case the specification is not mandated to perform second = O/A to confirm the port selected for the media.

 

Thanks

Partha

 

From:= mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Eric Rescorla
Sent: Sunday, August 11, 2013 8:21 PM
To: Christer Holmberg
Cc: mmusic_ietf.org; Paul Kyzivat
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for = bundle-only m- lines?

 

 

 

On Sun, Aug 11, 2013 at 6:11 AM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

Hi,

>> I think making sure all entities have the correct port numbers = is critical in making sure the media will flow.
>
> There is a difference between "making sure the media will = flow" and "before media can
> flow at all".
> For instance, Neither Firefox nor Chrome current does a second = O/A
> transaction and yet media flows just fine in most cases, since they = are operating
> in an unmediated environment. Obviously, this is a best-case = scenario, but similarly
> there are going to be mediated environments which are perfectly = happy with a second
> O/A exchange with non-zero ports.

There are also environements where a single offer, = with identical port numbers, work just fine, because the receiver will be = able to handle it even if it doesn't support BUNDLE.

However, we are defining a generic mechanism, supposed to work in = different environments.

 

"different environments" !=3D = "arbitrary lossage by any middlebox in the universe"

 

Again, you need to distinguish between *endpoints* = and filtering middleboxes.

 

 

But, sure, if the community thinks that we shall = define different options, depending on environments etc, we can do = that...

 

Which is not what I said.

 

-Ekr

 

Regards,

Christer





-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
To: Christer Holmberg [christer.holmberg@ericsson= .com]

CC: Justin Uberti [juberti@google.com]; mmusic@ietf.org [mmusic@ietf.org]; Paul Kyzivat [pkyzivat@alum.mit.edu]
Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for = bundle-only m- lines?





On Sat, Aug 10, 2013 at 3:08 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:

Hi,


>>> Requiring a second offer to add the bundle-only m-lines = defeats the purpose of bundle-only.
>> We already require a second offer. I know that some people, = including yourself, want to change that, but that is nothing we have agreed = on.
>>
>>> a) The delay to do an O/A will often exceed the time to = allocate candidates, for small numbers of streams; bundle-only was meant to avoid = this candidate latency.
>> You do not have to allocate ports for the bundle-only m- = lines.
>>
>>> b) Once you have the initial answer, you know whether the = other side supports BUNDLE, so you can take the appropriate action (and so = there is no need for bundle-only).
>>>
>>> If SIP can't deal with the bundle-only concept, then WebRTC = apps that care about latency will have to decide whether they are running in WebRTC-only mode or compatibility mode. In WebRTC-only mode, streams = will be bundled in the initial offer; in compatibility mode, 2 offer-answers = will be needed.
>> There are no "modes" in BUNDLE today :)
>>
> Of course there are. The handling in a reinvite case is distinct = from the initial offer, so that is modal behavior.


Sure, but you were talking about "WebRTC-only mode" and "compatibility mode", and my point is that currently the = procedures for initial offers, subsequent offers etc are the same.


>>> This would be a somewhat unfortunate outcome, so I'd like = to see bundle-only (or something like it) work.
>> I don't think the second offer is going to cause any latency. = Also, keep in mind that you only need the 2nd Offer/Answer during the session establishment. As agreed in Berlin, in mid-session changes you do NOT = need 2 offer/answers.
>
> Please provide support for this statement. It seems clear that a = 2nd offer adds _at least_ 1 RTT latency.


Sure, but I don't think that is going to be a practical problem.



Well, I'd like to see a more convincing argument than "some = middleboxes are sad" when you
do that.




First, there are deployed legacy SIP systems that use even more O/A transactions during session establishment. And, in your case I assume = you are even going to use something more "lightweight" than SIP to = carry your Offer/Answers.

Second, as WebRTC mandates usage of ICE, you are often going to need a subsequent O/A anyway.



It's important to distinguish between round-trips that are in the = critical path for media
flowing and those which are not.


-Ekr

 

------=_NextPart_000_0024_01CE9A08.DF8DA160-- From pkyzivat@alum.mit.edu Thu Aug 15 10:16:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9372311E81CF for ; Thu, 15 Aug 2013 10:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CICOPWz-q7EE for ; Thu, 15 Aug 2013 10:16:02 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id C648E11E817A for ; Thu, 15 Aug 2013 10:16:01 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta02.westchester.pa.mail.comcast.net with comcast id D0Un1m0020SCNGk515G0S0; Thu, 15 Aug 2013 17:16:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id D5G01m01B3ZTu2S3V5G0CS; Thu, 15 Aug 2013 17:16:00 +0000 Message-ID: <520D0CCF.8020401@alum.mit.edu> Date: Thu, 15 Aug 2013 13:15:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> <520A2564.7090404@alvestrand.no> In-Reply-To: <520A2564.7090404@alvestrand.no> 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=q20121106; t=1376586960; bh=oepA+ZQvdzRUTPBLDaIO2inUbeZ7V4oqBMpwQkOQYkM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eFhCMe64ICUInxl+WtudbZNolCZGg1Y/IJNUmhmm+cEDs1qP1T/hjcZkH87tYyT9d aCUSadBWtHlRJHJYrBj6/3vYrGkFfD/pmclA7h/Ig+AJTj8wDQcq9/jTCLu1OXX71m sZMQtuF3JF6iUqgu+vVVBmqV9xHCFo4iWv2RL3v9hi++mKa5jElkQp3LhPEPVp3Rx8 SKpUlH+QbBxNaeK/5PGq8oma6PTicO2di4SoviqPVZTi+MXY8+UWdYv9s/21mk+Nm6 j/v2ev9VeBP6tnTHqrrk4of9taYodfOua+Yob821NAYJZMJhZU+SdS1TVLbQqfAgs4 bbnoZpLvOgJFQ== Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 17:16:06 -0000 I went through this version, with an eye to alignment with the Unified Plan. I have a number of comments, some nits, some not: General: The Unified Plan says a single m-line describes one media source. It allows this source to consist of multiple RTP Streams (identified by SSRC). And it allows associating RTP Streams with m-lines multiple ways, not just by SSRC. This msid draft hasn't fully incorporated those concepts. It still seems to assume that a media source corresponds to a single SSRC. It would be helpful to have a section discussion the process of associating SSRCs to MedisStreamTracks. (And I think this needs to include the possibility that an SSRC might be moved from one MediaStreamTrack to another.) Section 2: The identifier is a string of ASCII characters chosen from 0-9, a-z, A-Z and - (hyphen), consisting of between 1 and 64 characters. It MUST be unique among the identifier values used in the same SDP session. It is RECOMMENDED that is generated using a random-number generator. ... There may be multiple msid attributes on a single m-line. There may also be multiple m-lines that have the same value for identifier and application data. What does uniqueness mean in this context, since it can be used multiple times, with the same or different m-lines? I *think* you mean that a given identifier value is associated with a single MediaStream for the duration of the SDP session. Also, msid attributes aren't "on" an m-line. I think it would be clearer to say "Multiple msid attributes may be associated with a single m-line." But with the Unified Plan this isn't true. Also, I find the use of "identifier" and "token" very confusing. It is hard to keep track of the semantics intended for those things. It would be easier to follow if some more specific terms were used. For example, "mediastream-id" instead of "identifier" in the msid and msid-semantics attributes, and "semantics" instead of "token" in msid-semantics attribute. ("semantics" is what is used in 3388 and 5576.) Section 4: o When a description is updated to have more SSRCs with the same msid value, but different appdata values, the recipient can signal to its application that new MediaStreamTracks have been added to the media stream. Is SSRC relevant any longer? s/SSRCs/m-lines/ ??? Also in Section 4: In addition to signaling that the track is closed when it disappears from the SDP, the track will also be signaled as being closed when all associated SSRCs have disappeared by the rules of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout). Here we can't avoid talking about SSRCs. But maybe more is needed about what SSRCs are associated with a particular m-line & msid value? Section 4.1: Pre-WebRTC entities will not send msid. This means that there will be some incoming RTP packets with SSRCs where the recipient does not know about a corresponding MediaStream id. In the context of the Unified Plan I think this could be stated better: There may be some incoming RTP packets that the recipient cannot associate with a MediaStreamTrack. Also: o An msid-semantic:WMS attribute is present. In this case, the session is WebRTC compatible, and the newly arrived SSRCs are either caused by a bug or by timing skew between the arrival of ... I suggest: o An msid-semantic:WMS attribute is present. In this case, the session is WebRTC compatible, and the unassociated packets are either caused by a bug or by timing skew between the arrival of ... Thanks, Paul On 8/13/13 2:24 PM, Harald Alvestrand wrote: > The auto-poster doesn't seem to want to tell mmusic about this.... > > this is updated according to Unified-plan. Since it was only 1 day > before the old version had expired, the proofreading might be a little > light - please point out places where I had missed changing "SSRC" to > "m-line"! > > I retained some description of the old mechanism (using a=ssrc) in an > appendix. Please state opinions on whether this should be retained as > informative, promoted to normative, or removed entirely in the next version. > > Hope this informs! > > Harald > > > -------- Original Message -------- > Subject: New Version Notification for draft-ietf-mmusic-msid-01.txt > Date: Tue, 13 Aug 2013 05:13:42 -0700 > From: internet-drafts@ietf.org > To: Harald T. Alvestrand , Harald Alvestrand > > > > > A new version of I-D, draft-ietf-mmusic-msid-01.txt > has been successfully submitted by Harald Alvestrand and posted to the > IETF repository. > > Filename: draft-ietf-mmusic-msid > Revision: 01 > Title: Cross Session Stream Identification in the Session Description Protocol > Creation date: 2013-08-13 > Group: mmusic > Number of pages: 14 > URL:http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt > Status:http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid > Htmlized:http://tools.ietf.org/html/draft-ietf-mmusic-msid-01 > Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01 > > Abstract: > This document specifies a 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 > ismmusic@ietf.org. > > > > > > 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 christer.holmberg@ericsson.com Fri Aug 16 00:17:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5B711E8111 for ; Fri, 16 Aug 2013 00:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZfRs4ROGq1O for ; Fri, 16 Aug 2013 00:17:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A0B8011E825A for ; Fri, 16 Aug 2013 00:17:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-49-520dd1f0fd4f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3C.5A.22048.0F1DD025; Fri, 16 Aug 2013 09:17:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Fri, 16 Aug 2013 09:17:04 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers Thread-Index: Ac6SwAaH+8B2wVyxQFSEGu6rKTxpcQFp3RKAAHouH+A= Date: Fri, 16 Aug 2013 07:17:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C44E4EE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre7Hi7xBBr++sVl0TGazmLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfH45STGgs0sFb8v9TA3MO5m7mLk5JAQMJHY desWC4QtJnHh3nq2LkYuDiGBw4wSn+6uZYdwFjNKbJx1Hsjh4GATsJDo/qcN0iAiYCjRtGce E4jNLCAjMeNsI5gtLOAjMfXbckaQchEBX4nzU2ogTCuJS+9iQSpYBFQlZi3oZwWxeYEqLnX9 glo7gVFi8cVr7CAJTpDWjvdsIDYj0G3fT62BWiUu8eHgdaj7BSSW7DkPZYtKvHz8jxXCVpL4 seESC0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm 5qSXm29iBMbHwS2/DXYwbrovdohRmoNFSZx3s96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MKVO+Rjp93OLE8Oju/rA890lTdkWlvSizeFece1gy7rZMc8KtZR8V1ycxW61r3nJfLCDQ nd355L3bG1dbGEz+1HvM1/TRisY+i55dsQdM1Lofrbo+K2fp1iv7b0vYVp0+Ofn8SvZI7mPH bW4Wdc+JOTJ58dbm222+JZPui6tuOb0y5NlBq0hfOyWW4oxEQy3mouJEACvJWeldAgAA Cc: mmusic Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 07:17:13 -0000 Hi, =20 >> It has been indicated that POFs (partial offers) and PANs (partial answe= rs) form a stand-alone mechanism, instead of being an extension of RFC3264. > > uh, I don't think so. THey seem sot be an optional extension to 3264 Well, that is not what was indicated during the meeting (if we don't count = Hadriel :)... Anyway, I guess that is part of the solution discussions. But, whatever it'= s an extension or not, I don't think it changes the fact that there will in= teractions between POF/PANs and 3264 O/As. Regards, Christer From christer.holmberg@ericsson.com Fri Aug 16 00:24:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282C011E8111 for ; Fri, 16 Aug 2013 00:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddyF2qFKKU8y for ; Fri, 16 Aug 2013 00:24:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 59D6E11E810F for ; Fri, 16 Aug 2013 00:24:13 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-7c-520dd39c0238 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C3.04.03802.C93DD025; Fri, 16 Aug 2013 09:24:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Fri, 16 Aug 2013 09:24:11 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? Thread-Index: AQHOmHzQ4AP154JSMUmzSenKQDde2pmXcW3A Date: Fri, 16 Aug 2013 07:24:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C44E532@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C421C80@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre6cy7xBBgefi1h0TGazmLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfFk/zLmgvUcFcdX9TI1MO5i62Lk5JAQMJFo Xt7KBGGLSVy4tx4ozsUhJHCYUaLxUBMzhLOYUWLJ/+mMXYwcHGwCFhLd/7RBGkQEDCWa9swD a2YWkJGYcbaRCaREWCBMYv/LCIiScInDH7YxQdhGEv+7fjKD2CwCqhJnjr9kBbF5BXwlOp92 s0KsmsAosXPaRrAGTqDErXUHGUFsRqDjvp9aA7VLXOLDwevMEEcLSCzZcx7KFpV4+fgfK4St JPFjwyUWiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYmTP TczMSS832sQIjJCDW36r7mC8c07kEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhiLzhzcOeeO6kTLw7FLp0xY/nfii3fxImxP7qy/Mt18kri3cprvno7Tt9kd171bsWZy h/h8e2GDfb6GwWsf3643c9TrcZMzC/mjWL3myC6fuB/nd8yP4GBwylSc+G05W0OW+6vKax/0 dugvFr9+6tb8hiUTfmUdf1N5l//xQvN/fbe+fHgtqHTltBJLcUaioRZzUXEiADcua8JeAgAA Cc: mmusic Subject: Re: [MMUSIC] BUNDLE goes UP: Do we need port zero for bundle-only m- lines? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 07:24:23 -0000 Hi, >> As has been indicated, bundle-only can only be used when one knows that = the receiver, and possible intermediaries etc, support it. > =20 >=20 > > I don't think that is the case. It can be used in an offer regardless of = if you know the answer can support it or not.=20 > > Related to other messages on the thread. Yes, I understand that ICE will= have a "clean up O/A" to fix all the ports to be the ones actually in use = but media flows before=20 > that "clean up". I have zero interest in exploding all this again to disc= uss a solution that would require more round trips before media could flow = and be less likely to work=20 > with existing SIP stuff. I think the current design is better than one th= at would require multiple O/A to get media to flow.=20 Discuss what??? In general, the current version of BUNDLE is based on the usage of 2 Offer/= Answers - which is something you have agreed to. If you only refer to bundle-only lines, that is a discussion that has just = started... Regards, Christer From christer.holmberg@ericsson.com Fri Aug 16 00:35:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A85E11E810A for ; Fri, 16 Aug 2013 00:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh+GsalYI-kl for ; Fri, 16 Aug 2013 00:35:38 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 48FDC11E825A for ; Fri, 16 Aug 2013 00:35:38 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-c6-520dd6487312 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B7.8A.25272.846DD025; Fri, 16 Aug 2013 09:35:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.92]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Fri, 16 Aug 2013 09:35:04 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" Thread-Topic: [MMUSIC] UP: Can a partial offer be a full offer? Thread-Index: AQHOke7vCbCwhSX1mkyx6wsRumrcBZmGnR2AgAAyiAqADNsBAIAD1rVw Date: Fri, 16 Aug 2013 07:35:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C44E693@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra7nNd4gg9WnuS06JrNZfNr0idli 6vLHLA7MHlN+b2T1WLLkJ5PHx6e3WAKYo7hsUlJzMstSi/TtErgyLiz+zlLwT7qiY+Ey9gbG 2WJdjJwcEgImEh+ebGOHsMUkLtxbz9bFyMUhJHCUUeLrhp2sIAkhgcWMEjMO53cxcnCwCVhI dP/TBgmLCBhKNO2ZxwRiMwt4SKz8MYERxBYWsJOYt/47G0SNvcSu1nYmCNtNYt2ktWBxFgFV iZMX97KA2LwCvhLTf19kgdh7lknifd8rdpBdnECJC5vqQWoYgW77fmoN1C5xiQ8HrzND3Cwg sWTPeShbVOLl43+sELaSxI8Nl1gg6vUkbkydwgZha0ssW/iaGWKvoMTJmU9YJjCKzUIydhaS lllIWmYhaVnAyLKKkaM4tTgpN93IYBMjMGoObvltsYPx8l+bQ4zSHCxK4rxb9M4ECgmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamB0izjSUFqqzLtRZb/+hSiG2eVCt37tXMwfPb202SzhZyjL 5Rlff7O9OBPCebHH6X/tmz87KpSVXp36eGH904/7Xq1NV4ir6uLyeFvtF5XiIc6WaCev5hGr Mm+v4ives8rH+jtfM80+K6iVeSJ9zkHfBLPV1XUtW7R09n/cpC4ounGL2ZKgl2pKLMUZiYZa zEXFiQBceRFVaAIAAA== Cc: mmusic Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 07:35:43 -0000 Hi, It is ok to only send m- line(s) that are changed. But, again, when you in a POF/PAN change on m- line explicitly, other m- li= nes may be changed implicitly. So, if you at the same time explicitly (usin= g a separate POF/PAN) also try to change those other m- line, there will be= a collision. Or, as Paul says, if multiple simultaneous POF/PANs change session level in= formation, there will be collision. MAYBE we could restrict usage of POF/PANs, and say that they MUST NOT be us= ed to change session level information... Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]=20 L=E4hetetty: 14. elokuuta 2013 1:54 Vastaanottaja: Christer Holmberg Kopio: Hadriel Kaplan; mmusic Aihe: Re: [MMUSIC] UP: Can a partial offer be a full offer? You only want to send the m blocks that have changed because if you send ot= her ones, you up the chances of both sides sending the same m block at the = same time and being back into the glare problem.=20 It seems to me the options are either 1 or 2 would make sense=20 1) the sender SHOULD only send m m blocks with a change (which might be al= l of them) and receiver MUST be prepared to receive any number.=20 2) you can only send one m block in a partial Off or Ans - but you can hav= e several outstanding at a time On Aug 5, 2013, at 10:35 AM, Christer Holmberg wrote: > Hi, > =20 > I see no issue with multiple m- lines - just wanted to verify that it wou= ld be allowed :) > =20 > Regards, > =20 > Christer > =20 >=20 >=20 > Sent from Windows using TouchDown (www.nitrodesk.com) >=20 > -----Original Message----- > From: Hadriel Kaplan [hadriel.kaplan@oracle.com] > To: Christer Holmberg [christer.holmberg@ericsson.com] > CC: mmusic [mmusic@ietf.org] > Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? >=20 > On Aug 5, 2013, at 11:17 AM, Christer Holmberg wrote: >=20 > > Note that my re-INVITE/UPDATE example is based on the assumption that o= ne can use partial offers/answers with SIP, on the wire. Not sure if that w= as part of the agreed scope for the UP. >=20 > Definitely NOT agreed on. Doesn't mean it won't happen in the future, bu= t the scope of UP was limited to WebRTC for now. We can debate which parts= of UP are generically applicable, and which not. For SIP, this isn't the = right WG for that debate. >=20 >=20 > > But, even without that, I think the question on including all m- lines = on a partial offer still applies :) >=20 > I don't see why WebRTC would restrict itself in any way regarding the num= ber of m-lines in a partial offer/answer. Nothing "breaks" if all m-lines = are in it, does it? The real question is if it can be greater than *one* m= -line. If it can, and I think it can, then I can't see how the exact quant= ity of them matters. The only downside is you increase the chance of glare= , I assume. >=20 > Afaik, the 'mid' attribute is there to identity which m-lines in the part= ial offer correspond to which m-lines in the full ordered set. (the 'mid' c= ould have even been an index number, except it's also used to avoid glare w= hen adding m-lines, which a numeric index wouldn't have done) So what's th= e issue with one or multiple m-lines? >=20 > -hadriel >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From fippo@goodadvice.pages.de Fri Aug 16 00:48:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0926B11E810F for ; Fri, 16 Aug 2013 00:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtC+qNeOWeHL for ; Fri, 16 Aug 2013 00:48:31 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id B1CB611E810A for ; Fri, 16 Aug 2013 00:48:30 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r7G7mRX2014329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 09:48:27 +0200 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id r7G7mRR0014325; Fri, 16 Aug 2013 09:48:27 +0200 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Fri, 16 Aug 2013 09:48:27 +0200 (CEST) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: Martin Thomson In-Reply-To: Message-ID: References: <520B299F.9060409@goodadvice.pages.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245: ice-ufrags of length 256 vs stun maximum username length of 512 bytes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 07:48:36 -0000 On Wed, 14 Aug 2013, Martin Thomson wrote: > On 14 August 2013 07:54, Philipp Hancke wrote: >> >> Off by one? > > Maybe. It certainly looks like an off-by-one error in the specs, > though you could technically argue that both sets of length > restrictions apply, since they are independent. After all, not all > users of the STUN username attribute are also doing ICE. Right. I'd actually hope that implementations don't send anything longer than 512 bytes. I am not so sure about the comparison on the receiving end. It's probably a good idea to mention this explicitly in 5245bis or draft-ietf-mmusic-ice-sip-sdp though. >> For ice-pwd this isn't a problem, right? > > This doesn't transit the network in STUN packets. In SDP, the maximum > size is 256 characters, but that's not a limit that other signaling > protocols need to respect. phew :-) From martin.thomson@gmail.com Fri Aug 16 09:13:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1EB11E8163 for ; Fri, 16 Aug 2013 09:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMFUcaowOtYO for ; Fri, 16 Aug 2013 09:13:04 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 40F3411E8152 for ; Fri, 16 Aug 2013 09:13:04 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so646535wes.32 for ; Fri, 16 Aug 2013 09:13:03 -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=mULmd6srFGozCbQcevHfIWfrHrFhPC2cBrDTA9XYtEE=; b=yaUqMOS+hhSVXEKySqFAMyP4x20fMzFNiWaNM1+IK/VYDYG6DGhF27e4FH4UwuoLlK 0xDqJ8z/8lXcb8WjHUAxh8Z8bBX5cF2PAR/t6dWofAUqGZNs7ZTuncQz25ByUx6MiPsM i0R5FF8u3skQLYIShjquH0EdGAn+mvH48tlVNAEkBBlTwEl8FsJ94dgrOtZlkL3s+hCN rWfiiclHK/FSVHP2QD7ap4bruTrYoWwPVoL8+bVIEQZ5MkxOPh1GHvdH934Mz+GR9F+5 cSGpjOg0WgBhwU2FIorarR94StUPPVnexN13DgRHsdreKsTxW9Mntb/se2l1LIVNr9M2 1cng== MIME-Version: 1.0 X-Received: by 10.194.109.164 with SMTP id ht4mr1661591wjb.35.1376669583427; Fri, 16 Aug 2013 09:13:03 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Fri, 16 Aug 2013 09:13:03 -0700 (PDT) In-Reply-To: References: <520B299F.9060409@goodadvice.pages.de> Date: Fri, 16 Aug 2013 09:13:03 -0700 Message-ID: From: Martin Thomson To: Philipp Hancke Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 5245: ice-ufrags of length 256 vs stun maximum username length of 512 bytes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:13:05 -0000 On 16 August 2013 00:48, Philipp Hancke wrote: > It's probably a good idea to mention this explicitly in 5245bis or > draft-ietf-mmusic-ice-sip-sdp though. Mention, or just fix. I'm guessing that this has never really been tested in practice, so fixing is probably quite feasible. From christer.holmberg@ericsson.com Mon Aug 19 06:03:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90FE11E826D for ; Mon, 19 Aug 2013 06:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.64 X-Spam-Level: X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPas4K5Mh9-k for ; Mon, 19 Aug 2013 06:03:36 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3900C11E8264 for ; Mon, 19 Aug 2013 06:03:35 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-d5-521217a6d584 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AF.61.16099.6A712125; Mon, 19 Aug 2013 15:03:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Mon, 19 Aug 2013 15:03:34 +0200 From: Christer Holmberg To: mmusic Thread-Topic: Draft new: draft-holmberg-mmusic-udptl-dtls-00 Thread-Index: Ac6c2+8uzokCW2xnSQeYLTwy0EHdvQ== Date: Mon, 19 Aug 2013 13:03:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C46787F@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_7594FB04B1934943A5C02806D1A2204B1C46787FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje5ycaEgg28buSz+7U2ymLr8MYsD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfHtZ0bBI9mKr73vGBsYv0l2MXJySAiYSBz8 tpoNwhaTuHBvPZgtJHCYUWLn7bwuRi4gewmjxIS7rexdjBwcbAIWEt3/tEFqRARkJPZu2swM YjML5Evc2vICrFdYwFzizMKjbBA1NhKbNx9nhbD1JJbv6GUBsVkEVCXu/l4G1ssr4CuxaGsj WA0j0A3fT61hgpgpLnHryXwmiNsEJJbsOc8MYYtKvHz8jxXCVpRof9rACHNDw6MjLBAzBSVO znzCMoFReBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMbLnJmbmpJcb bmIERsfBLb91dzCeOidyiFGag0VJnHeT3plAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxR l4t4PPtWr7A+Itpy05b345JHUR++uWtvjs7+tmPubJGY+vW/z6S8Wm23ZL7ZJNd9pixxs6ec eP5W2tjBKGi9kyz3R4EQkf91c4oUJ7B/0DTU6XxfpaR8fua1tK+FP12Mrx1fbvqlVIJr6aR7 Tc/yV2ZNvPRtn9NOu/IND3YZnGIoOqN2bJe/EktxRqKhFnNRcSIACbryjFwCAAA= Cc: "mmusic-chairs@tools.ietf.org" Subject: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:03:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C46787FESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, which d= efines usage of UDPTL over DTLS, in order to provide secure fax. The draft was previously submitted to DISPATCH. Based on discussions with t= he ADs and chairs, it was decided that it shall be submitted to MMUSIC (not= e that no DTLS extensions are needed). As is indicated in the draft, 3GPP has performed a study on how to provide = secure fax in the IMS, and the outcome was that secure fax shall be transpo= rted using UDPTL over DTLS. However, there is nothing "3GPP/IMS specific" about the mechanism, as= UDPTL is commonly used for fax also elsewhere. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C46787FESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have submitted a new draft, draft-holmberg-mmusic= -udptl-dtls-00, which defines usage of UDPTL over DTLS, in order to provide= secure fax.

 

The draft was previously submitted to DISPATCH. Base= d on discussions with the ADs and chairs, it was decided that it shall be s= ubmitted to MMUSIC (note that no DTLS extensions are needed).

 

As is indicated in the draft, 3GPP has performed a s= tudy on how to provide secure fax in the IMS, and the outcome was that secu= re fax shall be transported using UDPTL over

DTLS. However, there is nothing “3GPP/IMS spec= ific” about the mechanism, as UDPTL is commonly used for fax also els= ewhere.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C46787FESESSMB209erics_-- From harald@alvestrand.no Mon Aug 19 07:57:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4C11E82A9 for ; Mon, 19 Aug 2013 07:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n00dlJsLJZ08 for ; Mon, 19 Aug 2013 07:57:52 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 35E0611E8294 for ; Mon, 19 Aug 2013 07:57:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A393E39E52F for ; Mon, 19 Aug 2013 16:57:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OntN+p7-3x+V for ; Mon, 19 Aug 2013 16:57:35 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B099339E091 for ; Mon, 19 Aug 2013 16:57:35 +0200 (CEST) Message-ID: <5212325F.3040503@alvestrand.no> Date: Mon, 19 Aug 2013 16:57:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> <520A2564.7090404@alvestrand.no> <520D0CCF.8020401@alum.mit.edu> In-Reply-To: <520D0CCF.8020401@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 14:57:57 -0000 On 08/15/2013 07:15 PM, Paul Kyzivat wrote: > I went through this version, with an eye to alignment with the Unified > Plan. I have a number of comments, some nits, some not: Thanks for doing this quickly! I've incorporated these changes (with some rewording, as always). I'll give this a few more days to stew, and then emit a new version. > > General: > > The Unified Plan says a single m-line describes one media source. It > allows this source to consist of multiple RTP Streams (identified by > SSRC). And it allows associating RTP Streams with m-lines multiple > ways, not just by SSRC. > > This msid draft hasn't fully incorporated those concepts. It still > seems to assume that a media source corresponds to a single SSRC. It > would be helpful to have a section discussion the process of > associating SSRCs to MedisStreamTracks. (And I think this needs to > include the possibility that an SSRC might be moved from one > MediaStreamTrack to another.) I tried replacing every occurence of SSRC with m-line, except where that didn't make sense (and in Appendix B, of course). Please point at the text where I missed, if it's not covered below! > > Section 2: > > The identifier is a string of ASCII characters chosen from 0-9, a-z, > A-Z and - (hyphen), consisting of between 1 and 64 characters. It > MUST be unique among the identifier values used in the same SDP > session. It is RECOMMENDED that is generated using a random-number > generator. > ... > There may be multiple msid attributes on a single m-line. There may > also be multiple m-lines that have the same value for identifier and > application data. > > What does uniqueness mean in this context, since it can be used > multiple times, with the same or different m-lines? I *think* you mean > that a given identifier value is associated with a single MediaStream > for the duration of the SDP session. Yes, but I can't write that in section 2, since MediaStreams aren't introduced until section 4. The meaning of "uniqueness" has to be defined by the msid-semantic, I think - should I add a sentence saying that this is so? (It's tempting to declare that msid is useless for anything except WebRTC. But the Paris (?) IETF meeting told me to write a generic mechanism with a WebRTC specialization, so that's how it's written.) > > Also, msid attributes aren't "on" an m-line. I think it would be > clearer to say "Multiple msid attributes may be associated with a > single m-line." But with the Unified Plan this isn't true. Sorry? I think it's legal to say m=video a=msid: 1234 567 a=msid: ABCD EFG This would mean (for the WMS context) that the same media content is present in both MediaStream 1234 and MediaStream ABCD, with MediaStreamTrack ids 567 and EFG, respectively. > > Also, I find the use of "identifier" and "token" very confusing. It is > hard to keep track of the semantics intended for those things. It > would be easier to follow if some more specific terms were used. For > example, "mediastream-id" instead of "identifier" in the msid and > msid-semantics attributes, and "semantics" instead of "token" in > msid-semantics attribute. ("semantics" is what is used in 3388 and 5576.) You're talking about the ABNF in sections 2 and 3 now, right? We could use more meaningful names for the tokens, but it's just another level of indirection - generally, I don't find that specs become much more readable by repeated productions of the form name1 = name2 unless we have to refer to the tokens by name from surrounding text. But your mileage may vary. > > Section 4: > > o When a description is updated to have more SSRCs with the same > msid value, but different appdata values, the recipient can signal > to its application that new MediaStreamTracks have been added to > the media stream. > > Is SSRC relevant any longer? s/SSRCs/m-lines/ ??? Yep, I missed that (multiple misses in that section). Will update. > > Also in Section 4: > > In addition to signaling that the track is closed when it disappears > from the SDP, the track will also be signaled as being closed when > all associated SSRCs have disappeared by the rules of [RFC3550] > section 6.3.4 (BYE packet received) and 6.3.5 (timeout). > > Here we can't avoid talking about SSRCs. But maybe more is needed > about what SSRCs are associated with a particular m-line & msid value? Since this is in section 4 (WebRTC), I can happily point that problem off to unified-plan or its successors. > > Section 4.1: > > Pre-WebRTC entities will not send msid. This means that there will > be some incoming RTP packets with SSRCs where the recipient does not > know about a corresponding MediaStream id. > > In the context of the Unified Plan I think this could be stated better: > > There may be some incoming RTP packets that the recipient cannot > associate with a MediaStreamTrack. Rephrased, not quite like this. > > Also: > > o An msid-semantic:WMS attribute is present. In this case, the > session is WebRTC compatible, and the newly arrived SSRCs are > either caused by a bug or by timing skew between the arrival of > ... > > I suggest: > > o An msid-semantic:WMS attribute is present. In this case, the > session is WebRTC compatible, and the unassociated packets are > either caused by a bug or by timing skew between the arrival of Done. > ... > > Thanks, > Paul > > > On 8/13/13 2:24 PM, Harald Alvestrand wrote: >> The auto-poster doesn't seem to want to tell mmusic about this.... >> >> this is updated according to Unified-plan. Since it was only 1 day >> before the old version had expired, the proofreading might be a little >> light - please point out places where I had missed changing "SSRC" to >> "m-line"! >> >> I retained some description of the old mechanism (using a=ssrc) in an >> appendix. Please state opinions on whether this should be retained as >> informative, promoted to normative, or removed entirely in the next >> version. >> >> Hope this informs! >> >> Harald >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-ietf-mmusic-msid-01.txt >> Date: Tue, 13 Aug 2013 05:13:42 -0700 >> From: internet-drafts@ietf.org >> To: Harald T. Alvestrand , Harald Alvestrand >> >> >> >> >> A new version of I-D, draft-ietf-mmusic-msid-01.txt >> has been successfully submitted by Harald Alvestrand and posted to the >> IETF repository. >> >> Filename: draft-ietf-mmusic-msid >> Revision: 01 >> Title: Cross Session Stream Identification in the Session >> Description Protocol >> Creation date: 2013-08-13 >> Group: mmusic >> Number of pages: 14 >> URL:http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt >> Status:http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid >> Htmlized:http://tools.ietf.org/html/draft-ietf-mmusic-msid-01 >> Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01 >> >> Abstract: >> This document specifies a 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 >> ismmusic@ietf.org. >> >> >> >> >> >> 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 harald@alvestrand.no Mon Aug 19 08:02:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4131C21F9C53 for ; Mon, 19 Aug 2013 08:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox-rN3aKl2VK for ; Mon, 19 Aug 2013 08:02:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EAFE721F9C46 for ; Mon, 19 Aug 2013 08:02:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3D4FE39E2C0 for ; Mon, 19 Aug 2013 17:02:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jPTUb8695B3 for ; Mon, 19 Aug 2013 17:02:26 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8517E39E091 for ; Mon, 19 Aug 2013 17:02:26 +0200 (CEST) Message-ID: <52123382.9060005@alvestrand.no> Date: Mon, 19 Aug 2013 17:02:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C44E4EE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C44E4EE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 15:02:44 -0000 On 08/16/2013 09:17 AM, Christer Holmberg wrote: > Hi, > >>> It has been indicated that POFs (partial offers) and PANs (partial answers) form a stand-alone mechanism, instead of being an extension of RFC3264. >> uh, I don't think so. THey seem sot be an optional extension to 3264 > Well, that is not what was indicated during the meeting (if we don't count Hadriel :)... > > Anyway, I guess that is part of the solution discussions. But, whatever it's an extension or not, I don't think it changes the fact that there will interactions between POF/PANs and 3264 O/As. > My impression is that we're defining a new mechanism that contains 3264-style O/A *and* POF/PAN. Applications will then either use that mechanism or use 3264 only (analogous, kind of, to applications either using RTP/AVP or RTP/AVPF). So I see no "interaction" as such, but the semantics of the new mechanism have to be defined, and, if we intend it for use in SIP, how to negotiate its use has to be defined. From christer.holmberg@ericsson.com Mon Aug 19 09:37:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63AD11E812F for ; Mon, 19 Aug 2013 09:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAsjAIb0Sw2O for ; Mon, 19 Aug 2013 09:37:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F380411E810A for ; Mon, 19 Aug 2013 09:37:39 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-06-521249d0023d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C5.1E.22048.0D942125; Mon, 19 Aug 2013 18:37:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Mon, 19 Aug 2013 18:37:36 +0200 From: Christer Holmberg To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers Thread-Index: Ac6SwAaH+8B2wVyxQFSEGu6rKTxpcQFp3RKAAHouH+AAowm4AAAHVr2w Date: Mon, 19 Aug 2013 16:37:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C46CAD5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C44E4EE@ESESSMB209.ericsson.se> <52123382.9060005@alvestrand.no> In-Reply-To: <52123382.9060005@alvestrand.no> Accept-Language: en-US Content-Language: fi-FI 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+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje5FT6Egg2OXOS2O9XWxWUxd/pjF gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY9OcNW8FXzopXZzcyNjC+Yu9i5OCQEDCR eNRR0sXICWSKSVy4t56ti5GLQ0jgMKPE7MbnUM4SRokHk+8wgzSwCVhIdP/TBmkQEQiWWP5p OxOILSzgIzH123JGkBIRAV+J81NqIErcJM4cfs4MYrMIqEp0rJrOCGLzApX8m/OAFWL8d0aJ LQ072EESnAK6EmtaFoPNZAQ66PupNWA2s4C4xIeD15khDhWQWLLnPJQtKvHy8T9WCFtJ4seG SywQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmT Xm6+iREYCQe3/DbYwbjpvtghRmkOFiVx3s16ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MK7Xc+dbniGpZN3zodKwzmz9AfHKT6Grs5s+G+Ruq7034XDKmVazqK2N+1Q3tzzxvjxjcX7n 009tGavvrlPWWjKt7aj+7NgLbw/t7/gT113LJpa3RdTcLfBqR8XuDpGKU9PfXo9hL25/nX5W qHWC3+xnPySEq04k5OVUb1J92He95bToDtXLukosxRmJhlrMRcWJAITgOP1SAgAA Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:37:49 -0000 Hi Harald, >>>> It has been indicated that POFs (partial offers) and PANs (partial ans= wers) form a stand-alone mechanism, instead of being an extension of RFC326= 4. >>> uh, I don't think so. THey seem sot be an optional extension to 3264 >> Well, that is not what was indicated during the meeting (if we don't cou= nt Hadriel :)... >> >> Anyway, I guess that is part of the solution discussions. But, whatever = it's an extension or not, I don't think it changes the fact that there will= interactions between POF/PANs and 3264 O/As. >> >> My impression is that we're defining a new mechanism that contains 3264-= style O/A *and* POF/PAN. > > Applications will then either use that mechanism or use 3264 only (analog= ous, kind of, to applications either using RTP/AVP or RTP/AVPF). > > So I see no "interaction" as such, but the semantics of the new mechanism= have to be defined, and, if we intend it for use in SIP, how to negotiate = its use has to be defined. The problem with SIP is that, in certain situations (e.g. in a (re-)INVITE = request or response), you are REQUIRED to send an Offer. Now, whether that = Offer must be a 3264 Offer, or if some "type" of Offer is also allowed, I d= on't know :) Regards, Christer From dwing@cisco.com Mon Aug 19 10:42:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDB711E82B1 for ; Mon, 19 Aug 2013 10:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.377 X-Spam-Level: X-Spam-Status: No, score=-110.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDo3s66tOxcG for ; Mon, 19 Aug 2013 10:42:50 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1138E11E8135 for ; Mon, 19 Aug 2013 10:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1657; q=dns/txt; s=iport; t=1376934169; x=1378143769; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rXiV7F7Zrf4aXD302IxSUsO5GMVKY7sFrv4/NjYfb+o=; b=S+SDzv1wCPPBD6jYyYbTV/2lsAXpEpo8o8swQgQ47gzaLhcGfGvMsQO9 e2cLfOA6QdnlHIeakZG7Nh0bPWgb0Bqfg6G2WAvZWRH/cAPDeR/kJzpdn bdbNHyJSbo912Tx9GMm05AMkrFQyl+t3INaKnYAiylxXqYO/LIqXya+MP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJ5WElKrRDoH/2dsb2JhbABagwc1wAOBIxZ0giQBAQEDAQEBAWsLBQsLRicwBhOICgUNthwEjzB5MweDG3cDiS2KYINXhimLLIM8HIEu X-IronPort-AV: E=Sophos;i="4.89,914,1367971200"; d="scan'208";a="86247766" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 19 Aug 2013 17:42:47 +0000 Received: from [10.21.102.166] ([10.21.102.166]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7JHgl0l013331; Mon, 19 Aug 2013 17:42:47 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C46787F@ESESSMB209.ericsson.se> Date: Mon, 19 Aug 2013 10:42:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C46787F@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) Cc: "mmusic-chairs@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:42:54 -0000 On Aug 19, 2013, at 6:03 AM, Christer Holmberg = wrote: > Hi, > =20 > We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, = which defines usage of UDPTL over DTLS, in order to provide secure fax. > =20 > The draft was previously submitted to DISPATCH. Based on discussions = with the ADs and chairs, it was decided that it shall be submitted to = MMUSIC (note that no DTLS extensions are needed). > =20 > As is indicated in the draft, 3GPP has performed a study on how to = provide secure fax in the IMS, and the outcome was that secure fax shall = be transported using UDPTL over > DTLS. Got a pointer to that study? Seems easier to carry UDPTL over RTP, = which would allow the RTP to be secured using SRTP (and thus the UDPTL = would be secured using SRTP). There is a spec floating around to do = exactly that (carry fax over RTP so that SRTP can secure it). Advantage = of using SRTP to secure fax is it separates the keying mechanism from = security, so that Security Descriptions / MIKEY / DTLS-SRTP / = whatever-is-invented-in-2020 will work just as effectively for voice as = for fax. And also that upgrading from a voice call to a "fax" call has = no additional complexities due to security ("please press START to begin = the fax transmission"). -d > However, there is nothing =933GPP/IMS specific=94 about the mechanism, = as UDPTL is commonly used for fax also elsewhere. > =20 > Regards, > =20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Mon Aug 19 12:28:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E3811E82B8 for ; Mon, 19 Aug 2013 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sICtIvwOYPHh for ; Mon, 19 Aug 2013 12:28:33 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E09A911E82CB for ; Mon, 19 Aug 2013 12:28:30 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id Ei0Z1m0031ap0As51jUW87; Mon, 19 Aug 2013 19:28:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id EjUV1m01Y3ZTu2S3ijUVac; Mon, 19 Aug 2013 19:28:30 +0000 Message-ID: <521271DD.9010701@alum.mit.edu> Date: Mon, 19 Aug 2013 15:28:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <20130813121342.12135.74240.idtracker@ietfa.amsl.com> <520A2564.7090404@alvestrand.no> <520D0CCF.8020401@alum.mit.edu> <5212325F.3040503@alvestrand.no> In-Reply-To: <5212325F.3040503@alvestrand.no> 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=q20121106; t=1376940510; bh=q9pTlPw1gg829Mo748pOTkECV6IXyI/0y2fr3HOl7p0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dYwy/EUJPH4OYs7r3eBt0xKyAqoS3LXC5DXy1xVXyjh7xi0eAK1DQWj6FtwokzU1S oqzV95YoyYC/kw12u2sZsxMrHo0AMDoaaBrErHuL+a0+K19Ze8NILOS06kzRM0GVbH r4L+ZbDwxOE+mIWNRe6PTKbG0jHWb6VVmXsNs5ujQUQr0bgai50CqHbT951DTCoihL /a3jUBbK7AAU1s24mJkFVa45FqXadqRvk06JOPokeku8re3APDggeA4q3vknpw+Ez0 Y7szoFRRpL2wvBVWcjP8AeLagt5Cs4O6L5g0mhIb1ARhZACiff9F3tZf0xFyGRCcwy R78MUFQi6u+tw== Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:28:38 -0000 inline On 8/19/13 10:57 AM, Harald Alvestrand wrote: > On 08/15/2013 07:15 PM, Paul Kyzivat wrote: >> I went through this version, with an eye to alignment with the Unified >> Plan. I have a number of comments, some nits, some not: > > Thanks for doing this quickly! > > I've incorporated these changes (with some rewording, as always). I'll > give this a few more days to stew, and then emit a new version. > >> >> General: >> >> The Unified Plan says a single m-line describes one media source. It >> allows this source to consist of multiple RTP Streams (identified by >> SSRC). And it allows associating RTP Streams with m-lines multiple >> ways, not just by SSRC. >> >> This msid draft hasn't fully incorporated those concepts. It still >> seems to assume that a media source corresponds to a single SSRC. It >> would be helpful to have a section discussion the process of >> associating SSRCs to MedisStreamTracks. (And I think this needs to >> include the possibility that an SSRC might be moved from one >> MediaStreamTrack to another.) > > I tried replacing every occurence of SSRC with m-line, except where that > didn't make sense (and in Appendix B, of course). Please point at the > text where I missed, if it's not covered below! I didn't have anything specific in mind other than what is below. But I just got the feeling when reading it that it was still oriented towards the old model. >> Section 2: >> >> The identifier is a string of ASCII characters chosen from 0-9, a-z, >> A-Z and - (hyphen), consisting of between 1 and 64 characters. It >> MUST be unique among the identifier values used in the same SDP >> session. It is RECOMMENDED that is generated using a random-number >> generator. >> ... >> There may be multiple msid attributes on a single m-line. There may >> also be multiple m-lines that have the same value for identifier and >> application data. >> >> What does uniqueness mean in this context, since it can be used >> multiple times, with the same or different m-lines? I *think* you mean >> that a given identifier value is associated with a single MediaStream >> for the duration of the SDP session. > > Yes, but I can't write that in section 2, since MediaStreams aren't > introduced until section 4. The meaning of "uniqueness" has to be > defined by the msid-semantic, I think - should I add a sentence saying > that this is so? In part it is just nit picking by me. It might be that you can just not say this at all, at least here. In the context in which the statement is made it is hard to see what sort of uniqueness is being required. > (It's tempting to declare that msid is useless for anything except > WebRTC. But the Paris (?) IETF meeting told me to write a generic > mechanism with a WebRTC specialization, so that's how it's written.) IIUC, MediaStreamTrack ought to be synonymous with a CLUE capture-encoding. But I don't think we have anything in CLUE that corresponds to a MediaStream. I don't understand MediaStream very well, but perhaps it is indeed unique to WebRTC. The taxonomy draft is perhaps the right reference here. >> Also, msid attributes aren't "on" an m-line. I think it would be >> clearer to say "Multiple msid attributes may be associated with a >> single m-line." But with the Unified Plan this isn't true. > > Sorry? I'm picking at the meaning of words. To me "on" an m-line means that it is present within the characters that comprise the m-line itself. No "attribute" works that way. I presume you are using "on" as synonymous with "attached to", or "associated with". So I was simply suggesting being more explicit. > I think it's legal to say > > m=video > a=msid: 1234 567 > a=msid: ABCD EFG > > This would mean (for the WMS context) that the same media content is > present in both MediaStream 1234 and MediaStream ABCD, with > MediaStreamTrack ids 567 and EFG, respectively. I wasn't talking about any of that. Its a WebRTC issue whether the same logical stream of packets can be part of multiple MediaStreams or MediaStreamTracks. So I'll take your word for it. >> Also, I find the use of "identifier" and "token" very confusing. It is >> hard to keep track of the semantics intended for those things. It >> would be easier to follow if some more specific terms were used. For >> example, "mediastream-id" instead of "identifier" in the msid and >> msid-semantics attributes, and "semantics" instead of "token" in >> msid-semantics attribute. ("semantics" is what is used in 3388 and 5576.) > > You're talking about the ABNF in sections 2 and 3 now, right? Yes. > We could use more meaningful names for the tokens, but it's just another > level of indirection - generally, I don't find that specs become much > more readable by repeated productions of the form > > name1 = name2 > > unless we have to refer to the tokens by name from surrounding text. It words two ways: - the text referring back to the elements from the ABNF - when I look at the ABNF, understanding what concept in the text this element refers to. When reading, I encountered both of those problems. Eventually I can figure it out by going through an exercise of "what could this possibly mean". But it would be nice if it was clearer Thanks, Paul > But your mileage may vary. I realize this is to some extent a matter of taste. Personally, I find that ABNF non-terminals are cheap, so I am happy to use more of them to increase clarity. In particular I'm inclined to ensure that there is a well-named non-terminal for every element that needs to be referenced from the text. Thanks, Paul >> Section 4: >> >> o When a description is updated to have more SSRCs with the same >> msid value, but different appdata values, the recipient can signal >> to its application that new MediaStreamTracks have been added to >> the media stream. >> >> Is SSRC relevant any longer? s/SSRCs/m-lines/ ??? > > Yep, I missed that (multiple misses in that section). Will update. > >> >> Also in Section 4: >> >> In addition to signaling that the track is closed when it disappears >> from the SDP, the track will also be signaled as being closed when >> all associated SSRCs have disappeared by the rules of [RFC3550] >> section 6.3.4 (BYE packet received) and 6.3.5 (timeout). >> >> Here we can't avoid talking about SSRCs. But maybe more is needed >> about what SSRCs are associated with a particular m-line & msid value? > > Since this is in section 4 (WebRTC), I can happily point that problem > off to unified-plan or its successors. >> >> Section 4.1: >> >> Pre-WebRTC entities will not send msid. This means that there will >> be some incoming RTP packets with SSRCs where the recipient does not >> know about a corresponding MediaStream id. >> >> In the context of the Unified Plan I think this could be stated better: >> >> There may be some incoming RTP packets that the recipient cannot >> associate with a MediaStreamTrack. > > Rephrased, not quite like this. > >> >> Also: >> >> o An msid-semantic:WMS attribute is present. In this case, the >> session is WebRTC compatible, and the newly arrived SSRCs are >> either caused by a bug or by timing skew between the arrival of >> ... >> >> I suggest: >> >> o An msid-semantic:WMS attribute is present. In this case, the >> session is WebRTC compatible, and the unassociated packets are >> either caused by a bug or by timing skew between the arrival of > > Done. > >> ... >> >> Thanks, >> Paul >> >> >> On 8/13/13 2:24 PM, Harald Alvestrand wrote: >>> The auto-poster doesn't seem to want to tell mmusic about this.... >>> >>> this is updated according to Unified-plan. Since it was only 1 day >>> before the old version had expired, the proofreading might be a little >>> light - please point out places where I had missed changing "SSRC" to >>> "m-line"! >>> >>> I retained some description of the old mechanism (using a=ssrc) in an >>> appendix. Please state opinions on whether this should be retained as >>> informative, promoted to normative, or removed entirely in the next >>> version. >>> >>> Hope this informs! >>> >>> Harald >>> >>> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-ietf-mmusic-msid-01.txt >>> Date: Tue, 13 Aug 2013 05:13:42 -0700 >>> From: internet-drafts@ietf.org >>> To: Harald T. Alvestrand , Harald Alvestrand >>> >>> >>> >>> >>> A new version of I-D, draft-ietf-mmusic-msid-01.txt >>> has been successfully submitted by Harald Alvestrand and posted to the >>> IETF repository. >>> >>> Filename: draft-ietf-mmusic-msid >>> Revision: 01 >>> Title: Cross Session Stream Identification in the Session >>> Description Protocol >>> Creation date: 2013-08-13 >>> Group: mmusic >>> Number of pages: 14 >>> URL:http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt >>> Status:http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid >>> Htmlized:http://tools.ietf.org/html/draft-ietf-mmusic-msid-01 >>> Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01 >>> >>> Abstract: >>> This document specifies a 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 >>> ismmusic@ietf.org. >>> >>> >>> >>> >>> >>> 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 > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Tue Aug 20 02:42:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5B811E81F7 for ; Tue, 20 Aug 2013 02:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mansQXoR5xgW for ; Tue, 20 Aug 2013 02:42:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDFF11E8128 for ; Tue, 20 Aug 2013 02:42:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-44-52133a018e04 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A0.0D.16099.10A33125; Tue, 20 Aug 2013 11:42:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Tue, 20 Aug 2013 11:42:25 +0200 From: Christer Holmberg To: Dan Wing Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 Thread-Index: Ac6c2+8uzokCW2xnSQeYLTwy0EHdvQAFtGOAACWIkpA= Date: Tue, 20 Aug 2013 09:42:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C46D35E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C46787F@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvjS6TlXCQwbMLPBYXrz1kspi6/DGL A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxaHM3Y8F1gYp/X2YxNjBu4e1i5OSQEDCR eDXtLTuELSZx4d56NhBbSOAwo8SVP05djFxA9hJGieev+5i6GDk42AQsJLr/aYPUiAjISdyd P4EZxGYWkJGYcbaRCcQWFnCRmHBrHztEjatE76bVrBC2lcT+g+/YQMawCKhKLD9pAhLmFfCV WHxyCjPEqgZGifnf7jOCJDgFbCXabxwAu4cR6Lbvp9YwQewSl7j1ZD4TxM0CEkv2nGeGsEUl Xj7+xwphK0q0P21ghKjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZhaRl ASPLKkb23MTMnPRyw02MwAg5uOW37g7GU+dEDjFKc7AoifNu0jsTKCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoHRtfiJ0rZnR3rETl8oZGnuaGhfHXro/u43icmLp3T/Xn2xcxKXfo7wo3cX 3MSnx4lPKZ31aesv4Rk5zj56mx5UGIZtY/hXmJ2Z8fbdxrK02vWKLyd9VOjWnNdko/lHZvpk fnUjldUn5tp2piwv8K1d6vHN6LYs08OUB4xvvdJ3qoTHyzK5uy1XYinOSDTUYi4qTgQAAjl/ 214CAAA= Cc: mmusic Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 09:42:33 -0000 Hi Dan, I'll get back to your comments later, but just a question for clarification= : When you say "UDPTL over RTP", you are NOT referring to RFC 4612, right?=20 Or, did you mean to say "fax over RTP"? :) Regards, Christer -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: 19. elokuuta 2013 20:43 To: Christer Holmberg Cc: mmusic; mmusic-chairs@tools.ietf.org Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 On Aug 19, 2013, at 6:03 AM, Christer Holmberg wrote: > Hi, > =20 > We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, which= defines usage of UDPTL over DTLS, in order to provide secure fax. > =20 > The draft was previously submitted to DISPATCH. Based on discussions with= the ADs and chairs, it was decided that it shall be submitted to MMUSIC (n= ote that no DTLS extensions are needed). > =20 > As is indicated in the draft, 3GPP has performed a study on how to=20 > provide secure fax in the IMS, and the outcome was that secure fax shall = be transported using UDPTL over DTLS. Got a pointer to that study? Seems easier to carry UDPTL over RTP, which w= ould allow the RTP to be secured using SRTP (and thus the UDPTL would be se= cured using SRTP). There is a spec floating around to do exactly that (car= ry fax over RTP so that SRTP can secure it). Advantage of using SRTP to se= cure fax is it separates the keying mechanism from security, so that Securi= ty Descriptions / MIKEY / DTLS-SRTP / whatever-is-invented-in-2020 will wor= k just as effectively for voice as for fax. And also that upgrading from a= voice call to a "fax" call has no additional complexities due to security = ("please press START to begin the fax transmission"). -d > However, there is nothing "3GPP/IMS specific" about the mechanism, as UDP= TL is commonly used for fax also elsewhere. > =20 > Regards, > =20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From dwing@cisco.com Tue Aug 20 08:34:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9347711E8226 for ; Tue, 20 Aug 2013 08:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.488 X-Spam-Level: X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byHnnWwSvQqI for ; Tue, 20 Aug 2013 08:33:57 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 346D211E8100 for ; Tue, 20 Aug 2013 08:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2610; q=dns/txt; s=iport; t=1377012834; x=1378222434; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=leAY3GjjSwgADDvYt5irdjdLN64fF3X3V2DiyZPfDLQ=; b=FDN2xZ4O+p3jn5FyESSlEoFHY56T9mpYPWHhhX3GjfPnNErBjylkjiEj DeAO1LNhLqsKLrs3ErWJXoAZ/NtNYNv8GuVc0Qw/4sWLd/ZL1tL7VvfGr 0mkQ6LBpdIJxTVCez8PfLQpSOo02cG7t67Gb+sF8RjvEZE2GIKr5IKHuf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAD6ME1KrRDoH/2dsb2JhbABagwU1wCqBJBZ0giQBAQEDAQEBATc0CwUHBAsRBAEBAScHJx8JCAYTiAoFDa01BI8peTMHBoMVeQOJLYpgg1iGKYstgzwcgS4 X-IronPort-AV: E=Sophos;i="4.89,921,1367971200"; d="scan'208";a="87057490" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 20 Aug 2013 15:33:40 +0000 Received: from [10.21.102.166] ([10.21.102.166]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7KFXd4r009247; Tue, 20 Aug 2013 15:33:39 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C46D35E@ESESSMB209.ericsson.se> Date: Tue, 20 Aug 2013 08:33:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3981BAC4-E7ED-4A03-A83F-3E95FF75DCAC@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C46787F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C46D35E@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) Cc: mmusic Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 15:34:21 -0000 On Aug 20, 2013, at 2:42 AM, Christer Holmberg = wrote: > Hi Dan, >=20 > I'll get back to your comments later, but just a question for = clarification: >=20 > When you say "UDPTL over RTP", you are NOT referring to RFC 4612, = right?=20 I believe I am. However, I thought there was an ITU specification for = T.38 over RTP -- perhaps there is just that IETF specification. Are you = not a fan of RFC4612? >=20 > Or, did you mean to say "fax over RTP"? :) Maybe you could educate me on the difference. My fax knowledge has = faded with time. -d >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: 19. elokuuta 2013 20:43 > To: Christer Holmberg > Cc: mmusic; mmusic-chairs@tools.ietf.org > Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 >=20 >=20 > On Aug 19, 2013, at 6:03 AM, Christer Holmberg = wrote: >=20 >> Hi, >>=20 >> We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, = which defines usage of UDPTL over DTLS, in order to provide secure fax. >>=20 >> The draft was previously submitted to DISPATCH. Based on discussions = with the ADs and chairs, it was decided that it shall be submitted to = MMUSIC (note that no DTLS extensions are needed). >>=20 >> As is indicated in the draft, 3GPP has performed a study on how to=20 >> provide secure fax in the IMS, and the outcome was that secure fax = shall be transported using UDPTL over DTLS. >=20 > Got a pointer to that study? Seems easier to carry UDPTL over RTP, = which would allow the RTP to be secured using SRTP (and thus the UDPTL = would be secured using SRTP). There is a spec floating around to do = exactly that (carry fax over RTP so that SRTP can secure it). Advantage = of using SRTP to secure fax is it separates the keying mechanism from = security, so that Security Descriptions / MIKEY / DTLS-SRTP / = whatever-is-invented-in-2020 will work just as effectively for voice as = for fax. And also that upgrading from a voice call to a "fax" call has = no additional complexities due to security ("please press START to begin = the fax transmission"). >=20 > -d >=20 >=20 >> However, there is nothing "3GPP/IMS specific" about the mechanism, as = UDPTL is commonly used for fax also elsewhere. >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 From christer.holmberg@ericsson.com Tue Aug 20 09:32:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C13711E8242 for ; Tue, 20 Aug 2013 09:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS0yIZLM+q7r for ; Tue, 20 Aug 2013 09:32:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 86F3C11E8122 for ; Tue, 20 Aug 2013 09:32:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-3b-52139a1a064c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A7.95.16099.A1A93125; Tue, 20 Aug 2013 18:32:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Tue, 20 Aug 2013 18:32:26 +0200 From: Christer Holmberg To: Dan Wing Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 Thread-Index: Ac6c2+8uzokCW2xnSQeYLTwy0EHdvQAFtGOAACWIkpAACD9+gAAFYQca Date: Tue, 20 Aug 2013 16:32:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C471B66@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C46787F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C46D35E@ESESSMB209.ericsson.se>, <3981BAC4-E7ED-4A03-A83F-3E95FF75DCAC@cisco.com> In-Reply-To: <3981BAC4-E7ED-4A03-A83F-3E95FF75DCAC@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvja7ULOEggzctShYXrz1kspi6/DGL A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx9tNMloLZYhWbj/xnb2A8L9jFyMkhIWAi 8fHiH2YIW0ziwr31bF2MXBxCAocZJTYdusEM4SwBco5sAspwcLAJWEh0/9MGaRARkJO4O38C WDOzgIzEjLONTCC2sICLxIRb+9ghalwlejetZoWw3SRe3FwKFmcRUJVYvvIwWC+vgK/EuTU/ 2CF2fWWU+Hx5EQtIglPAVuLHo31gNiPQdd9PrWGCWCYucevJfCaIqwUkluw5D/WBqMTLx/9Y IWxFiY+v9jFC1OtILNj9iQ3C1pZYtvA11GJBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRUj e25iZk56ueEmRmCUHNzyW3cH46lzIocYpTlYlMR5N+mdCRQSSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXA6OFqteanhB/rOq5LNz+JL1n+fKuCaq91cIBrcZ2R4hb3DM6zvlfYbB6Ifj4uvfBF Sfhq9cO6AdZijCESRfGcB97MOKSZv/FL/rbDMQtKnq13+3nqGmNj2KxKtbtNrBzXPXvmn1t4 dnGx+HNpN0b7sunLHhdlltXv/Sh06nGR1OcMloPr1NRYlViKMxINtZiLihMB5cwtaWACAAA= Cc: mmusic Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 16:32:33 -0000 Hi Dan, >> I'll get back to your comments later, but just a question for clarificat= ion: >> >> When you say "UDPTL over RTP", you are NOT referring to RFC 4612, right? > > I believe I am. However, I thought there was an ITU specification for T.= 38 over RTP -- perhaps there is just that IETF specification. =20 The latest version of T.38 also specifies the usage of T.38 over RTP. =20 RFC 4612 defines the new MIME type and fmtp attribute values, also used in = T.38, but refers to T.38 for the fax mechanism itself. > Are you not a fan of RFC4612? I'm a fan of Kelly Clarkson ;) >> Or, did you mean to say "fax over RTP"? :) > > Maybe you could educate me on the difference. My fax knowledge has faded= with time. When you use RTP, you don't use UDPTL. The UDPTL layer is "replaced" by the= RTP layer, and the fax stuff is transported as an RTP payload type. Regards, Christer > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 19. elokuuta 2013 20:43 > To: Christer Holmberg > Cc: mmusic; mmusic-chairs@tools.ietf.org > Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 > > > On Aug 19, 2013, at 6:03 AM, Christer Holmberg wrote: > >> Hi, >> >> We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, whic= h defines usage of UDPTL over DTLS, in order to provide secure fax. >> >> The draft was previously submitted to DISPATCH. Based on discussions wit= h the ADs and chairs, it was decided that it shall be submitted to MMUSIC (= note that no DTLS extensions are needed). >> >> As is indicated in the draft, 3GPP has performed a study on how to >> provide secure fax in the IMS, and the outcome was that secure fax shall= be transported using UDPTL over DTLS. > > Got a pointer to that study? Seems easier to carry UDPTL over RTP, which= would allow the RTP to be secured using SRTP (and thus the UDPTL would be = secured using SRTP). There is a spec floating around to do exactly that (c= arry fax over RTP so that SRTP can secure it). Advantage of using SRTP to = secure fax is it separates the keying mechanism from security, so that Secu= rity Descriptions / MIKEY / DTLS-SRTP / whatever-is-invented-in-2020 will w= ork just as effectively for voice as for fax. And also that upgrading from= a voice call to a "fax" call has no additional complexities due to securit= y ("please press START to begin the fax transmission"). > > -d > > >> However, there is nothing "3GPP/IMS specific" about the mechanism, as UD= PTL is commonly used for fax also elsewhere. >> >> Regards, >> >> Christer >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >= From pkyzivat@alum.mit.edu Tue Aug 20 14:50:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC80F11E82EE for ; Tue, 20 Aug 2013 14:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.356 X-Spam-Level: X-Spam-Status: No, score=-0.356 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g4ZT+YiDMf2 for ; Tue, 20 Aug 2013 14:50:36 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id A009011E82D7 for ; Tue, 20 Aug 2013 14:50:34 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta08.westchester.pa.mail.comcast.net with comcast id F0tN1m0010cZkys589qYWJ; Tue, 20 Aug 2013 21:50:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id F9qY1m00a3ZTu2S3W9qYRF; Tue, 20 Aug 2013 21:50:32 +0000 Message-ID: <5213E4A6.3010704@alum.mit.edu> Date: Tue, 20 Aug 2013 17:50:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C44E693@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C44E693@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=q20121106; t=1377035432; bh=inpSl3wWlMSp+uWLL5V8I/ENdqovYPFOXi9nkuzxXH8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=V8kdJU1BFdmQPZfsU+FKNE6iOjLbQHpqXyM7ysoJVU+9geMKmNBEZTjgWKlBUBSM+ ILqmLIyTGZHFvUpqD4vvhw6cgfPNEWARo4d0CeTB8Xo3SIrL/CcCRrlPO8Tj+ttbn/ 9dqJbHcyTJn4AGDJkEhcvGC9Hk4BzBzxPOfhaJM5pOGIxdpexRYEhd3g8e4NZQNlaI ES+6nfwoWBLKp/mbah9NVK29ATWfP/y9R+cCyQw0r8pm71M27LQjtpPKxn8nKFcoM6 85VP9hcM2jP3RpP+Jewq+KJqKvUdm7AzXJ+Wp1ANzl4c+EeczpbwCcFumbG3bzE6CX CuD3Bf28UGOzA== Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 21:50:42 -0000 On 8/16/13 3:35 AM, Christer Holmberg wrote: > MAYBE we could restrict usage of POF/PANs, and say that they MUST NOT be used to change session level information... I was assuming it was obvious that this must not be the case. The POFs and PANs (AFAIK) only contain the media sections they intend to change, so they don't contain the session level stuff. If you change session level stuff, then you should need a real offer. Or is somebody suggesting to analyze the changes, and discover that some session level things don't apply to all media sections (e.g., because the media section overrides them, or they just aren't pertinent for that kind of media) and so you can send a POF that includes just the session level stuff and the media sections that are affected. ??? I don't think much of that. Thanks, Paul From christer.holmberg@ericsson.com Tue Aug 20 23:19:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D67311E81BB for ; Tue, 20 Aug 2013 23:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[AWL=-1.597, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvqEvRYElEkN for ; Tue, 20 Aug 2013 23:19:39 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8C25111E8165 for ; Tue, 20 Aug 2013 23:19:35 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-80-52145bf5e0a8 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C2.05.25272.6FB54125; Wed, 21 Aug 2013 08:19:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Wed, 21 Aug 2013 08:19:33 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] UP: Can a partial offer be a full offer? Thread-Index: AQHOke7vCbCwhSX1mkyx6wsRumrcBZmGnR2AgAAyiAqADNsBAIAD1rVwgAcX0wCAAK8PIA== Date: Wed, 21 Aug 2013 06:19:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C473198@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C44E693@ESESSMB209.ericsson.se> <5213E4A6.3010704@alum.mit.edu> In-Reply-To: <5213E4A6.3010704@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI 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+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje63aJEgg+Z9whZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxpW0zS8EVlooVu7qZGhjPM3cxcnJICJhI NF0+ygRhi0lcuLeerYuRi0NI4CijxPxbb1ggnCWMEjNPvwTq4OBgE7CQ6P6nDdIgIuAr8ezx bTYQW1jATmLe+u9sEHF7iV2t7UwQdpjE34Xb2EBaWQRUJdbNdQcJ8wK1/ll0nB1i/GZmiUUv 77KAJDgFdCSOnjgINocR6KDvp9aAzWEWEJf4cPA61NECEkv2wDwgKvHy8T9WCFtJ4seGSywQ 9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyFGcWpyUm25k sIkRGA0Ht/y22MF4+a/NIUZpDhYlcd4temcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDu ily/SSnjXPaFlVyPPMw5JGclztSr2i22cHGyqR/TAcm2FSVXDsocWlj4sSjgwbZ1rkUS6w5z b1nx+u0qDtOKCTL9P/4Yfs0P0OX+PinlXzzHj3m9YhoPy12PJdpuWPr8taYek/d/q7QlvIcF A00dBHPsrO6deRvp/Dqd82fN/Pv2j9UzDi1TYinOSDTUYi4qTgQAV9VLYlQCAAA= Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 06:19:45 -0000 Hi, >> MAYBE we could restrict usage of POF/PANs, and say that they MUST NOT be= used to change session level information... > > I was assuming it was obvious that this must not be the case. > The POFs and PANs (AFAIK) only contain the media sections they intend to = change, so they don't contain the session level stuff. > If you change session level stuff, then you should need a real offer. Keep in mind that the o- line, which IS session level, IS modified each tim= e a POF/PAN is sent. Maybe we should use media level o- lines for POFs/PANs.... Regards, Christer From pkyzivat@alum.mit.edu Wed Aug 21 06:34:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3211E83A8 for ; Wed, 21 Aug 2013 06:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsRq+Ky5VBHw for ; Wed, 21 Aug 2013 06:34:16 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 02C9E11E839A for ; Wed, 21 Aug 2013 06:34:14 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id FNYT1m0020cZkys53RaEqW; Wed, 21 Aug 2013 13:34:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id FRaE1m00G3ZTu2S3WRaEG1; Wed, 21 Aug 2013 13:34:14 +0000 Message-ID: <5214C1D5.10201@alum.mit.edu> Date: Wed, 21 Aug 2013 09:34:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C44E693@ESESSMB209.ericsson.se> <5213E4A6.3010704@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C473198@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C473198@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=q20121106; t=1377092054; bh=uM7rPuf8bLf3XR7sRzJSit7cJv14qB1mkSjj/ZjXEdc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=U4JvZ6GKcEK1Yn1loyPwE9C3V6vam9xtimBNEgWF2hPa/yKHGCYum7DRKRdOa1ZA+ +mVT4eG/QRZuXiSgqlnQTJa59cYHaj537qaoLJlSVdZF9JLg6XFqYERAcbbQR100dN zZ+VH+w3tgZKAJ8v8f7fifW3UeMR4F2QUPcWMmeg3nHIPi00Lq1os7QNzt0seM14C0 GHczVQwoh8oFFtWpwxHJY1iWKhntnXEU/algA/ulyT9cRG56bXLVGwIoMgScLdrQbp Zo36nN/+v5gy2ZepVl0VglqKi84mQ70kkdWa9CRoWbqSm4AtNjvt7eqzWbIsoJknfM k2h38d5ZqJtiQ== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 13:34:22 -0000 On 8/21/13 2:19 AM, Christer Holmberg wrote: > Hi, > >>> MAYBE we could restrict usage of POF/PANs, and say that they MUST NOT be used to change session level information... >> >> I was assuming it was obvious that this must not be the case. >> The POFs and PANs (AFAIK) only contain the media sections they intend to change, so they don't contain the session level stuff. >> If you change session level stuff, then you should need a real offer. > > Keep in mind that the o- line, which IS session level, IS modified each time a POF/PAN is sent. Good point. > Maybe we should use media level o- lines for POFs/PANs.... I don't know how you could do that in a backward compatible way. Thanks, Paul From hadriel.kaplan@oracle.com Wed Aug 21 07:33:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76F611E80D9 for ; Wed, 21 Aug 2013 07:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng2pFeyFKXN6 for ; Wed, 21 Aug 2013 07:33:19 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B03A11E80F1 for ; Wed, 21 Aug 2013 07:33:19 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7LEXDkD029368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Aug 2013 14:33:14 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LEXDGf001547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 14:33:13 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LEXCZ2028788; Wed, 21 Aug 2013 14:33:12 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Aug 2013 07:33:12 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5214C1D5.10201@alum.mit.edu> Date: Wed, 21 Aug 2013 10:33:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26E5EE5C-85A6-43BB-80FB-4D05A059A90F@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C44E693@ESESSMB209.ericsson.se> <5213E4A6.3010704@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C473198@ESESSMB209.ericsson.se> <5214C1D5.10201@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 14:33:26 -0000 On Aug 21, 2013, at 9:34 AM, Paul Kyzivat wrote: >> Maybe we should use media level o- lines for POFs/PANs.... >=20 > I don't know how you could do that in a backward compatible way. Backward compatible to what? There's no POFs/PANs thing today. You = don't even need to use SDP syntax if you don't want to, or you could use = some diff-style format of SDP lines, or use what look and act exactly = like SDP lines but aren't technically "SDP" to avoid any legacy RFC = rules. -hadriel From pkyzivat@alum.mit.edu Wed Aug 21 10:24:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE6711E8234 for ; Wed, 21 Aug 2013 10:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuJMmVCtCYk0 for ; Wed, 21 Aug 2013 10:24:32 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 1E24011E8120 for ; Wed, 21 Aug 2013 10:24:31 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id FRQ41m0060vyq2s5EVQXef; Wed, 21 Aug 2013 17:24:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id FVQW1m00i3ZTu2S3RVQW4F; Wed, 21 Aug 2013 17:24:30 +0000 Message-ID: <5214F7CE.2060506@alum.mit.edu> Date: Wed, 21 Aug 2013 13:24:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C44E693@ESESSMB209.ericsson.se> <5213E4A6.3010704@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C473198@ESESSMB209.ericsson.se> <5214C1D5.10201@alum.mit.edu> <26E5EE5C-85A6-43BB-80FB-4D05A059A90F@oracle.com> In-Reply-To: <26E5EE5C-85A6-43BB-80FB-4D05A059A90F@oracle.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=q20121106; t=1377105871; bh=bZhtorwfnrZmsR1rDiIpO15Lu7aSS/jwyi8qUdgTGBM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gHNfUJcTmfKWyFu+Xyr8SKQGgVVB2VfQcWqycKB4LmSwEZYUs6Gaq1lEV5839znkN 8Bcjmi55ZO8Kmbp/LvdS0LIWjlV00z/OQDO2cJKMrSAG4dbmCoOqWYsDAkXKC+MhyV Tg4p7n+iFG/pB+vui3xWyK9B2nV54ehDqDrxzSIoaK/M1iRsl9mITCRLm0GLyZUhwD LmupTVWLS88yZw3C2oP8rw+CMiS5jT2MwW6n3zc1riJGVZl6ljeCvX3Zr1UfSm8FLD cKkH2fyGgH032MFm81OZHSvt/BFEmx2XBgEXGbhr0iPEDsQFGkfAAO6Hd5fmjDMDkx 8u29JV9s5sn4A== Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:24:44 -0000 On 8/21/13 10:33 AM, Hadriel Kaplan wrote: > > On Aug 21, 2013, at 9:34 AM, Paul Kyzivat wrote: > >>> Maybe we should use media level o- lines for POFs/PANs.... >> >> I don't know how you could do that in a backward compatible way. > > Backward compatible to what? There's no POFs/PANs thing today. You don't even need to use SDP syntax if you don't want to, or you could use some diff-style format of SDP lines, or use what look and act exactly like SDP lines but aren't technically "SDP" to avoid any legacy RFC rules. Maybe we are thinking of this differently, but my thinking is that consistency with a full SDP must be maintained. If you start off with an O/A, then some POFs/PANs, eventually you may need to do another O/A. And at that point there needs to be consistency. I think that means that POFs/PANs always contain a subset of a full SDP, and act as deltas, implicitly updating a full SDP. That means everything in the POFs/PANs needs to be valid SDP. And when that stuff is used in a full O/A, there need to be rules for how those are reconciled. So, to introduce a media level o-line, it would need to be defined for SDP too. It might be possible to arrange so that it won't be seen by an endpoint that doesn't support POFs/PANs, but that will take some care, and is likely to be fragile. Thanks, Paul From aallen@blackberry.com Wed Aug 21 10:31:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9F511E826C for ; Wed, 21 Aug 2013 10:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrnSdQbqnJkQ for ; Wed, 21 Aug 2013 10:31:25 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7F211E80FA for ; Wed, 21 Aug 2013 10:31:23 -0700 (PDT) X-AuditID: 0a41282f-b7f8b6d000004656-92-5214f9648f2d Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id EA.C1.18006.469F4125; Wed, 21 Aug 2013 12:31:16 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.03.0123.003; Wed, 21 Aug 2013 12:31:16 -0500 From: Andrew Allen To: Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Propo Thread-Index: AQHOlU4Nmoxv99P2J06Zo3Rf6o2Qapmf5I5Q Date: Wed, 21 Aug 2013 17:31:14 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E0153CXMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsXC5ZyvrZvyUyTI4PslK4v3F3Qtpi5/zOLA 5DHl90ZWjyVLfjIFMEU1MNok5uXllySWpCqkpBYn2yr5pKYn5igEFGWWJSZXKrhkFifnJGbm phYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9d CwtTS11DJTtdJJDwjzujv+0EY8Hc34wV77++ZmlgnHqVsYuRk0NCwERix5fVTBC2mMSFe+vZ QGwhgZWMEi9bsrsYuYDszYwSDf+3sYAk2AS0JPYfng7WICLgKnFk4V0mkCJhgT4mieZH79hA HBGBfiaJpuZ/LBBVRhIN27rA1rEIqErcezCPGcTmFfCQ+N08HSzOKCArsfvsdbCpzALiEree zIc6SUBiyZ7zzBC2qMTLx/9YIWxFiRl75gPZHED1+RLP19dAjBSUODnzCcsERqFZSCbNQqia haQKokRHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UomJtRbGBmkJyXrFeUmauXl1qyiRGU EBw19Hcwvn1vcYhRgINRiYd3xXeRICHWxLLiytxDjBIczEoivIUngUK8KYmVValF+fFFpTmp xYcYg4BhMpFZijs5H5is8krijQ0MiOQoifO6qnwIFBJIByas7NTUgtQimKFMHJxSDYzyt7Q3 ptVVB4o16fN3vkw2OPotrONL7r4b+wpvXtW7/rGAX+amhco3ZbFNv+OEoiZXbOa2ZMlb9HP1 HjZRCQPOD0ffCH3+lbq11eqvt+MCvi9nnYTDzDztH+W/8fxnHTPbJ0hX4v3SmJnRG3ckmC13 4Zu4YpM60y29b4d7/HLWx06fxRdxdZkSS3FGoqEWc1FxIgBcZTVzOwMAAA== Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Propo X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:31:31 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E0153CXMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable In my view since including all the correlation attributes in the SDP is a SH= OULD strength implementing all the correlation attributes should also be of= SHOULD strength or at most MUST implement except when it is known that a pa= rticular correlation mechanism will work for the deployment scenario that c= ircuit-switched bearer is used. It seems to me kind of silly to have a MUST= implement (but might not ever try and use requirement). To my knowledge 3GPP are currently the only party interested in using this d= raft. To publish this draft with mandatory aspects which are not needed and= not acceptable to 3GPP application will in my view be a mistake and result= in an RFC that will either not be implemented or will not be implemented as= written because the overhead of implementing the DTMF and UUI correlation m= echanisms is not justified and since these are not needed in the 3GPP use ca= se and will not work with the 3GPP architecture either. In the 3GPP application of this draft the negotiation of the circuit-switche= d bearer does not take place end to end between the terminals but instead be= tween the terminal and an IMS network infrastructure component (the SCC AS)= that acts as B2BUA and the CS call is then interworked to SIP and patched i= n with the session with the remote party. In addition the E.164 number provi= ded by the IMS network infrastructure component is unique for that circuit-s= witched bearer setup so no additional correlation mechanism is really needed= . The Mobile terminal always acts as the active party in establishing the ci= rcuit switched bearer in the 3GPP scenario. Mandating the callerid mechanism for correlation is acceptable to me since i= t basically has no impact on the mobile terminal or the IMS network infrastr= ucture component except the inclusion of the cs-correlation attribute and th= e inclusion of that by the interworking MSC in the P-Asserted-Identity (whic= h is already done). It may have the advantage that now the IMS network infra= structure component does not have to allocate a unique E.164 number for each= session but could just use the callerid for the correlation. I think this a= lso does mean that the SCC AS can then be sure that the CS session setup is= coming from the terminal that was negotiated it in the O/A exchange and no= t some attacker trying to hijack sessions using as the dialed number an E.16= 4 number that was previously assigned to him. Also since in the 3GPP scenari= o the circuit-switched network is local to and under the control of the oper= ator the callerid mechanism can be guaranteed to work. The DTMF and UUI mechanisms are quite intensive to implement and both have i= ssues for the 3GPP application. DTMF will result in a delay in the setup end= to end of the media and also would require media to be routed to the IMS ne= twork infrastructure component (which is only a signaling B2BUA) and force i= t to have to support DTMF tone detection. UUI will almost certainly not wor= k as most operators switchers do not pass this information and also would re= quire support for the CUSS UUI mechanisms to deliver the UUI in SIP from the= interworking switch to the SCC AS. I am not against the end to end use of CS SDP but I think it does have some= issues such as the cost of long distance or even international circuit swit= ched bearers when the only leg that is a problem is the access for one mobil= e user. Also a device that needs to use circuit switched bearers cannot do s= o with those device that don't also support CS SDP or that also have access= to a circuit-switched connection. So I don't think the correlation issues w= ith end to end use are the primary obstacles to successful interoperability.= One way to address the interoperability issues is an architecture like 3GPP= 's where the circuit-switched bearer is negotiated between the device and an= interworking function at the edge of the network which is where the quality= problem exists in the first place not to set up a CS call end to end. In my view it is not the end of the world if in some scenarios the user has= to manually accept the circuit switched bearer and patch it into the multim= edia session. In fact there may be some really valid use cases where the dev= ice that receives the CS setup is not the same device that negotiated the CS= session using SDP. Think of a webex type conference where you connect into= a conference using SIP and then get the conference bridge to call you back= with a PSTN call to your POTS phone - Manual acceptance seems fine to me in= this case and automatic correlation will not work. Similarly an internet g= aming session established using SIP might call the user back at his POTS lin= e for audio conversations associated with the game. One possibility is to state in the draft that if you cannot confirm that the= CS call is part of the session negotiated using SDP using a correlation mec= hanism or some other means you MUST NOT accept the CS bearer as part of the= session without manual user acceptance. I am Ok for the callerid correlation mechanism to be made mandatory to imple= ment. I think this is the mechanism with the least burden for implementation= s and also the one most likely to work. I do not agree that the DTMF and the= UUI should be mandatory to implement. I also think it should be realized that implementations may only support one= direction for the CS call establishment and that the endpoints only need to= support the aspects of the correlation mechanism for the direction(s) they= support. Also some users might also not wish to be a passive party (such as= when calling party pays for example when cellular roaming) even if they hav= e the capability to do so. Thus some implementations may only support the as= pects of the correlation mechanism for the direction (active or passive) tha= t they support. Andrew From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Flemming Andreasen Sent: Friday, August 09, 2013 6:10 PM To: mmusic Subject: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol= Action: 'Session Description Protocol (SDP) Extension For Setting Audio and= Video Media Streams Over Circuit-Switched Bearers In The Public Switched Te= lephone Network (PSTN)' to Propos... Greetings MMUSIC As you can see per the below, the IESG approved the Circuit-Switched Bearers= draft for publication, however before doing so, they requested a couple of= changes. The resulting approved document can be found at http://tools.ietf.= org/html/draft-ietf-mmusic-sdp-cs-21 One of the changes introduced resulted in all 3 correlation mechanisms now b= eing mandatory-to-implement (previously they were not): Implementations MUST support the three correlation mechanisms specified in Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4, and SHOULD include all supported mechanisms the initial Offer. Since this is a non-trivial change that has not been discussed by the WG (an= d we know of at least one person having expressed concerns with it off-line)= , we are hereby solicting the WG participants for input on changes introduce= d as a result of the IESG review with a focus on the above. In doing so, ple= ase keep in mind that we are developing standards that work in the general I= nternet. The following URL provides a diff-file showing the changes resulting from th= e IESG review: http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sdp-cs-18.txt&url= 2=3Ddraft-ietf-mmusic-sdp-cs-21.txt Comments are due by August 23 (two weeks from today) Thanks -- Flemming (MMUSIC co-chair) -------- Original Message -------- Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For= Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The= Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-= mmusic-sdp-cs-21.txt) Date: Mon, 1 Jul 2013 11:56:23 -0700 From: The IESG To: IETF-Announce CC: mmusic chair , mmusic mailing list , RFC Edi= tor The IESG has approved the following document: - 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ *Technical Summary * The document describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Publich Switched Telephone Network (PSTN) *Working Group Summary * The WG had some discussion around the format to use for E.164 numbers and whether to align this with the existing definition in RFC 3108. The RFC 3108 definition was seen as deficient and the WG agreed it was better to align with relevant parts of the tel URI format defined in RFC 3966, not least since SDP address types are defined in the context of a particular network type, and hence RFC 3108 compatibility is not a concern (the implication is that the "E164" address type may differ between network types in SDP). *Document Quality * There are currently no known implementations of the draft, however the draft is a dependency for 3GPP, so future implementations are expected. The document has received good overall review in the WG, some of which resulted in changes to the detailed specification. The document has been reviewed in detail several times, including of the last few versions. The major contributors to these as well as earlier discussions are listed in the Acknowledgements section of the document. *Personnel * Document Shepherd: Flemming Andreasen Responsible AD: Gonzalo Camarillo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic . --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338E0153CXMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

In my view since= including all the correlation attributes in the SDP is a SHOULD strength im= plementing all the correlation attributes should  also be of SHOULD str= ength or at most MUST implement except when it is known that a particular correlation mechanism will work for the= deployment scenario that  circuit-switched bearer is used. It seems to= me kind of silly to have a MUST implement (but might not ever try and use r= equirement).

 =

To my knowledge 3= GPP are currently the only party interested in using this draft. To publish= this draft with mandatory aspects which are not needed and not acceptable t= o 3GPP application will in my view be a mistake and result in an RFC that will either not be implemented or wi= ll not be implemented as written because the overhead of implementing the DT= MF and UUI correlation mechanisms is not justified and since these are not n= eeded in the 3GPP use case and will not work with the 3GPP architecture either.

 =

In the 3GPP appli= cation of this draft the negotiation of the circuit-switched bearer does not= take place end to end between the terminals but instead between the termina= l and an IMS network infrastructure component (the SCC AS) that acts as B2BUA and the CS call is then interwork= ed to SIP and patched in with the session with the remote party. In addition= the E.164 number provided by the IMS network infrastructure component is un= ique for that circuit-switched bearer setup so no additional correlation mechanism is really needed. The M= obile terminal always acts as the active party in establishing the circuit s= witched bearer in the 3GPP scenario.

 =

Mandating the cal= lerid mechanism for correlation is acceptable to me since it basically has n= o impact on the mobile terminal or the IMS network infrastructure component= except the inclusion of the cs-correlation attribute and the inclusion of that by the interworking MSC in the P-Assert= ed-Identity (which is already done). It may have the advantage that now the= IMS network infrastructure component does not have to allocate a unique E.1= 64 number for each session but could just use the callerid for the correlation. I think this also does mea= n that the SCC AS can then be sure that the CS session setup is coming from= the terminal  that was negotiated it in the O/A exchange and not some= attacker trying to hijack sessions using as the dialed number an E.164 number that was previously assigned to= him. Also since in the 3GPP scenario the circuit-switched network is local= to and under the control of the operator the callerid mechanism can be guar= anteed to work.

 =

The DTMF and UUI= mechanisms are quite intensive to implement and both have issues for the 3G= PP application. DTMF will result in a delay in the setup end to end of the m= edia and also would require media to be routed to the IMS network infrastructure component (which is only a s= ignaling B2BUA) and force it to have to support  DTMF tone detection. U= UI will almost certainly not work as most operators switchers do not pass th= is information and also would require support for the CUSS UUI mechanisms to deliver the UUI in SIP from the inte= rworking switch to the SCC AS.

 =

I am not against the end to end use of CS= SDP but I think it does have some issues such as the cost of long distance= or even international circuit switched bearers when the only leg that is a problem is the access for one mobile user. Also a device= that needs to use circuit switched bearers cannot do so with those device t= hat don’t also support CS SDP or that also have access to a circuit-sw= itched connection. So I don’t think the correlation issues with end to end use are the primary obstacles to suc= cessful interoperability. One way to address the interoperability issues is= an architecture like 3GPP's where the circuit-switched bearer is negotiated= between the device and an interworking function at the edge of the network which is where the quality problem exis= ts in the first place not to set up a CS call end to end.

 

In my view it is not the end of the world= if in some scenarios the user has to manually accept the circuit switched b= earer and patch it into the multimedia session. In fact there may be some really valid use cases where the device that receives the= CS setup is not the same device that negotiated the CS session using SDP. T= hink of a webex type conference where you connect into a conference using SI= P and then get the conference bridge to call you back with a PSTN call to your POTS phone – Manual= acceptance seems fine to me in this case and automatic correlation will not= work. Similarly an internet  gaming session established using SIP migh= t call the user back at his POTS line for audio conversations associated with the game.

 =

One possibility is to state in the draft= that if you cannot confirm that the CS call is part of the session negotiat= ed using SDP using a correlation mechanism or some other means you MUST NOT accept the CS bearer as part of the session without manu= al user acceptance.

I am Ok for the callerid correlation mechanism to be made= mandatory to implement. I think this is the mechanism with the least burden= for implementations and also the one most likely to work. I do not agree that the DTMF and the UUI should be mandatory to imple= ment.

 

I also think it should be realized that i= mplementations may only support one direction for the CS call establishment= and that the endpoints only need to support the aspects of the correlation mechanism for the direction(s) they support. Also some u= sers might also not wish to be a passive party (such as when calling party p= ays for example when cellular roaming) even if they have the capability to d= o so. Thus some implementations may only support the aspects of the correlation mechanism for the direction= (active or passive) that they support.

 =

Andrew=

 =

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.= org] On Behalf Of Flemming Andreasen
Sent: Friday, August 09, 2013 6:10 PM
To: mmusic
Subject: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: P= rotocol Action: 'Session Description Protocol (SDP) Extension For Setting Au= dio and Video Media Streams Over Circuit-Switched Bearers In The Public Swit= ched Telephone Network (PSTN)' to Propos...

 

Greetings MMUSIC

As you can see per the below, the IESG approved the Circuit-Switched Bearers= draft for publication, however before doing so, they requested a couple of= changes. The resulting approved document can be found at http://to= ols.ietf.org/html/draft-ietf-mmusic-sdp-cs-21

One of the changes introduced resulted in all 3 correlation mechanisms now b= eing mandatory-to-implement (previously they were not):
<quote>

&nb=
sp;  Implementations MUST support the three correlation mechanisms=

&nb=
sp;  specified in Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4,
&nb=
sp;  and SHOULD include all supported mechanisms the initial Offer.

</quote>
Since this is a non-trivial change that has not been discussed by the WG (an= d we know of at least one person having expressed concerns with it off-line)= , we are hereby solicting the WG participants for input on changes introduce= d as a result of the IESG review with a focus on the above. In doing so, please keep in mind that we are dev= eloping standards that work in the general Internet.


The following URL provides a diff-file showing the changes resulting from th= e IESG review:
    http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sdp-cs-18.txt&url= 2=3Ddraft-ietf-mmusic-sdp-cs-21.txt

Comments are due by August 23 (two weeks from today)

Thanks

-- Flemming (MMUSIC co-chair)



-------- Original Message --------

Subject= :

[MMUSIC] Protocol Action: 'Session Description Protoc= ol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Sw= itched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed= Standard (draft-ietf-mmusic-sdp-cs-21.txt)

Date: <= o:p>

Mon, 1 Jul 2013 11:56:23 -0700

From: <= o:p>

The IESG &= lt;iesg-secretary@ietf.org>

To:

IETF-Announce <ietf-announce@ietf.org>

CC:

mmusic chair <mmusic-chairs@tools.ietf.org>, mmusic mailing list <mmusic@ietf.org>, RFC Editor <= a href=3D"mailto:rfc-editor@rfc-editor.org"> <rfc-editor@rfc-editor.org>

 

The IESG has approved the following document:
- 'Session Description Protocol (SDP) Extension For Setting Audio and
   Video Media Streams Over Circuit-Switched Bearers In The P=
ublic
   Switched Telephone Network (PSTN)'
  (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard
 
This document is the product of the Multiparty Multimedia Session Contr=
ol
Working Group.
 
The IESG contact persons are Gonzalo Camarillo and Richard Barnes.=

 
A URL of this Internet Draft is:
h=
ttp://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/

 


 


 


 


*Technical Summary


*


 


The document describes use cases, requirements, and protocol extensions=



for using the Session Description Protocol (SDP) Offer/Answer model for=



establishing audio and video media streams over circuit-switched bearer=
s


in the Publich Switched Telephone Network (PSTN)


 


*Working Group Summary


*


 


The WG had some discussion around the format to use for E.164 numbers


and whether to align this with the existing definition in RFC 3108. The=



RFC 3108 definition was seen as deficient and the WG agreed it was=



better to align with relevant parts of the tel URI format defined in RF=
C


3966, not least since SDP address types are defined in the context of a=



particular network type, and hence RFC 3108 compatibility is not a=



concern (the implication is that the "E164" address type may=
 differ


between network types in SDP).


 


*Document Quality


*


 


There are currently no known implementations of the draft, however the<=
o:p>


draft is a dependency for 3GPP, so future implementations are expected.=



 


The document has received good overall review in the WG, some of which<=
o:p>


resulted in changes to the detailed specification. The document has bee=
n


reviewed in detail several times, including of the last few versions.


The major contributors to these as well as earlier discussions are=



listed in the Acknowledgements section of the document.

 


 


*Personnel


*


 


Document Shepherd: Flemming Andreasen


Responsible AD: Gonzalo Camarillo 


_______________________________________________


mmusic mailing list


mmusic@ietf.org


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


.


 


 

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338E0153CXMB104ADSrimnet_-- From hadriel.kaplan@oracle.com Wed Aug 21 12:22:07 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8521F9BD0 for ; Wed, 21 Aug 2013 12:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5w5khcZA5V6 for ; Wed, 21 Aug 2013 12:21:58 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A969A21F9EEC for ; Wed, 21 Aug 2013 12:21:53 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7LJLmSE001708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Aug 2013 19:21:49 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LJLlvP006994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 19:21:48 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LJLlVw019877; Wed, 21 Aug 2013 19:21:47 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Aug 2013 12:21:46 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5214F7CE.2060506@alum.mit.edu> Date: Wed, 21 Aug 2013 15:21:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C44E693@ESESSMB209.ericsson.se> <5213E4A6.3010704@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C473198@ESESSMB209.ericsson.se> <5214C1D5.10201@alum.mit.edu> <26E5EE5C-85A6-43BB-80FB-4D05A059A90F@oracle.com> <5214F7CE.2060506@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:22:07 -0000 On Aug 21, 2013, at 1:24 PM, Paul Kyzivat wrote: > On 8/21/13 10:33 AM, Hadriel Kaplan wrote: >> Backward compatible to what? There's no POFs/PANs thing today. You = don't even need to use SDP syntax if you don't want to, or you could use = some diff-style format of SDP lines, or use what look and act exactly = like SDP lines but aren't technically "SDP" to avoid any legacy RFC = rules. >=20 > Maybe we are thinking of this differently, but my thinking is that = consistency with a full SDP must be maintained. If you start off with an = O/A, then some POFs/PANs, eventually you may need to do another O/A. And = at that point there needs to be consistency. Sure, the state changes and the rules that do that must be consistent. = The encoding syntax and rules for mandatory lines in a POF/PAN need not = be. (not that I'm seriously proposing a different encoding syntax be = created, but just saying "we aren't constrained to SDP offer/answer MUST = rules for this POF/PAN piece") > I think that means that POFs/PANs always contain a subset of a full = SDP, and act as deltas, implicitly updating a full SDP. That means = everything in the POFs/PANs needs to be valid SDP. So are you saying it needs to contain an "v=3D", "s=3D", and "t=3D" = lines? Because those are mandatory for "SDP", afaik. =20 [In fact afaict, technically "e=3D" and "p=3D" were mandatory = originally, but RFC 3264 downgraded them to optional. (and then later = RFC 4566 did the same for "SDP")] This POF/PAN thing can pick+choose what pieces of SDP-ish stuff it needs = to convey, and how. > And when that stuff is used in a full O/A, there need to be rules for = how those are reconciled. Sure. > So, to introduce a media level o-line, it would need to be defined for = SDP too. Or we could keep an o=3D line above the m=3D section of the POF/PAN, or = define some other attribute altogether to perform the same function for = the POFs/PANs and just define that it updates the sess-version value, or = whatever. My only point is we don't need to worry about = backwards-compatibility. We do need to worry about name collision with = SDP, since we're using SDP syntax encoding. But we could, for example, = define attributes that are only usable for POFs/PANs and not full SDP = O/A. -hadriel From ron.even.tlv@gmail.com Thu Aug 22 02:08:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513B721F933B for ; Thu, 22 Aug 2013 02:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBYccFgVNEyK for ; Thu, 22 Aug 2013 02:08:01 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1799721F87BB for ; Thu, 22 Aug 2013 02:07:44 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q56so1365550wes.21 for ; Thu, 22 Aug 2013 02:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=1gSrrKE2RzzVCXEuMTcieEjitawOhd6nuumQq6NdUHk=; b=NCfTsuC/eYOpMpUQ5U1j6l+youBklvrznUYBlJy9jtFT7mkQALjmqWyH77P5bKWTJk l3gBmL9Joc8aOXwTGCuJzhjzLOqK1ALUhdtOBY2crqAMolv94dkfs9QsYYklF7VkQoIm C6gYOxSX5brYvxcdKQyopaX6asltAoP4jXkp5UHsZoSTD1j1YqoFzC3tYlgX1HUXhfK2 w7J8wU3o+3a5pGekvXAN5vdkKS8A5q0MN3aIaH9PgBJpAv2dgdJVM6LhBX8Uz5Yw1uMV AK73Yzb+gu2ZAAlgs7czgfDUX8i3UOf6FbDQsUsI8V1gGId5No+kdc8vGxmbvMds7Axg 3h9g== X-Received: by 10.180.9.69 with SMTP id x5mr19997719wia.41.1377162464199; Thu, 22 Aug 2013 02:07:44 -0700 (PDT) Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id ff5sm31442134wib.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 02:07:42 -0700 (PDT) From: "Roni Even" To: "'Jonathan Lennox'" , "'Bernard Aboba'" References: , <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com>, <3AD93742-DBA4-4EDD-80AD-A667994ECE8D@vidyo.com> In-Reply-To: <3AD93742-DBA4-4EDD-80AD-A667994ECE8D@vidyo.com> Date: Thu, 22 Aug 2013 12:05:13 +0300 Message-ID: <034a01ce9f16$bc2d8600$34889200$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_034B_01CE9F2F.E17BA860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ680PtyCDXIknXog+yt3k+QmtJ0gEe3FNKAgCnf3gCFUU8LQNTIcKFmAQHXVA= Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 09:08:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_034B_01CE9F2F.E17BA860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jonathan, Maybe if you want to use FEC only on the base layer and not on all layers. Roni From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lennox Sent: 19 July, 2013 5:54 PM To: Bernard Aboba Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RFC 6190 Single Session Transport On Jul 18, 2013, at 10:02 PM, Bernard Aboba wrote: Jonathan said: "I don't understand how single-session multi-source transmission will work without either a) signaling "a=ssrc-group DDP" decoding dependencies, or b) making various implementation-specific assumptions about the structure of the SVC streams." [BA] In terms of SDP choices for expressing layering within a single m line, you can either go the a=ssrc-group:DDP route, or use distinct payload types for each layer and RFC 5583 a=group:DDP (this is what "Unified Plan" Section 4.7 appears to advocate). I'm not sure how "MST within a single session" could be expressed in SDP without BUNDLE. Was the idea to use multiple m lines and group them together but use the same port? I think the authors of RFC 6190 didn't see a use case for MST within a single RTP session -- all of the interesting MST use cases they saw involved separate transport flows for the separate layers, and if you're sending all the layers on a single transport flow, SST is significantly simpler. What requirement are you trying to achieve that's met by MST in a single session, but not by SST? -- Jonathan Lennox jonathan@vidyo.com ------=_NextPart_000_034B_01CE9F2F.E17BA860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

Maybe if you want to use FEC only on the base layer and not on all = layers.

Roni

 

From:= = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = Jonathan Lennox
Sent: 19 July, 2013 5:54 PM
To: = Bernard Aboba
Cc: mmusic@ietf.org
Subject: Re: = [MMUSIC] RFC 6190 Single Session = Transport

 

 

On = Jul 18, 2013, at 10:02 PM, Bernard Aboba <bernard_aboba@hotmail.com&g= t; wrote:



Jonathan said: 

"I don't understand = how single-session multi-source transmission will work without either a) = signaling "a=3Dssrc-group DDP" decoding dependencies, or b) = making various implementation-specific assumptions about the structure = of the SVC streams."
 
[BA] In terms of SDP choices for = expressing layering within a single m line, you can either go the = a=3Dssrc-group:DDP route, or use distinct payload types for each layer = and RFC 5583 a=3Dgroup:DDP (this is what "Unified Plan" = Section 4.7 appears to advocate).  

I'm not sure how = "MST within a single session" could be expressed in SDP = without BUNDLE.  Was the idea to use multiple m lines and group = them together but use the same port? 

 

I think the authors of RFC 6190 didn't see a use case = for MST within a single RTP session -- all of the interesting MST use = cases they saw involved separate transport flows for the separate = layers, and if you're sending all the layers on a single transport flow, = SST is significantly simpler.

 

What requirement are you trying to achieve that's met = by MST in a single session, but not by SST?

 

--

Jonathan Lennox
jonathan@vidyo.com

 

------=_NextPart_000_034B_01CE9F2F.E17BA860-- From christer.holmberg@ericsson.com Thu Aug 22 02:37:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4471711E819D for ; Thu, 22 Aug 2013 02:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Hem3aaQWFT for ; Thu, 22 Aug 2013 02:37:17 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF221F9FFF for ; Thu, 22 Aug 2013 02:37:16 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-eb-5215dbc9b492 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8B.70.03802.9CBD5125; Thu, 22 Aug 2013 11:37:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Thu, 22 Aug 2013 11:37:08 +0200 From: Christer Holmberg To: Dan Wing Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 Thread-Index: Ac6c2+8uzokCW2xnSQeYLTwy0EHdvQAFtGOAAIoTZrA= Date: Thu, 22 Aug 2013 09:37:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4754A3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C46787F@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6p26JBBgtOsFtcvPaQyeLf3iSL qcsfszgwe0z5vZHVY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DK6JrYxVZwTrTi0JojrA2M 2wW7GDk5JARMJE71nGKFsMUkLtxbz9bFyMUhJHCYUeLnpB0sEM4SRon2exuZuhg5ONgELCS6 /2mDNIgIyEncnT+BGcRmFoiVWHzrKguILSzgIjHh1j52iBpXid5Nq1khbCuJnotXwGwWAVWJ a/OfgfXyCvhKPPv+AWpXA6PE/G/3GUESnAK2Eu03DrCB2IxA130/tYYJYpm4xK0n85kgrhaQ WLLnPDOELSrx8vE/qG8UJdqfNjBC1OtILNj9iQ3C1pZYtvA11GJBiZMzn7BMYBSbhWTsLCQt s5C0zELSsoCRZRUje25iZk56udEmRmDcHNzyW3UH451zIocYpTlYlMR5N+udCRQSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAuCmYva1S+e1zz8APKxojor3377630rs+/vCxpODPCTo5Oxi5 qi6acs/TThB50/OpnXWClcnOnu9GDyb0phye4pZnsq3nsUJL67svJ19e9KhTKvl3M04ymGUV n1W47dpjBz5eZNdeuzCV2b91qf4jrsSKSP3Vi1YZbLumd6Fmz905znrGZ7Z8U2Ipzkg01GIu Kk4EAIPPfH9pAgAA Cc: "mmusic-chairs@tools.ietf.org" , mmusic Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 09:37:22 -0000 Hi Dan, Regarding the 3GPP SA3 study, the information I gave was a little misleadin= g. From a security perspective SRTP would be fine. The focus of the SA3 study was on how to provide security for the existing = fax transmission mechanism, which uses UDPTL/UDP. 3GPP already mandates IMS terminals to support UDPTL/UDP for unsecure fax. = And, new terminals (supporting secure fax) are still required to also suppo= rt unsecure fax, in order to communicate with legacy terminals when unsecur= e fax is sufficient.=20 So, using UDPTL/DTLS/UDP for secure fax makes more sense, as it avoids impl= ementing different mechanisms for secure and unsecure fax - UDPTL/DTLS/UDP = only requires a new layer between UDPTL and UDP, it does not require changi= ng the upper layers (UDPTL and above). Hopefully this clarifies :) Regards, Christer -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: 19. elokuuta 2013 20:43 To: Christer Holmberg Cc: mmusic; mmusic-chairs@tools.ietf.org Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 On Aug 19, 2013, at 6:03 AM, Christer Holmberg wrote: > Hi, > =20 > We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, which= defines usage of UDPTL over DTLS, in order to provide secure fax. > =20 > The draft was previously submitted to DISPATCH. Based on discussions with= the ADs and chairs, it was decided that it shall be submitted to MMUSIC (n= ote that no DTLS extensions are needed). > =20 > As is indicated in the draft, 3GPP has performed a study on how to=20 > provide secure fax in the IMS, and the outcome was that secure fax shall = be transported using UDPTL over DTLS. Got a pointer to that study? Seems easier to carry UDPTL over RTP, which w= ould allow the RTP to be secured using SRTP (and thus the UDPTL would be se= cured using SRTP). There is a spec floating around to do exactly that (car= ry fax over RTP so that SRTP can secure it). Advantage of using SRTP to se= cure fax is it separates the keying mechanism from security, so that Securi= ty Descriptions / MIKEY / DTLS-SRTP / whatever-is-invented-in-2020 will wor= k just as effectively for voice as for fax. And also that upgrading from a= voice call to a "fax" call has no additional complexities due to security = ("please press START to begin the fax transmission"). -d > However, there is nothing "3GPP/IMS specific" about the mechanism, as UDP= TL is commonly used for fax also elsewhere. > =20 > Regards, > =20 > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From atle.monrad@ericsson.com Thu Aug 22 05:11:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9CE11E81B0 for ; Thu, 22 Aug 2013 05:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FPOGIBZ+1dP for ; Thu, 22 Aug 2013 05:10:56 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7429411E81B2 for ; Thu, 22 Aug 2013 05:10:55 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-fb-5215ffccbe1e Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A4.71.22048.CCFF5125; Thu, 22 Aug 2013 14:10:52 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.129]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Thu, 22 Aug 2013 14:10:52 +0200 From: Atle Monrad To: Andrew Allen , Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Propo Thread-Index: AQHOlU4Nmoxv99P2J06Zo3Rf6o2Qapmf5I5QgAFLoaA= Date: Thu, 22 Aug 2013 12:10:51 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C1844F6@ESESSMB203.ericsson.se> References: In-Reply-To: Accept-Language: nb-NO, 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_7D2F7D7ADBA812449F25F4A69922881C1844F6ESESSMB203ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje7Z/6JBBnPvGFrcn7eV0eL9BV2L qcsfszgwe8xqWMvuMeX3RlaPJUt+MgUwR3HZpKTmZJalFunbJXBlbJoxm7lg1X6mim9XsxoY L0xk6mLk5JAQMJE4uO8oG4QtJnHh3nogm4tDSOAwo8SGq6+YIJwljBLHmiGq2AR0JM79vMMK YosI5ErMmnCFHaRIWKCPSaL50TuwdhGBfiaJpuZ/LBBVVhIdJzvAOlgEVCX67mwAs3kFvCUW XlnOCGILCXhIrNzYBWZzCnhKnHt4B6iXg4NRQFZibhMvSJhZQFzi1pP5UGcLSCzZc54ZwhaV ePn4HyuErSTRuOQJK0R9vsS2S4eYIFYJSpyc+YRlAqPILCSjZiEpm4WkDCKuI7Fg9yc2CFtb YtnC18ww9pkDj5mQxRcwsq9iZM9NzMxJLzffxAiMqYNbfhvsYNx0X+wQozQHi5I472a9M4FC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGGPkH+9ycQ841tD+KvFtxNNlE38v/Z8cnMeTnDiZ ScKmw7bW9P3jnxPU/ZpzLv+qCGQo0r9beHCVW8qFWY8Pu9VJ/ZobF7YsmOlkWiJ/6MYAGb6q K9pVT1eL7xafV6b2tuunRL7z2sx50fMrWR7ltGZuZjoxd7IYZ8+1TKfkhgcXD+cJTLydr8RS nJFoqMVcVJwIABQNIuZ3AgAA Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Propo X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:11:03 -0000 --_000_7D2F7D7ADBA812449F25F4A69922881C1844F6ESESSMB203ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks I'd like to support Andrew on this topic. I don't know if bundling these attributes together in one draft was done ju= st for convenience or of there are other reasons. What is clear is that the= se three attributes were not related initially. 3GPP has no use of all attributes as explained by Andrew. I hope that this = late change can be reverted (or modified in a less radical way) and the dra= ft completed soon. 3GPP has been waiting for completion of this draft for long now. I think we= can assume that there are implementations in the field, thus these last mi= nute changes may cause problems. Please also consider that the 3GPP-feature using this draft is "IMS Central= ized Service Control". This feature is part of 3GPP Rel-8, a release that w= as completed from 3GPP point if view by June 2008. Thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation Ericsson From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Andrew Allen Sent: 21. august 2013 19:31 To: Flemming Andreasen; mmusic Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Pro= tocol Action: 'Session Description Protocol (SDP) Extension For Setting Aud= io and Video Media Streams Over Circuit-Switched Bearers In The Public Swit= ched Telephone Network (PSTN)' to Propo In my view since including all the correlation attributes in the SDP is a S= HOULD strength implementing all the correlation attributes should also be = of SHOULD strength or at most MUST implement except when it is known that a= particular correlation mechanism will work for the deployment scenario tha= t circuit-switched bearer is used. It seems to me kind of silly to have a = MUST implement (but might not ever try and use requirement). To my knowledge 3GPP are currently the only party interested in using this = draft. To publish this draft with mandatory aspects which are not needed an= d not acceptable to 3GPP application will in my view be a mistake and resul= t in an RFC that will either not be implemented or will not be implemented = as written because the overhead of implementing the DTMF and UUI correlatio= n mechanisms is not justified and since these are not needed in the 3GPP us= e case and will not work with the 3GPP architecture either. In the 3GPP application of this draft the negotiation of the circuit-switch= ed bearer does not take place end to end between the terminals but instead = between the terminal and an IMS network infrastructure component (the SCC A= S) that acts as B2BUA and the CS call is then interworked to SIP and patche= d in with the session with the remote party. In addition the E.164 number p= rovided by the IMS network infrastructure component is unique for that circ= uit-switched bearer setup so no additional correlation mechanism is really = needed. The Mobile terminal always acts as the active party in establishing= the circuit switched bearer in the 3GPP scenario. Mandating the callerid mechanism for correlation is acceptable to me since = it basically has no impact on the mobile terminal or the IMS network infras= tructure component except the inclusion of the cs-correlation attribute and= the inclusion of that by the interworking MSC in the P-Asserted-Identity (= which is already done). It may have the advantage that now the IMS network = infrastructure component does not have to allocate a unique E.164 number fo= r each session but could just use the callerid for the correlation. I think= this also does mean that the SCC AS can then be sure that the CS session s= etup is coming from the terminal that was negotiated it in the O/A exchang= e and not some attacker trying to hijack sessions using as the dialed numbe= r an E.164 number that was previously assigned to him. Also since in the 3G= PP scenario the circuit-switched network is local to and under the control = of the operator the callerid mechanism can be guaranteed to work. The DTMF and UUI mechanisms are quite intensive to implement and both have = issues for the 3GPP application. DTMF will result in a delay in the setup e= nd to end of the media and also would require media to be routed to the IMS= network infrastructure component (which is only a signaling B2BUA) and for= ce it to have to support DTMF tone detection. UUI will almost certainly no= t work as most operators switchers do not pass this information and also wo= uld require support for the CUSS UUI mechanisms to deliver the UUI in SIP f= rom the interworking switch to the SCC AS. I am not against the end to end use of CS SDP but I think it does have some= issues such as the cost of long distance or even international circuit swi= tched bearers when the only leg that is a problem is the access for one mob= ile user. Also a device that needs to use circuit switched bearers cannot d= o so with those device that don't also support CS SDP or that also have acc= ess to a circuit-switched connection. So I don't think the correlation issu= es with end to end use are the primary obstacles to successful interoperabi= lity. One way to address the interoperability issues is an architecture lik= e 3GPP's where the circuit-switched bearer is negotiated between the device= and an interworking function at the edge of the network which is where the= quality problem exists in the first place not to set up a CS call end to e= nd. In my view it is not the end of the world if in some scenarios the user has= to manually accept the circuit switched bearer and patch it into the multi= media session. In fact there may be some really valid use cases where the d= evice that receives the CS setup is not the same device that negotiated the= CS session using SDP. Think of a webex type conference where you connect i= nto a conference using SIP and then get the conference bridge to call you b= ack with a PSTN call to your POTS phone - Manual acceptance seems fine to m= e in this case and automatic correlation will not work. Similarly an intern= et gaming session established using SIP might call the user back at his PO= TS line for audio conversations associated with the game. One possibility is to state in the draft that if you cannot confirm that th= e CS call is part of the session negotiated using SDP using a correlation m= echanism or some other means you MUST NOT accept the CS bearer as part of t= he session without manual user acceptance. I am Ok for the callerid correlation mechanism to be made mandatory to impl= ement. I think this is the mechanism with the least burden for implementati= ons and also the one most likely to work. I do not agree that the DTMF and = the UUI should be mandatory to implement. I also think it should be realized that implementations may only support on= e direction for the CS call establishment and that the endpoints only need = to support the aspects of the correlation mechanism for the direction(s) th= ey support. Also some users might also not wish to be a passive party (such= as when calling party pays for example when cellular roaming) even if they= have the capability to do so. Thus some implementations may only support t= he aspects of the correlation mechanism for the direction (active or passiv= e) that they support. Andrew From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Flemming Andreasen Sent: Friday, August 09, 2013 6:10 PM To: mmusic Subject: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protoco= l Action: 'Session Description Protocol (SDP) Extension For Setting Audio a= nd Video Media Streams Over Circuit-Switched Bearers In The Public Switched= Telephone Network (PSTN)' to Propos... Greetings MMUSIC As you can see per the below, the IESG approved the Circuit-Switched Bearer= s draft for publication, however before doing so, they requested a couple o= f changes. The resulting approved document can be found at http://tools.iet= f.org/html/draft-ietf-mmusic-sdp-cs-21 One of the changes introduced resulted in all 3 correlation mechanisms now = being mandatory-to-implement (previously they were not): Implementations MUST support the three correlation mechanisms specified in Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4, and SHOULD include all supported mechanisms the initial Offer. Since this is a non-trivial change that has not been discussed by the WG (a= nd we know of at least one person having expressed concerns with it off-lin= e), we are hereby solicting the WG participants for input on changes introd= uced as a result of the IESG review with a focus on the above. In doing so,= please keep in mind that we are developing standards that work in the gene= ral Internet. The following URL provides a diff-file showing the changes resulting from t= he IESG review: http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sdp-cs-18.txt&ur= l2=3Ddraft-ietf-mmusic-sdp-cs-21.txt Comments are due by August 23 (two weeks from today) Thanks -- Flemming (MMUSIC co-chair) -------- Original Message -------- Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For= Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The= Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf= -mmusic-sdp-cs-21.txt) Date: Mon, 1 Jul 2013 11:56:23 -0700 From: The IESG To: IETF-Announce CC: mmusic chair , mmusic mailing list , RFC E= ditor The IESG has approved the following document: - 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ *Technical Summary * The document describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Publich Switched Telephone Network (PSTN) *Working Group Summary * The WG had some discussion around the format to use for E.164 numbers and whether to align this with the existing definition in RFC 3108. The RFC 3108 definition was seen as deficient and the WG agreed it was better to align with relevant parts of the tel URI format defined in RFC 3966, not least since SDP address types are defined in the context of a particular network type, and hence RFC 3108 compatibility is not a concern (the implication is that the "E164" address type may differ between network types in SDP). *Document Quality * There are currently no known implementations of the draft, however the draft is a dependency for 3GPP, so future implementations are expected. The document has received good overall review in the WG, some of which resulted in changes to the detailed specification. The document has been reviewed in detail several times, including of the last few versions. The major contributors to these as well as earlier discussions are listed in the Acknowledgements section of the document. *Personnel * Document Shepherd: Flemming Andreasen Responsible AD: Gonzalo Camarillo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic . --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_7D2F7D7ADBA812449F25F4A69922881C1844F6ESESSMB203ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks

 <= /p>

I’d like to support= Andrew on this topic.

 <= /p>

I don’t know if bun= dling these attributes together in one draft was done just for convenience = or of there are other reasons. What is clear is that these three attributes were not related initially.

 <= /p>

3GPP has no use of all at= tributes as explained by Andrew. I hope that this late change can be revert= ed (or modified in a less radical way) and the draft completed soon.

 <= /p>

3GPP has been waiting for= completion of this draft for long now. I think we can assume that there ar= e implementations in the field, thus these last minute changes may cause problems.

 <= /p>

Please also consider that= the 3GPP-feature using this draft is “IMS Centralized Service Contro= l”. This feature is part of 3GPP Rel-8, a release that was completed from 3GPP point if view by June 2008.

 <= /p>

Thanks<= /p>

/atle

 <= /p>

________________________________


Atle Monrad
3GPP CT Chairman

Group Function Technology – Standardization and Technical Regulation<= /span>
Ericsson

 

 <= /p>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Andrew Allen
Sent: 21. august 2013 19:31
To: Flemming Andreasen; mmusic
Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [F= wd: Protocol Action: 'Session Description Protocol (SDP) Extension For Sett= ing Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN)' to Propo

 

In my view since= including all the correlation attributes in the SDP is a SHOULD strength i= mplementing all the correlation attributes should  also be of SHOULD s= trength or at most MUST implement except when it is known that a particular correlation mechanism will work for the= deployment scenario that  circuit-switched bearer is used. It seems t= o me kind of silly to have a MUST implement (but might not ever try and use= requirement).

 

To my knowledge = 3GPP are currently the only party interested in using this draft. To publis= h this draft with mandatory aspects which are not needed and not acceptable= to 3GPP application will in my view be a mistake and result in an RFC that will either not be implemented or w= ill not be implemented as written because the overhead of implementing the = DTMF and UUI correlation mechanisms is not justified and since these are no= t needed in the 3GPP use case and will not work with the 3GPP architecture either.

 

In the 3GPP appl= ication of this draft the negotiation of the circuit-switched bearer does n= ot take place end to end between the terminals but instead between the term= inal and an IMS network infrastructure component (the SCC AS) that acts as B2BUA and the CS call is then interwor= ked to SIP and patched in with the session with the remote party. In additi= on the E.164 number provided by the IMS network infrastructure component is= unique for that circuit-switched bearer setup so no additional correlation mechanism is really needed. The = Mobile terminal always acts as the active party in establishing the circuit= switched bearer in the 3GPP scenario.

 

Mandating the ca= llerid mechanism for correlation is acceptable to me since it basically has= no impact on the mobile terminal or the IMS network infrastructure compone= nt except the inclusion of the cs-correlation attribute and the inclusion of that by the interworking MSC in the P-Asser= ted-Identity (which is already done). It may have the advantage that now th= e IMS network infrastructure component does not have to allocate a unique E= .164 number for each session but could just use the callerid for the correlation. I think this also does me= an that the SCC AS can then be sure that the CS session setup is coming fro= m the terminal  that was negotiated it in the O/A exchange and not som= e attacker trying to hijack sessions using as the dialed number an E.164 number that was previously assigned to= him. Also since in the 3GPP scenario the circuit-switched network is local= to and under the control of the operator the callerid mechanism can be gua= ranteed to work.

 

The DTMF and UUI= mechanisms are quite intensive to implement and both have issues for the 3= GPP application. DTMF will result in a delay in the setup end to end of the= media and also would require media to be routed to the IMS network infrastructure component (which is only a = signaling B2BUA) and force it to have to support  DTMF tone detection.= UUI will almost certainly not work as most operators switchers do not pass= this information and also would require support for the CUSS UUI mechanisms to deliver the UUI in SIP from the int= erworking switch to the SCC AS.

 

I am not against the end to end use of = CS SDP but I think it does have some issues such as the cost of long distan= ce or even international circuit switched bearers when the only leg that is a problem is the access for one mobile user. Also a devic= e that needs to use circuit switched bearers cannot do so with those device= that don’t also support CS SDP or that also have access to a circuit= -switched connection. So I don’t think the correlation issues with end to end use are the primary obstacles to su= ccessful interoperability. One way to address the interoperability issues i= s an architecture like 3GPP's where the circuit-switched bearer is negotiat= ed between the device and an interworking function at the edge of the network which is where the quality problem exi= sts in the first place not to set up a CS call end to end.

 

In my view it is not the end of the wor= ld if in some scenarios the user has to manually accept the circuit switche= d bearer and patch it into the multimedia session. In fact there may be some really valid use cases where the device that receives th= e CS setup is not the same device that negotiated the CS session using SDP.= Think of a webex type conference where you connect into a conference using= SIP and then get the conference bridge to call you back with a PSTN call to your POTS phone – Manual= acceptance seems fine to me in this case and automatic correlation will no= t work. Similarly an internet  gaming session established using SIP mi= ght call the user back at his POTS line for audio conversations associated with the game.

 

One possibility is to state in the draf= t that if you cannot confirm that the CS call is part of the session negoti= ated using SDP using a correlation mechanism or some other means you MUST NOT accept the CS bearer as part of the session without man= ual user acceptance.

I am Ok for the callerid correlation mechanism to be made mandatory to impl= ement. I think this is the mechanism with the least burden for implementati= ons and also the one most likely to work. I do not agree that the DTMF and = the UUI should be mandatory to implement.

 

I also think it should be realized that= implementations may only support one direction for the CS call establishme= nt and that the endpoints only need to support the aspects of the correlation mechanism for the direction(s) they support. Also some = users might also not wish to be a passive party (such as when calling party= pays for example when cellular roaming) even if they have the capability t= o do so. Thus some implementations may only support the aspects of the correlation mechanism for the directio= n (active or passive) that they support.

 

Andrew

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: Friday, August 09, 2013 6:10 PM
To: mmusic
Subject: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: = Protocol Action: 'Session Description Protocol (SDP) Extension For Setting = Audio and Video Media Streams Over Circuit-Switched Bearers In The Public S= witched Telephone Network (PSTN)' to Propos...

 

Greetings MMUSIC

As you can see per the below, the IESG approved the Circuit-Switched Bearer= s draft for publication, however before doing so, they requested a couple o= f changes. The resulting approved document can be found at http://t= ools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21

One of the changes introduced resulted in all 3 correlation mechanisms now = being mandatory-to-implement (previously they were not):
<quote>

&n=
bsp;  Implementations MUST support the three correlation mechanisms
&n=
bsp;  specified in Section 5.2.3.2, Section 5.2.3.=
3 and Section 5.2.3.4,
&n=
bsp;  and SHOULD include all supported mechanisms the initial Offer.

</quote>
Since this is a non-trivial change that has not been discussed by the WG (a= nd we know of at least one person having expressed concerns with it off-lin= e), we are hereby solicting the WG participants for input on changes introd= uced as a result of the IESG review with a focus on the above. In doing so, please keep in mind that we are de= veloping standards that work in the general Internet.


The following URL provides a diff-file showing the changes resulting from t= he IESG review:
    http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sdp-cs-18.txt&ur= l2=3Ddraft-ietf-mmusic-sdp-cs-21.txt

Comments are due by August 23 (two weeks from today)

Thanks

-- Flemming (MMUSIC co-chair)



-------- Original Message --------

Subjec= t:

[MMUSIC] Protocol Action: 'Session Description Proto= col (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-= Switched Bearers In The Public Switched Telephone Network (PSTN)' to Propos= ed Standard (draft-ietf-mmusic-sdp-cs-21.txt)

Date: =

Mon, 1 Jul 2013 11:56:23 -0700

From: =

The IESG = <iesg-secretary@ietf.org>

To:

IETF-Announce <ietf-announce@ietf.org>

CC:

mmusic chair <mmusic-chairs@tools.ietf.org>, mmusic mailing list <mmusic@ietf.org>, RFC Editor = <rfc-editor@rfc-editor.org>

 

The IESG has approved the following document:
- 'Session Description Protocol (SDP) Extension For Setting Audio and<=
o:p>
   Video Media Streams Over Circuit-Switched Bearers In The =
Public
   Switched Telephone Network (PSTN)'
  (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard
 
This document is the product of the Multiparty Multimedia Session Cont=
rol
Working Group.
 
The IESG contact persons are Gonzalo Camarillo and Richard Barnes.
 
A URL of this Internet Draft is:
=
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/

 


 


 


 


*Technical Summary


*


 


The document describes use cases, requirements, and protocol extension=
s


for using the Session Description Protocol (SDP) Offer/Answer model fo=
r


establishing audio and video media streams over circuit-switched beare=
rs


in the Publich Switched Telephone Network (PSTN)


 


*Working Group Summary


*


 


The WG had some discussion around the format to use for E.164 numbers<=
o:p>


and whether to align this with the existing definition in RFC 3108. Th=
e


RFC 3108 definition was seen as deficient and the WG agreed it was


better to align with relevant parts of the tel URI format defined in R=
FC


3966, not least since SDP address types are defined in the context of =
a


particular network type, and hence RFC 3108 compatibility is not a


concern (the implication is that the "E164" address type may=
 differ


between network types in SDP).


 


*Document Quality


*


 


There are currently no known implementations of the draft, however the=



draft is a dependency for 3GPP, so future implementations are expected=
.


 


The document has received good overall review in the WG, some of which=



resulted in changes to the detailed specification. The document has be=
en


reviewed in detail several times, including of the last few versions.<=
o:p>


The major contributors to these as well as earlier discussions are


listed in the Acknowledgements section of the document.

 


 


*Personnel


*


 


Document Shepherd: Flemming Andreasen


Responsible AD: Gonzalo Camarillo 


_______________________________________________


mmusic mailing list


mmusic@ietf.org

https://www.i=
etf.org/mailman/listinfo/mmusic


.


 


 

 

-------------------= --------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

--_000_7D2F7D7ADBA812449F25F4A69922881C1844F6ESESSMB203ericsso_-- From ron.even.tlv@gmail.com Thu Aug 22 07:02:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F8521F8B12 for ; Thu, 22 Aug 2013 07:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrmFlnVAxZld for ; Thu, 22 Aug 2013 07:02:42 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 80EAE21F866E for ; Thu, 22 Aug 2013 07:02:42 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t60so1730617wes.31 for ; Thu, 22 Aug 2013 07:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=mG8I/03+G0NCW5fDlzUkjYKoqOm9Ksx8mxj55uXsXc0=; b=l7NOPNmf9I/oPCWFJ/Vtn2sVZ+Omh/YBsmqe35Su6alvQ9QHbZOgaq8rXqJeZHAy2C mbCV/6WKBvKwNDOX9N3B9UBNlIrx4jwVA0tJgFVv8dYk2x1IvWwEr5MfwDMtCxPCyeAy nm+RDw58tTTB+qFtJlTNc8tfvC3P5A3doSVbUxaojZZFYeRUrD91RXZkFndUz0s+wjXq uSIXP8vm64mJKUAUuxaSzEdHm8pbsE5+RhjOq7nes/jZtNF/O4E61t6bgLmsuYbUBZR0 8WHQxp/NXF4xo9+MVuJTFEGeMvr6s7DuB6rNgo9GfGgljlA0+QHaFbM93fu1TtRhjwHM WWVg== X-Received: by 10.180.207.84 with SMTP id lu20mr2673934wic.50.1377180159329; Thu, 22 Aug 2013 07:02:39 -0700 (PDT) Received: from RoniE (bzq-109-67-221-133.red.bezeqint.net. [109.67.221.133]) by mx.google.com with ESMTPSA id v9sm38382732wiw.8.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Aug 2013 07:02:38 -0700 (PDT) From: "Roni Even" To: "'Cullen Jennings \(fluffy\)'" , References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> In-Reply-To: Date: Thu, 22 Aug 2013 17:00:16 +0300 Message-ID: <038601ce9f3f$efe855a0$cfb900e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHhSi4rMF59GtWVZLm6eUv/wmHmTAG3YjvyAXHa8loCRvWqfgHvq+67AYZd+3cDIYzBf5kbrEdA Content-Language: en-us Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 14:02:43 -0000 Hi, Based on this thread and the proposal in Adam's MMSUIC unified proposal we will write a document that will update RFC3551 and outline the available ranges. We will check if we need any comment to the closed RTP Payload types (PT) for standard audio and video encodings . This will be done in AVTcore based on the conclusion from the MMUSIC session in Berlin Roni Even AVTcore co-chair > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Cullen Jennings (fluffy) > Sent: 21 May, 2013 5:51 PM > To: mmusic@ietf.org WG > Cc: payload@ietf.org > Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC > 5761? > > > On May 13, 2013, at 2:03 AM, Magnus Westerlund > wrote: > > > I also think you should check with IANA if one can touch a closed > > registry at all, or if we are restricted to clarifying notes for the > > registry. > > If we have consensus for the change and IESG approval, I think we can do > whatever we want to the IANA registries. If we want a totally different > format for the registry, we can do that - we just need a draft that updates > the previous RFC that defined the registries. > > However, I agree with Keith the registry is for code point allocation, not > explaining life to implementors. If we need an information RFC to summarize > and explain all the info to implementors, that would be easy to publish if > someone wrote it. > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From mzanaty@cisco.com Thu Aug 22 13:06:12 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A645311E8201 for ; Thu, 22 Aug 2013 13:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YoFwYK103JO for ; Thu, 22 Aug 2013 13:06:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D301E11E81C5 for ; Thu, 22 Aug 2013 13:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12111; q=dns/txt; s=iport; t=1377201967; x=1378411567; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EQhXFtUp4lkqZl6x2wa5YFlzyseQLEh+2H0fC4CSXzo=; b=DtOKL7cuZBBOckq2tP1NHJ4SBDloCVjm7wpqmYcSXl/XgXtxCvOBtTIx EFpPVYEXU2U9RxS1cSZwpEZDaPY8zmW3/0qSDBwt+v8FRNND60Rc8rVXW dgdHvuIWnkLHRZ66Liqlco3ZaXCbxf29KktAhjDmGwgs/OIn3WnkdbnHO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAMBuFlKtJV2a/2dsb2JhbABagkNENVGtSpJAgR0WdIIkAQEBBC1MEAIBCA4DBAEBCx0HMhQJCAIEAQ0FCId2Aw+3E41tgkgxBgGDG3sDlX6OGYUpgx+CKw X-IronPort-AV: E=Sophos;i="4.89,935,1367971200"; d="scan'208,217";a="250653606" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 22 Aug 2013 20:06:06 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7MK66G5028059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 20:06:06 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.38]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 15:06:06 -0500 From: "Mo Zanaty (mzanaty)" To: Roni Even , "'Jonathan Lennox'" , "'Bernard Aboba'" Thread-Topic: [MMUSIC] RFC 6190 Single Session Transport Thread-Index: AQJ680PtyCDXIknXog+yt3k+QmtJ0gEe3FNKAgCnf3gCFUU8LQNTIcKFmAQHXVCAALK6sA== Date: Thu, 22 Aug 2013 20:06:05 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D508265@xmb-rcd-x14.cisco.com> References: , <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com>, <3AD93742-DBA4-4EDD-80AD-A667994ECE8D@vidyo.com> <034a01ce9f16$bc2d8600$34889200$@gmail.com> In-Reply-To: <034a01ce9f16$bc2d8600$34889200$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.28.99] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D508265xmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RFC 6190 Single Session Transport X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 20:06:12 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D508265xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Selective forwarding of layers at a switch is simpler with MST versus SST, = since SST requires rewriting timestamps and sequence numbers to drop layers= . RTCP reporting per layer is another benefit of MST. These advantages stem= from using multiple SSRCs independent of whether they use the same or sepa= rate transport flows. I think the entire nomenclature of SST/MST should evolve to Single/Multiple= SSRC (not Session) Transport, since that is really what matters. BUNDLE an= d UP make this evolution inevitable. Note that MST is already widely deploy= ed this way, which is non-standard. So updating the nomenclature would ali= gn with both current deployments and future standards like BUNDLE/UP. Mo From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Roni Even Sent: Thursday, August 22, 2013 5:05 AM To: 'Jonathan Lennox'; 'Bernard Aboba' Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RFC 6190 Single Session Transport Hi Jonathan, Maybe if you want to use FEC only on the base layer and not on all layers. Roni From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Jonathan Lennox Sent: 19 July, 2013 5:54 PM To: Bernard Aboba Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RFC 6190 Single Session Transport On Jul 18, 2013, at 10:02 PM, Bernard Aboba > wrote: Jonathan said: "I don't understand how single-session multi-source transmission will work = without either a) signaling "a=3Dssrc-group DDP" decoding dependencies, or = b) making various implementation-specific assumptions about the structure o= f the SVC streams." [BA] In terms of SDP choices for expressing layering within a single m line= , you can either go the a=3Dssrc-group:DDP route, or use distinct payload t= ypes for each layer and RFC 5583 a=3Dgroup:DDP (this is what "Unified Plan"= Section 4.7 appears to advocate). I'm not sure how "MST within a single session" could be expressed in SDP wi= thout BUNDLE. Was the idea to use multiple m lines and group them together= but use the same port? I think the authors of RFC 6190 didn't see a use case for MST within a sing= le RTP session -- all of the interesting MST use cases they saw involved se= parate transport flows for the separate layers, and if you're sending all t= he layers on a single transport flow, SST is significantly simpler. What requirement are you trying to achieve that's met by MST in a single se= ssion, but not by SST? -- Jonathan Lennox jonathan@vidyo.com --_000_3879D71E758A7E4AA99A35DD8D41D3D91D508265xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Selective forwarding of layers at a swi= tch is simpler with MST versus SST, since SST requires rewriting timestamps= and sequence numbers to drop layers. RTCP reporting per layer is another benefit of MST. These advantages stem from using multiple= SSRCs independent of whether they use the same or separate transport flows= .

 

I think the entire nomenclature of SST/= MST should evolve to Single/Multiple SSRC (not Session) Transport, since th= at is really what matters. BUNDLE and UP make this evolution inevitable. Note that MST is already widely deployed this way, which is no= n-standard. So  updating the nomenclature would align with both curren= t deployments and future standards like BUNDLE/UP.

 

Mo

 

 

From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Thursday, August 22, 2013 5:05 AM
To: 'Jonathan Lennox'; 'Bernard Aboba'
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RFC 6190 Single Session Transport

 

Hi Jonathan,

Maybe if you want to use = FEC only on the base layer and not on all layers.

Roni

 <= /p>

From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Lennox
Sent: 19 July, 2013 5:54 PM
To: Bernard Aboba
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RFC 6190 Single Session Transport

 

 

On Jul 18, 2013, at 10:02 PM, Bernard Aboba <bernard_aboba@hotmail.com> = wrote:

 

Jonathan said: 

"I don't understand how single-session multi-source= transmission will work without either a) signaling "a=3Dssrc-group DD= P" decoding dependencies, or b) making various implementation-specific assumptions about the structure of the SVC streams."
 
[BA] In terms of SDP choices for expressing layering within a single m line= , you can either go the a=3Dssrc-group:DDP route, or use distinct payload t= ypes for each layer and RFC 5583 a=3Dgroup:DDP (this is what "Unified = Plan" Section 4.7 appears to advocate).  

I'm not sure how "MST within a single session" could be expressed= in SDP without BUNDLE.  Was the idea to use multiple m lines and grou= p them together but use the same port? 

 

I think the authors of RFC 6190 didn't see a use cas= e for MST within a single RTP session -- all of the interesting MST use cas= es they saw involved separate transport flows for the separate layers, and = if you're sending all the layers on a single transport flow, SST is significantly simpler.

 

What requirement are you trying to achieve that's me= t by MST in a single session, but not by SST?

 

--

Jonathan Lennox
jonathan@vidyo.com

 

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D508265xmbrcdx14ciscoc_-- From magnus.westerlund@ericsson.com Fri Aug 23 01:38:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240BA11E82D2 for ; Fri, 23 Aug 2013 01:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.298 X-Spam-Level: X-Spam-Status: No, score=-105.298 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVk5erbsGPSa for ; Fri, 23 Aug 2013 01:38:19 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C7C2C11E8173 for ; Fri, 23 Aug 2013 01:38:10 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-6d-52171f6f306a Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 91.69.22048.F6F17125; Fri, 23 Aug 2013 10:38:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.2.328.9; Fri, 23 Aug 2013 10:38:06 +0200 Message-ID: <52171FA3.9040905@ericsson.com> Date: Fri, 23 Aug 2013 10:38:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+JvjW6+vHiQwcZVMhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo+u52wF53kqDjYtYmtgXMnVxcjJISFgInH1w2R2CFtM4sK9 9WwgtpDAYUaJn5Piuxi5gOxljBLvu6+ygCR4BbQlWvsugdksAqoSE1r7mUBsNgELiZs/GsGa RQWCJdq3f2WDqBeUODnzCVi9iIC6ROvmPlYQW1jAW+Lfm7OsEIslJbYtOgZ2BLOAnsSUqy2M ELa8RPPW2cwQB2lLNDR1sE5g5J+FZOwsJC2zkLQsYGRexciem5iZk15uvokRGE4Ht/w22MG4 6b7YIUZpDhYlcd7NemcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTD6zPyw+Y1E0f8k1pku 8x1bSi5eLBPO217qf5rPa6ma1c7un3MUznrLVm+trUoNubrEk9umhvuQTvoj2yMp7TOP1HkX /YpR0hO5ob7O/bq2b9P/uwWqf0Ok2vbr6CoLb5LyPXNsfmfbL4d+c7cH7/n2tO1usAtztt7U LVubosMvt0/DyukckxJLcUaioRZzUXEiAJbF8Ff1AQAA Subject: [MMUSIC] RTSP 2.0: Inconsistent identifiers between Range and Accept-Ranges X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 08:38:26 -0000 WG, One of Elwyn's comments are in regards to the lack of IANA registry for new Accept-Ranges formats. My immediate reaction is that should not be needed as range formats are common between the Range and Accept-Ranges header. But, then I checked our definitions are realized that we have made a blunder to not reuse the range identifiers from Range in Accept-Ranges. To resolve this issue we either can do two things. 1) Change the Accept-Ranges header to use the Range header identifiers. This will affect any implementations of Accept-Ranges header and the values it uses. Because Accept-Ranges has the following identifiers: Accept-Ranges: NPT SMPTE UTC While ranges has the following: Range: npt, smpte, smpte-30-drop, smpte-25, clock So in addition to being different there are actually more resolution in formats for Range header than in Accept ranges. 2) Define a registry and clarify the mapping between the accept-ranges identifiers and the Range ones. I personally think 1) is long term better. But, the question is how it affects any existing implementations of 2.0? Feedback much desired Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Aug 23 01:51:35 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF7E11E82E5; Fri, 23 Aug 2013 01:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.351 X-Spam-Level: X-Spam-Status: No, score=-105.351 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TalCClRElYpF; Fri, 23 Aug 2013 01:51:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F099711E82D2; Fri, 23 Aug 2013 01:51:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-e8-5217228cc16d Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4A.0D.16099.C8227125; Fri, 23 Aug 2013 10:51:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Fri, 23 Aug 2013 10:51:22 +0200 Message-ID: <521722BF.8010207@ericsson.com> Date: Fri, 23 Aug 2013 10:52:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Elwyn Davies References: <1370477514.4596.9052.camel@mightyatom> In-Reply-To: <1370477514.4596.9052.camel@mightyatom> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+JvjW6PkniQwY9ZlhYXvxxhtzh+YAe7 xdVXn1kspi5/zOLA4vH1ZDuLx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsftJRcH7woqz u18yNjA+jOpi5OCQEDCROLkltIuRE8gUk7hwbz1bFyMXh5DAYUaJz/OnsUA4yxklrr3sYAap 4hXQluiYMYMJxGYRUJU4P7WfEcRmE7CQuPmjkQ3EFhUIlmjf/pUNol5Q4uTMJywgtoiAmsTm rw8YQYYyC3QzSsx+dgFskLCAj8SWCavBioQEjCUef33PCmJzAl13t7WLFeI8SYlti46xg9jM AnoSU662MELY8hLNW2czQ/RqSzQ0dbBOYBSahWT3LCQts5C0LGBkXsXInpuYmZNebriJERjI B7f81t3BeOqcyCFGaQ4WJXHeTXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwGgpGdNe/ /furfYvdjhuOUWJTU41vam0yVlA2ONNVxCy1goVv0Ue3/tTAD/6f1n6sPLP/lXfHvf2T/zo3 ykZPTK6a+EBAYe1E7tWft/3jmhbInHTFb+1OK5uOT0szFF1+CIrG8s5LFVPc7GWh1irIU/7p RHr0NZaqHs9Cx/6pMTf3lW99ecpCiaU4I9FQi7moOBEAD+ZUZTICAAA= Cc: General Area Review Team , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 08:51:35 -0000 Hi, Continuing with the issues after Section 11. Once more a big thanks for the work you have put into this. It is really helpful, both from clarity point of view and finding some actual protocol issues. On 2013-06-06 02:11, Elwyn Davies wrote: > > s13.4.1, para 2: >> Upon receipt of the PLAY request, the server MUST position the normal >> play time to the beginning of the range specified in the received >> Range header > > Should this mention the caveat that (if I understood earlier statements > correctly) the server may not be able to deliver exactly on this MUST > and then sets it the nearest it can manage? This is borne out by the > example later in this section where the server sets the start point back > 10ms (and says so), etc. Seek-Style affects the interpreation of MUST! Yes, I have added that this needs to happen ".. within the limits of the media resource and in accordance with the Seek-Style header (Section X.Y) ..". > > s13.4.4/.5/.7/.8: In these sections the Media-Property random access > property is stated as being required to be Random-Access. Is > Conditional Random Access a possible value for this property? The > confusion in s4.9.1 does not allow me to conclude that this shouldn't be > a value for the property (sorry for the double negative but this looks a > bit confused). These section lists the Media-Properties for the media resource one request delivery for. Thus from a PLAY request perspective using a Seek-Style: CoRAP header is fine for the ones that has Random Access property as Random-Access in these section. > > s13.5.1: Apologies if this question is stupid - I am not a media stream > wxpert. Suppose we have an aggregated stream with (say) a number of > recorded media items making up the aggregate. The client sets it on to > play to the end. What happens if not all the streams end at the same > time? Do we get PLAY_NOTIFY End-of-Stream notifications for each > individual stream as it ends or just one when the complete aggregate > ends? Not at all a stupid question. This should have been clearly specified for all usages of PLAY_NOTIFY in regards to aggregated sessions. Thus I have added both a general requirement on PLAY_NOTIFY level: PLAY_NOTIFY requests MAY use both aggregate control URI and individual media resource URIs depending on scope of the notification. This scope may have important distinctions for aggregated sessions, and each reason for a PLAY_NOTIFY request needs to specify the interpretation and if aggregated control URIs or individual URIs may be used in requests. And specified the following for end-of-stream: For RTSP Session where media resources under aggregated control the media resources will normally end at approximately the same time, although some small differences may exist, on the scale of a few hundred of milliseconds. In those cases a RTSP session under aggregated control SHOULD send only a single PLAY_NOTIFY request. By using the aggregate control URI in the PLAY_NOTIFY request the RTSP server indicates that this applies to all media resources within the session. In cases RTP is used for media delivery corresponding RTP-Info needs to be included for all media resources. In cases where one or more media resource has significantly shorter duration than some other resources in the aggregated session the server MAY send end-of-stream notifications using individual media resource URIs to indicate to agents that there will be no more media for this particular media resource related to the current active PLAY request. In such cases when the remaining media resources comes to end-of-stream they MUST send a PLAY_NOTIFY request using the aggregate control URI to indicate that no more resources remains. And the following for Media-Properties-Update The Media-Properties header has session scope, thus for aggregated sessions the PLAY_NOTIFY request MUST be using the aggregated control URI. And for Scale-Change PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated control URI in the request. The scale change for any aggregated session do apply to all media streams part of the aggregate. > > s13.5.2, para 2: >> that changes the basis for making >> estimates on how the media range progress. > I can't parse the last part of this and I am not sure what it should be. I hope this is better This notification MUST be sent for media that are Time-Progressing every time an event happens that changes the basis for making estimates on how the available for play-back media range will progress with wall clock time. > > s14: What happens if the upper layer PDU is longer than (2^16 - 1)? I have added this note: Note that this mechanism does not support larger PDUs than 65535 bytes, which is the same that regular IPv4 and IPv6 is capable. If the media delivery protocol intended to be used has larger PDUs than that, the definition of such mechanisms usage of this mechanism will require the definition of a PDU fragmentation mechanism. > > s18.10, private para: Is there any way in RTSP for the cache to know > whether this is a private cache for the user that should cache this > content? To my understanding this is something the cache itself knows through its behavior and deployment. > s18.10, last para: I am not absolutely certain, but I think this para > is specific to the max-age cache type rather than being generic as > implied by the indentation. [If so use the trick > to provide a pseudo-paragraph break] Yes, you are correct. I did the equally easy choice for hanging lists to simply make a new paragraph without any paragraph text. > s18.14: Consider adding the 'identity' value explicitly to the ABNF. If I understand you correctly what you are requesting is that "identity" is listed as an construct in the content-coding ABNF construction that are used by Accept-Encoding and Content-Encoding headers. Accept-Encoding = "Accept-Encoding" HCOLON [ encoding *(COMMA encoding) ] encoding = codings [SEMI accept-params] codings = content-coding / "*" content-coding = "identity" / token Content-Encoding = "Content-Encoding" HCOLON content-coding *(COMMA content-coding) > > s18.29, para 2: Are (or should there be) constraints on the ordering of > media ranges for a non-continuous media stream? It would probably make > the client's job easier if they were in incresing order. This is a interesting question. If one simply expresses what pieces of media that are currently available then using a requirement that the first ranges end-time must be prior any of the subsequent ranges start times would work. However, my head gets stuck on considering when desired playback is non linear. But that is probably a higher function question. So a possible addition after this existing sentence: The server MAY include more than one range specification of any given time format to indicate media that has non-continuous range. would be: The range specifications shall be ordered with the range with the lowest value or earliest start time first, followed by ranges with increasingly higher values or later start time. Comments on this? > s18.41: It appears from a literal interpretation (the third sentence is > an unqualified MUST) that the responder has to respond with error code > 551 and an (empty?) list of Unsupported features if it actually does > support all the features. I suspect this is not what is wanted. Correct, reformulated proposal is: In case any of the feature-tags listed by the Require header are not supported by the server or client receiving the request, it MUST respond to the request using the error code 551 (Option Not Supported) and include the Unsupported header listing those feature-tags which are NOT supported. > s18.45, para 4: Harummph! Political Correctness strikes again. Every > protocol should (and probably does) have a CRAP policy. ;-) Yes, the lower case o is silent here ;-). > > s18.52, 'setup' section: There seems to be some inconsistency in the > spcification of the 'active/passive/actpass' values. a) Is there some > reason for specifying them in square brackets? Not, that I can remember. Removing both brackets and quotes. b) should they say > ["active:"] or ["active":] - both formats are used? The ABNF has the > plain words with no brackets or quotes. The later would be correct, but now it will only say active: The ABNF is clear that it will be RTP/SAVPF/TCP;unicast;setup=active;connection=new > > 18.52, 'connection' section, 1st line: > s/Clients use the setup parameter/Clients use the connection parameter/ > (I assume). Had to tweak that sentence a bit more: Clients use the connection parameter in a transport specification part of the Transport header in a SETUP request, to indicate the client's preference for either reusing an existing connection between client and server (in which case the client sets the "connection" parameter to "existing"), or requesting the creation of a new connection between client and server (in which cast the client sets the "connection" parameter to "new"). > > s21.1, transfer of sensitive info: Is there an equivalent of the Referer > header in RTSP? Not sure there is but it would be good to explain one > way or the other (either there isn't one so it's less of a problem or > this is the equivalent...) Yes, the Referer header is retained also in RTSP. > > s21.1, DNS Spoofing: Presumably RTSP will interact significantly with > content delivery networks. Some of these work by DNS 'spoofing' that > was in its infancy when RFC 2616 was published. Are there any other > issues that come out of the greater prevalence of CDNs since 1999? I have no experience with large scale deployment of RTSP. To my knowledge there hasn't been the same development with CDNs for RTSP as HTTP. This I think is dependent on several factors. One has been the issues with deploying RTSP on global scale due to NAT traversal etc, instead progressive download and HTTP adaptive streaming has mostly taken this market. Thus most large scale deployments has been in contexts within single operators providing Video On Demand services etc. Thus, I don't really know of any additional issues around this. > > s21.1, Session Hijacking: The last part of this is written so that it > appears to mandate authentication in all cases. As far as I understand > it is up to the client to decide if it needs authentication etc and some > content will be offered on unsecured URIs. I think this needs to be > clearer that authentication will mitigate the problem but whether it is > done is up to the client if the server doesn't care. Is this better? Another choice for preventing session hijacking is to use client authentication and only allow the authenticated client creating the session to access that session. > > s21.1, Persistently suspicious behaviour: There seems to be a mismatch > between the title (persistently..) and the first sentence (a single > instance). Do we have examples of the sort of security risk which is > supposed to be met with a 403 response the first time? Yes, it is a bit inconsistent. I propose: Suspicious behavior: RTSP servers upon detecting intances of behavior which is deemed a security risk SHOULD return error code 403 (Forbidden). RTSP servers SHOULD also be aware of attempts to probe the server for weaknesses and entry points and MAY arbitrarily disconnect and ignore further requests from clients which are deemed to be in violation of local security policy. > > s21.1, last sentence: >> Some of the above threats are such that >> the implementation of the RTSP functionality itself needs to consider >> which policy and strategy it uses to mitigate them. > It strikes me that this is not very helpful to a prospective > implementer. The point of this section is at least in part to provide > that policy and strategy. I am not quite sure how to rewrite this (or > if indeed other people think it does need rewriting). No, it is not helpful in other ways then, you need to think about this and consider what mitigations you think should be implemented and how that affects your implementation design. For now I am leaving this as it is. > s22.3: The rules about allocating in the sections above x50 should be > explained here (see s8.1.1). The numbers below x50 in each section > should be marked as a special category of reserved so they are only > allocated to HTTP analogues. Is an experimental/private segment in each > category desirable? Yes I think adding something like the below to at least make clear the intention that RTSP specific status codes should first be registered in the x50-x99 range. New RTSP functionality requiring Status Codes should first be registered in the range x50-x99. Only when the range is full should registrations be done in the x00-x49 range, unless it is to adopt an HTTP extension also to RTSP. The reason is to enable any HTTP extension to be adopted to RTSP without needing to renumber any related status codes. Regarding experimental and private I am very torn about such range. Unless someone else in the WG thinks this is worth the work I will leave it out. > > s22.9: Being allowed to register new Range header formats will currently > be restricted to times specified by NPT, SMPTE or UTC because no > registry is defined for Accept-Ranges. Is this what is intended? No, the intention is that Range header format registry is shared between Range and Accept-Ranges. However, I see the description is not clear on this and needs to be amended. I have sent a separate email on this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From christer.holmberg@ericsson.com Fri Aug 23 03:39:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE7911E80F7 for ; Fri, 23 Aug 2013 03:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqcJE5qRmvOU for ; Fri, 23 Aug 2013 03:39:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B5E6011E80E7 for ; Fri, 23 Aug 2013 03:39:39 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-fb-52173be7f186 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 19.78.22048.7EB37125; Fri, 23 Aug 2013 12:39:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Fri, 23 Aug 2013 12:39:35 +0200 From: Christer Holmberg To: mmusic Thread-Topic: DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. Thread-Index: Ac6f7OG1P0YUwhF6Remol1dqLcLlOQ== Date: Fri, 23 Aug 2013 10:39:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C47762C@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_7594FB04B1934943A5C02806D1A2204B1C47762CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvje4La/Egg59BFlOXP2ZxYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG5z/nWQq6djJWfP7wg7mB8dt8xi5GTg4JAROJyUcnQNliEhfu rWfrYuTiEBI4zCgxa/ERVghnCaPE9M79LF2MHBxsAhYS3f+0QRpEBGQk9m7azAxSIyxwiFHi 6txpYA0iAscZJT5+f8YEUaUncXPPLXYQm0VAVWLunSdgNq+Ar8TCznnMIDYj0Orvp9aA1TML iEvcejKfCeIkAYkle84zQ9iiEi8f/2OFsBUl2p82MELU50scu70RaqagxMmZT1gmMArNQjJq FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG9tzEzJz0cvNNjMDgP7jlt8EO xk33xQ4xSnOwKInzbtY7EygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMTRpk+rXU5u3HLn3 WUnjxoK4/XyKZmK2HzesrN+7OTn48M0CyQ8K/40Evxz984WPM1/+Nd8au1dHzhvqVG0KnJb1 fHn6LKXs2hk7flhbrtVvuF/mdTA2NFRZeooA917F+Bdf1uzTkFpf4KO9xvq2Ji/XR6tFil2M 6dP22HDcU5z+9upWN+spf5VYijMSDbWYi4oTAR6SZ4RMAgAA Subject: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 10:39:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C47762CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the open issues related to BUNDLE presented in Berlin (Q5 in my slid= es) was whether, once a BUNDLE address is re-negotiated (i.e. the usage of = BUNDLE etc has already been negotiated), it is allowed to assign the new su= ggested BUNDLE address to all "m=3D" lines immediately, instead of doing th= e 2-step Offer/Answer procedure. The outcome was that it shall be allowed. So, based on that, I am suggesting the change below to section 6.1.4 of BUN= DLE. NOTE that this only applies to the case where a BUNDLE address is RE-negoti= ated (e.g. in a re-INVITE). There is still a discussion about the initial O= ffer, and that outcome of that (and the outcome of the UP discussions) may = obviously also impact the text. But, let's keep that separate for now, and = only focus on the case when a BUNDLE address is RE-negotiated :) Regards, Christer ------------------------------------------- OLD TEXT (BUNDLE-04): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6.4.1. SDP Offerer Bundle Address Request and Usage An Offerer can assign a BUNDLE address to multiple "m=3D" lines in a BUNDLE group, once the Answerer has selected the BUNDLE address for the Offerer. An Offerer MUST NOT assign a BUNDLE address to multiple "m=3D" lines until the Answerer has selected the BUNDLE address. OPEN ISSUE: Should it be allowed to assign a new BUNDLE address to multiple "m=3D" lines in a BUNDLE group, before the Answerer has selected the BUNDLE address? In order to negotiate (or, to re-negotiate) the BUNDLE address associated with a BUNDLE group, the Offerer, in the SDP Offer, assigns a unique address to each "m=3D" line in the BUNDLE group. In addition, the Offerer indicates which unique address it wishes the Answerer to select as the Offerer's BUNDLE address. The Offerer places the mid, associated with the unique address requested to be selected as the BUNDLE address, first in the SDP group:BUNDLE attribute mid list. The Answerer will then select the BUNDLE address for the Offerer ([ref-to-be-added]). If the Offerer, in a subsequent SDP Offer, wants to re-negotiate the BUNDLE address associated with a BUNDLE group, it MAY assign the previously negotiated BUNDLE address as a unique address to one of the "m=3D" lines in the BUNDLE group. If the Offerer assigns the previously selected BUNDLE address to more than one "m=3D" line in a BUNDLE group, the first mid in the SDP group:BUNDLE attribute mid list MUST represent an "m=3D" line to which the BUNDLE address is assigned. Hence, in order to re-negotiate the BUNDLE address, the Offerer needs to assign a unique address to each "m=3D" line in the BUNDLE group, as described above. An Offerer MUST NOT assign a BUNDLE address to an "m=3D" line that is not associated with a BUNDLE group. An Offerer MUST NOT assign a BUNDLE address, that has been negotiated for a BUNDLE group, to an "m=3D" line that is associated with another BUNDLE group. Section 10.1 shows an example of a Bundle Address Request. SUGGESTED NEW TEXT: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 6.4.1. SDP Offerer Bundle Address Request and Usage An Offerer can assign a BUNDLE address to multiple "m=3D" lines in a BUNDLE group, once the Answerer has selected the BUNDLE address for the Offerer. An Offerer MUST NOT assign a BUNDLE address to multiple "m=3D" lines until the Answerer has selected the BUNDLE address. Before the Answerer has selected a BUNDLE address for the Offerer, in order to negotiate the BUNDLE address associated with a BUNDLE group, the Offerer, in the SDP Offer, assigns a unique address to each "m=3D" line in the BUNDLE group. In addition, the Offerer indicates which unique address it wishes the Answerer to select as the Offerer's BUNDLE address. The Offerer places the mid, associated with the unique address requested to be selected as the BUNDLE address, first in the SDP group:BUNDLE attribute mid list. The Answerer will then select the BUNDLE address for the Offerer ([ref-to-be-added]). If an Offerer, in a subsequent SDP Offer, wants to re-negotiate the BUNDLE address associated with a BUNDLE group, it can either: - Assign the requested new BUNDLE address to all "m=3D" lines in the BUNDLE group; or - In the same way as described in the procedures above, assign a unique address to each "m=3D" line in the BUNDLE group (the previously negotiated BUNDLE address can also be assigned as a unique address to one of the "m=3D" lines in the BUNDLE group). In both cases, the Offerer places the mid, associated with the unique address requested to be selected as the BUNDLE address, first in the SDP group:BUNDLE attribute mid list (if the requested new BUNDLE address is assigned to all "m=3D" lines in the BUNDLE group, all mids in the SDP group:BUNDLE attribute mid list will represent that same address). An Offerer MUST NOT assign a BUNDLE address to an "m=3D" line that is not associated with a BUNDLE group. An Offerer MUST NOT assign a BUNDLE address, that has been negotiated for a BUNDLE group, to an "m=3D" line that is associated with another BUNDLE group. Section 10.1 shows an example of a Bundle Address Request. --_000_7594FB04B1934943A5C02806D1A2204B1C47762CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One of the open issues related to BUNDLE presented i= n Berlin (Q5 in my slides) was whether, once a BUNDLE address is re-negotia= ted (i.e. the usage of BUNDLE etc has already been negotiated), it is allow= ed to assign the new suggested BUNDLE address to all “m=3D” lines immediately, instead of doing the = 2-step Offer/Answer procedure. The outcome was that it shall be allowed.

 

So, based on that, I am suggesting the change below = to section 6.1.4 of BUNDLE.

 

NOTE that this only applies to the case where a BUND= LE address is RE-negotiated (e.g. in a re-INVITE). There is still a discuss= ion about the initial Offer, and that outcome of that (and the outcome of t= he UP discussions) may obviously also impact the text. But, let’s keep that separate for now, and only foc= us on the case when a BUNDLE address is RE-negotiated :)

 

Regards,

 

Christer

 

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

 

OLD TEXT (BUNDLE-04):

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

 

6.4.1.  SDP Offerer Bundle Address Request and Usage<= o:p>

 

   An Offerer can assign a BUNDLE address to mul= tiple "m=3D" lines in a

   BUNDLE group, once the Answerer has selected = the BUNDLE address for

   the Offerer.  An Offerer MUST NOT assign= a BUNDLE address to multiple

   "m=3D" lines until the Answerer has= selected the BUNDLE address.

 

   OPEN ISSUE: Should it be allowed to assign a = new BUNDLE address to

   multiple "m=3D" lines in a BUNDLE g= roup, before the Answerer has

   selected the BUNDLE address?

 

   In order to negotiate (or, to re-negotiate) t= he BUNDLE address

   associated with a BUNDLE group, the Offerer, = in the SDP Offer,

   assigns a unique address to each "m=3D&q= uot; line in the BUNDLE group.  In

   addition, the Offerer indicates which unique = address it wishes the

   Answerer to select as the Offerer's BUNDLE ad= dress.  The Offerer

   places the mid, associated with the unique ad= dress requested to be

   selected as the BUNDLE address, first in the = SDP group:BUNDLE

   attribute mid list.  The Answerer will t= hen select the BUNDLE address

   for the Offerer ([ref-to-be-added]).

 

   If the Offerer, in a subsequent SDP Offer, wa= nts to re-negotiate the

   BUNDLE address associated with a BUNDLE group= , it MAY assign the

   previously negotiated BUNDLE address as a uni= que address to one of

   the "m=3D" lines in the BUNDLE grou= p.

 

   If the Offerer assigns the previously selecte= d BUNDLE address to more

   than one "m=3D" line in a BUNDLE gr= oup, the first mid in the SDP

   group:BUNDLE attribute mid list MUST represen= t an "m=3D" line to which

   the BUNDLE address is assigned.  Hence, = in order to re-negotiate the

   BUNDLE address, the Offerer needs to assign a= unique address to each

   "m=3D" line in the BUNDLE group, as= described above.

 

   An Offerer MUST NOT assign a BUNDLE address t= o an "m=3D" line that is

   not associated with a BUNDLE group.  An = Offerer MUST NOT assign a

   BUNDLE address, that has been negotiated for = a BUNDLE group, to an

   "m=3D" line that is associated with= another BUNDLE group.

 

   Section 10.1 shows an example of a Bundle Add= ress Request.

 

 

 

SUGGESTED NEW TEXT:

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

 

6.4.1.  SDP Offerer Bundle Address Request and Usage

 


   An Offerer can assign a BUNDLE address to multiple "=
m=3D" lines in a


   BUNDLE group, once the Answerer has selected the BUNDLE a=
ddress for


   the Offerer.  An Offerer MUST NOT assign a BUNDLE ad=
dress to multiple


   "m=3D" lines until the Answerer has selected th=
e BUNDLE address.


 


   Before the Answerer has selected a BUNDLE address for the=
 Offerer,


   in order to negotiate the BUNDLE address associated with =
a BUNDLE 


   group, the Offerer, in the SDP Offer, assigns a uniq=
ue address to 


   each "m=3D" line in the BUNDLE group. In a=
ddition, the Offerer indicates 


   which unique address it wishes the Answerer to selec=
t as the 


   Offerer's BUNDLE address. The Offerer places the mid=
, associated 


   with the unique address requested to be selected as =
the BUNDLE address, 


   first in the SDP group:BUNDLE attribute mid list.&nb=
sp; The Answerer will 


   then select the BUNDLE address for the Offerer ([ref=
-to-be-added]).


 


   If an Offerer, in a subsequent SDP Offer, wants to re-neg=
otiate the


   BUNDLE address associated with a BUNDLE group, it can eit=
her:


 


-    Assign the requested new BUNDLE address to all “m=3D” line=
s in the 


BUNDLE group; or


-    In the same way as described in the procedures above, assign a 


unique address to each “m=3D”=
 line in the BUNDLE group (the previously 


negotiated BUNDLE address can also be ass=
igned as a unique address 


to one of the “m=3D” lines in=
 the BUNDLE group).


 


   In both cases, the Offerer places the mid, associated wit=
h the unique 


   address requested to be selected as the BUNDLE addre=
ss, first in the 


   SDP group:BUNDLE attribute mid list (if the requeste=
d new BUNDLE address 


   is assigned to all “m=3D” lines in the B=
UNDLE group, all mids in the SDP 


   group:BUNDLE attribute mid list will represent that =
same address).


 


   An Offerer MUST NOT assign a BUNDLE address to an "m=
=3D" line that is


   not associated with a BUNDLE group.  An Offerer MUST=
 NOT assign a


   BUNDLE address, that has been negotiated for a BUNDLE gro=
up, to an


   "m=3D" line that is associated with another BUN=
DLE group.


 


   Section 10.1 shows an example of a Bundle Address Request=
.


 
--_000_7594FB04B1934943A5C02806D1A2204B1C47762CESESSMB209erics_-- From christer.holmberg@ericsson.com Fri Aug 23 03:53:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC45111E80E7 for ; Fri, 23 Aug 2013 03:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.16 X-Spam-Level: X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[AWL=-1.562, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfGwmNSkYkOm for ; Fri, 23 Aug 2013 03:53:00 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A363A21F9C70 for ; Fri, 23 Aug 2013 03:52:57 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-6c-52173f078407 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A6.48.25272.70F37125; Fri, 23 Aug 2013 12:52:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Fri, 23 Aug 2013 12:52:55 +0200 From: Christer Holmberg To: mmusic Thread-Topic: DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration Thread-Index: Ac6f7ikjB1DJ6cLXRlGYV8ZqhT4gnQ== Date: Fri, 23 Aug 2013 10:52:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C47766D@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_7594FB04B1934943A5C02806D1A2204B1C47766DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjS6HvXiQwRpti6nLH7M4MHosWfKT KYAxissmJTUnsyy1SN8ugStjyw6dgiU2Fe2TWxkbGK+bdDFyckgImEjcnfiVBcIWk7hwbz1b FyMXh5DAUUaJJx0dLBDOEkaJX1NnATkcHGwCFhLd/7RBGkQEZCT2btrMDGILCyRI/PhxlhEi nipxum8tO4StJ3GvdR0TiM0ioCpx48kWsGW8Ar4S0/c0g8UZgRZ/P7UGzGYWEJe49WQ+E8RB AhJL9pxnhrBFJV4+/scKYStKtD9tYISoz5c4090LNVNQ4uTMJywTGIVmIRk1C0nZLCRlEHEd iQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR3FqcVJuupHBJkZg0B/c8ttiB+PlvzaHGKU5 WJTEebfonQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKgiZR+gdFPyolCgpOG77OW9byWM 5swW3nntytnUYi/BZ1Jaqe/0N65h1XWRXz2F9Vt7kO0vvYWSZ/sZ1/EcnFjytc583YvNlb7T A5gWnGtgC23x0Gac/1TXuVdTb5rASgtrRd3rW9gYDqo2Sqwr1zQ9uWPO10VaHCzZWf+/Rt8M dItySroarMRSnJFoqMVcVJwIANrhiHlIAgAA Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 10:53:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C47766DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the open issues related to BUNDLE presented in Berlin (Q1, Q2 and Q7= in my slides) was regarding the usage of any given PT value. My take of the outcome was that: - We agreed that any given PT value can only be used for a single = codec configuration (Q1) - We agreed that we need some definition text for "codec configura= tion" (Q2) - We agreed that, within a BUNDLE group, any given PT value can be= used in multiple m- lines, as long as it is used for a single codec config= uration (Q7). Jonathan Lennox promised to suggest some definition text for "codec configu= ration", so let's wait for that until we go into those discussions. But, if you have any issues with the agreements in general, please bring th= em up :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C47766DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One of the open issues related to BUNDLE presented i= n Berlin (Q1, Q2 and Q7 in my slides) was regarding the usage of any given = PT value.

 

My take of the outcome was that:

 

-     &= nbsp;    We agreed that any given PT value can only b= e used for a single codec configuration (Q1)

-     &= nbsp;    We agreed that we need some definition text = for “codec configuration” (Q2)

-     &= nbsp;    We agreed that, within a BUNDLE group, any g= iven PT value can be used in multiple m- lines, as long as it is used for a= single codec configuration (Q7).

 

Jonathan Lennox promised to suggest some definition = text for “codec configuration”, so let’s wait for that un= til we go into those discussions.

 

But, if you have any issues with the agreements in g= eneral, please bring them up :)

 

Regards,

 

Christer

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C47766DESESSMB209erics_-- From magnus.westerlund@ericsson.com Fri Aug 23 06:53:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CA911E817A; Fri, 23 Aug 2013 06:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.673 X-Spam-Level: X-Spam-Status: No, score=-103.673 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYp7vYN7diGQ; Fri, 23 Aug 2013 06:53:43 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7B08211E81A4; Fri, 23 Aug 2013 06:53:42 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-46-5217696389fb Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D8.D9.25272.36967125; Fri, 23 Aug 2013 15:53:39 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Fri, 23 Aug 2013 15:53:38 +0200 Message-ID: <52176998.5000101@ericsson.com> Date: Fri, 23 Aug 2013 15:54:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Elwyn Davies References: <1370477514.4596.9052.camel@mightyatom> <51C85D02.1050907@ericsson.com> <1372164466.4524.9526.camel@mightyatom> In-Reply-To: <1372164466.4524.9526.camel@mightyatom> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+JvjW5ypniQwa/TohYXvxxhtzh+YAe7 xdVXn1kspi5/zOLA4vH1ZDuLx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsXHLJKaCnWkV e3+sZm5gbA7oYuTkkBAwkfg1s4cRwhaTuHBvPVsXIxeHkMBRRonDs0+wQzjLGCVWzNjPClLF K6At0b5iAwuIzSKgKjHn2XF2EJtNwELi5o9GNhBbVCBYon37VzaIekGJkzOfgNWLCKhJbP76 gBFkKLNAN6PE7GcXmEASwgJhEvO2dIPZQgI1Es9a7oAN5QQ6b/2aJhaI8yQlti06BhZnFtCT mHK1hRHClpdo3jqbGaJXW6KhqYN1AqPQLCS7ZyFpmYWkZQEj8ypGjuLU4qTcdCODTYzAcD64 5bfFDsbLf20OMUpzsCiJ827ROxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVEna7bC54Pi b1ie1RdNKL/OtkpqJcsyVXf2t3qnN8/lZvZNmtqs9Xfqc8cFBjv2LznMyPnuUPv0WeqKTc85 jy9Vsq7aHdy0emWf6NZL8VWXf4dldUw/lm0XL5bnJXh2tp1vj0oXh51cTfmPXdJ7bfQLpW2b 7997HhHOblv2NWX95CDG/vZ7skosxRmJhlrMRcWJALC5bf81AgAA Cc: General Area Review Team , draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 13:53:49 -0000 Hi, Now getting to implement your response in our source. Some few additional comments or notes below. On 2013-06-25 14:47, Elwyn Davies wrote: > > On Mon, 2013-06-24 at 16:51 +0200, Magnus Westerlund wrote: >> Elwyn, >> >> Follow up on some of the nits that is not simply to implement or where I >> disagree or want to provide feedback. >> >> This email covers all issues up to and including Section 11. That is as >> far as I have managed to process them yet. I will now handle over the >> rest of this list to my co-authors. >> >> On 2013-06-06 02:11, Elwyn Davies wrote: >>> >>> >>> ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified >>> values "smpte", "npt" and "clock" are valid in the Range parameter. >>> What is the meaning of such an unqualified value? >> >> You are correct about that the basic definition in ABNF allows for >> empty. The reason for this is the following stated in Section 18.38: >> >> It MAY be >> included in GET_PARAMETER requests from the client to the server with >> only a Range format and no value to request the current media >> position, whether the session is in Play or Ready state in the >> included format. >> > Two points: > - A suggestion: Make ss4.4/4.5/4.6 into subsections of a new s4.4. Add > a bit of text in the new s4.4 saying that the range specifiers are used > in the RANGE header and pointing to s18.38 for the unqualified use. > (consistent with s2.7 which gives usage). > - An issue I hadn't spotted: I haven't checked but are the unqualified > values allowed in the SDP extension case (s20.3)? >> >> I think your suggestion is a good one and I have written such a section, initial proposal below: 4.4. Media Time Formats RTSP currently supports three different media time formats defined below. Additional time formats may be specified in the future. These time formats can be used with the Range header (Section 18.38) to request playback and specify at which media position protocol requests actually will or has taken place. They are also used in description of the media's properties using the Media-Range header (Section 18.29). The format identifier only are used in Accept- Ranges header (Section 18.5) to declare supported time formats and also in the Range header (Section 18.38) to request the time format used in the response. 4.4.1. SMPTE Relative Timestamps Regarding the SDP a=range attribute. The ABNF allows the unqualified usage. The textual specification of a=range attribute in D.1.6 is silent on unqualified usage. The only usage of unqualified usage in a=range would be to indicate that although this media has unknown or time-progressing properties it does support the time formats for the a=range with unqualified values that has been included. >> >>> >>> s10.2, para 6 and following note: I can't see that the note following >>> para 6 can be justified: since the restriction on multiple connections >>> from a client to a server is only a SHOULD, an interoperable server MUST >>> be capable of handling multiple connections from a client unless the >>> server can explicitly send back a TOO MANY CONNECTIONS status. >> >> See separate email > > Should I have had this already? It was sent to the MMUSIC WG mailing list on the 24th of June. I have forwarded if to you personally. > >> >>> >>> s10.6: RFC 3986 has capability for dealing with IP versions beyond 6... >>> should these be carried over into RTSP? The IANA registry says they are. >> >> I am uncertain what you want here? Yes, the URI format allows for future >> definitions of literal IP address versions. However, RTSP does contain >> explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP >> versions will require some extension definition to function. > > Perhaps an excess of zeal on my behalf. Perhaps a (non-normative) note > saying what you just wrote: 'Although the general URI format envisages > potential future new versions of the literal IP address, usage of any > such new version would require other modifications to the RTSP > specofication (e.g., ...[any relevant section(s)]).' Yes, I added such text. >> >>> >>> s10.7, last para: Should the doubling of the wait timer have an upper limit? >> >> Yes, I added an upper limit of 30 minutes. This is way beyond what any >> human will accept, only robots will keep on going at this timeout value. >> And I think that is large enough to avoid any issues. > > Agreed > >> >> I also propose to clarify the range for the variations and added the >> classical 0.5 to 1.5 times the deterministic value. >> >> Text proposal. >> >> That timer MUST be doubled for each additional failure to connect or >> receive response until the value exceeds 30 minutes when the timers >> deterministic value may be set to 30 minutes. It is RECOMMENDED to not > ^^^^^^^^^^^^^ > base? >> set the same value in the timer for each scheduling, but instead to add >> a variation to the mean value, resulting in picking a random value >> within the range of 0.5 to 1.5 of the mean value. This has gotten changed a bit more and currently reads: A more complex case may arise when a load balancing RTSP proxy is in use, i.e., where an RTSP proxy is used to select amongst a set of RTSP servers to handle the requests, or when multiple server addresses are available for a given server name. The proxy or client may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) from one of its RTSP servers or proxies, or a TCP timeout (if the server is even unable to handle the request message). The proxy or client simply retries the other addresses or configured proxies, but may also receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) response or TCP timeouts from those addresses. In such a situation, where none of the RTSP servers/proxies/addresses can handle the request, the RTSP agent has to wait before it can send any new requests to the RTSP server. Any additional request to a specific address MUST be delayed according to the Retry-After headers received. For addresses where no response was received or TCP timeout occurred, an initial wait timer SHOULD be set to 5 seconds. That timer MUST be doubled for each additional failure to connect or receive response until the value exceeds 30 minutes when the timers mean value may be set to 30 minutes. It is REQUIRED to not set the same value in the timer for each scheduling, but instead to add a variation to the mean value, resulting in picking a random value within the range of 0.5 to 1.5 of the mean value. >> >>> >>> s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed >>> are 'defined' in this draft. The nearest thing to a definition of >>> play.basic that I can find is the last sentence of para 4 in this >>> section. I am not convinced that I could produce an interoperable >>> implementation of a server with this feature-tag with the one sentence >>> 'definition'. References to where play.xxx are defined would be useful >>> (play.scale in s18.44, play.speed in s18.48). >>> >> >> Hmmm, the other feature-tags than play.basic are pretty straightforward >> and well contained. play-basic is really a minimal RTSP server >> implementation according to the whole spec for media playback. >> >> This can probably be more clearly expressed somewhere, but it can't >> really be enumerated. Then we are back to the issue we had with RFC 2326 >> minimal implementation list that was incomplete and lacked a lot of >> things really necessary. >> >> This issue still haven't resulted in any changes to our source. > > Ah! I see I have (re-)opened a can of worms! One thought for providing > the proverbial larger can into which the worms can be stuffed back: > > Define 'play.basic' as the default that you get back if none of the > others apply. How's that for weasel words! After my leave I have written a bit of definition for play.basic: 11.1. Feature Tag: play.basic The play.basic feature tag represents an RTSP implementation according to all normative RTSP protocol features specified in this specification. This specification is both a RTSP core specification as well intended to enable setup and control of playback of media. Thus following all normative parts in the main sections (the ones with numbers), not the appendices (starting with letters), unless explicitly specified in a main section for being a required appendix. Note: This feature tag does not mandate any media delivery protocol, such as RTP. In RTSP 1.0 there was a minimal implementation section. However, that was not consistent with the rest of the specification. So rather than making an attempt to explicitly enumerate the features for play.basic this specification have to be read in completeness and the necessary features normatively defined as being required are included. >> >> >>> s11, Supported (and Proxy-Supported) bullets: >>> OLD: >>> This results in the >>> receiver is learning the requester's feature support. >>> NEW: >>> This results in the >>> receiver learning the requester's feature support >>> relevant to the specified resource. >>> [Note: I added 'specified resource' here and then thought about whether >>> this made any sense. It probably needs to be clearer what set of >>> features are included in the Supported list for both requester and >>> responder. Are they restricted to those relevant to the specified >>> resource that might of course be the whole server, proxy - or client?? - >>> in which case there isn't an issue, but it might be a specific >>> presentation - what happens then? Affects s13.1, para 3 also.] >> >> Actually, I don't think it is specific to the media resource. The issue >> with making it specific to a media resource is that a RTSP client needs >> to be able to look into the future and supply an answer for a media >> resource it may not yet know sufficient to provide a tailored response >> for. I think it is simpler and better to provide general capabilities in >> the supported header and then later determine how well they apply for >> the media resource itself. > > So maybe make it clear that feature support returned is just what the > responder can do generally and is not specific to the URI provided. Yes, I have tried to make it clear that it is not resource specific. Supported: This header is used to determine the complete set of functionality that both client and server have in general and is not dependent on specific resource. The intended usage is to determine before one needs to use a functionality that it is supported. It can be used in any method, but OPTIONS is the most suitable one as it at the same time determines all methods that are implemented. When sending a request the requester declares all its capabilities by including all supported feature-tags. This results in the receiver is learning the requester's feature support. The receiver then includes its set of features in the response. Proxy-Supported: This header is used similarly to the Supported header, but instead of giving the supported functionality of the client or server it provides both the requester and the responder a view of the common functionality supported in general by all members of the proxy chain between the two supports and not dependent on the resource. Proxies are required to add this header whenever the Supported header is present, but proxies may also add it independently of the requester. I also added variations of this sentence to the Supported and Proxy-Supported headers description: These feature tags are the ones the server or client support in general, and is not specific to the request resource. > > Either that or make the request valid only for non-specific URIs (i.e. > at the server/client level) if that is possible (not sure how that would > work for server asking client if that is allowed). Doesn't really work as supported is intended to be possible to add to any request to determine the functionality supported by the replying agent. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tireddy@cisco.com Sun Aug 25 23:42:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DEB11E8165 for ; Sun, 25 Aug 2013 23:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiBlUaGdiQEN for ; Sun, 25 Aug 2013 23:42:46 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8411E8130 for ; Sun, 25 Aug 2013 23:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2814; q=dns/txt; s=iport; t=1377499366; x=1378708966; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=kvj+Ut0TR7U/0tKEMl5TxXk/ZWQoMsHOs2Cbhc2P6Ss=; b=PxyDmhBEdNJn39oeJ9jO85k1yYd5I/C5rX9pihsMvzImWhCy0jcpnhi2 FCRAP/hC1kxgv/bJux651HtZgNJ9+5zy/yrlWpDSV0QZoytsVUcMyOr0T sAX5RnMZMeQ3bSanL831iEa+EK9Ya5LRNHq7jVeZqqiV4YwxkdGCc1WvQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYGANj3GlKtJXG9/2dsb2JhbABagwc1SwaDJ7xrF4EJFm0HgiQBAQEEIxETMA4GAQgRBAEBAwIGHQMCBDAUAQYBAQUFBBMIAYd4BwWWNo5/hAiNdYEpjx4WKIJiNH0DmRuQNIMegio X-IronPort-AV: E=Sophos;i="4.89,956,1367971200"; d="scan'208";a="251628751" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 26 Aug 2013 06:42:45 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7Q6gjLS025051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Aug 2013 06:42:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 01:42:45 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-02.txt Thread-Index: AQHOobGUnhOktz0LA0udxKThEjYwSZmmH+qg Date: Mon, 26 Aug 2013 06:42:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1903180B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.62.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [MMUSIC] FW: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 06:42:51 -0000 VXBkYXRlZCB0aGUgSGFwcHkgRXllYmFsbHMgRXh0ZW5zaW9uIGZvciBJQ0UgQWxnb3JpdGhtIGlu IHNlY3Rpb24gNCBvZiB0aGUgZHJhZnQgYmFzZWQgb24gdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZy b20gdGhlIFdHIHRvIHVwZGF0ZSB0aGUgY2FuZGlkYXRlIHByaW9yaXR5IA0Kc3VjaCB0aGF0IHNv bWUgc2VydmVyLXJlZmxleGl2ZSBjYW5kaWRhdGVzIGhhdmUgaGlnaGVyIHByaW9yaXR5IHRoYW4g c29tZSBJUHY2IGhvc3QgY2FuZGlkYXRlcy4NCg0KQ29tbWVudHMgYW5kIFN1Z2dlc3Rpb25zIGFy ZSB3ZWxjb21lLg0KDQotQXV0aG9ycy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBTdW5kYXksIEF1Z3VzdCAyNSwgMjAxMyAxMDowOSBQTQ0KVG86IFRpcnVt YWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBEYW4g V2luZyAoZHdpbmcpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXJlZGR5LW1tdXNpYy1pY2UtaGFwcHktZXllYmFsbHMtMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXJlZGR5LW1tdXNpYy1pY2UtaGFwcHktZXllYmFsbHMtMDIudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQg cG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXJlZGR5 LW1tdXNpYy1pY2UtaGFwcHktZXllYmFsbHMNClJldmlzaW9uOgkgMDINClRpdGxlOgkJIEhhcHB5 IEV5ZWJhbGxzIEV4dGVuc2lvbiBmb3IgSUNFDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wOC0yNQ0K R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDcNClVSTDog ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVk ZHktbW11c2ljLWljZS1oYXBweS1leWViYWxscy0wMi50eHQNClN0YXR1czogICAgICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yZWRkeS1tbXVzaWMtaWNlLWhhcHB5 LWV5ZWJhbGxzDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXJlZGR5LW1tdXNpYy1pY2UtaGFwcHktZXllYmFsbHMtMDINCkRpZmY6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcmVkZHktbW11c2ljLWljZS1o YXBweS1leWViYWxscy0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IHJlcXVpcmVtZW50cyBmb3IgYWxnb3JpdGhtcyB0aGF0IG1ha2UgSUNFDQogICBjb25uZWN0aXZp dHkgY2hlY2tzIG1vcmUgcmVzcG9uc2l2ZSBieSByZWR1Y2luZyBkZWxheXMgaW4gZHVhbC1zdGFj aw0KICAgaG9zdCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyB3aGVuIHRoZXJlIGlzIGEgcGF0aCBm YWlsdXJlIGZvciB0aGUNCiAgIGFkZHJlc3MgZmFtaWx5IHByZWZlcnJlZCBieSB0aGUgYXBwbGlj YXRpb24gb3IgYnkgdGhlIG9wZXJhdGluZw0KICAgc3lzdGVtLiAgQXMgSVB2NiBpcyB1c3VhbGx5 IHByZWZlcnJlZCwgdGhlIHByb2NlZHVyZXMgaW4gdGhpcw0KICAgZG9jdW1lbnQgaGVscHMgYXZv aWQgdXNlci1ub3RpY2VhYmxlIGRlbGF5cyB3aGVuIHRoZSBJUHY2IHBhdGggaXMNCiAgIGJyb2tl biBvciBleGNlc3NpdmVseSBzbG93Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From pkyzivat@alum.mit.edu Tue Aug 27 06:42:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59D21E8094 for ; Tue, 27 Aug 2013 06:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+iogXDIS1jT for ; Tue, 27 Aug 2013 06:42:46 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id D307221E80B9 for ; Tue, 27 Aug 2013 06:42:45 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta14.westchester.pa.mail.comcast.net with comcast id HnSK1m00717dt5G5Epiluc; Tue, 27 Aug 2013 13:42:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Hpik1m0153ZTu2S3ZpikAf; Tue, 27 Aug 2013 13:42:45 +0000 Message-ID: <521CACD4.6060904@alum.mit.edu> Date: Tue, 27 Aug 2013 09:42:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C47762C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C47762C@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=q20121106; t=1377610965; bh=OJeGCeQibAnD5gq1Lqiz7Z+mF5DfMi8eYwzBpDxPwoM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JFcyy7NqMcSziUZMjC8mUiVmAM0xQ5VdYSMaEsk2o941xK8J7i4Gt9GIaHNV7wB4P trx+nG9o5pK6mMv9Vy9qzFyKo61rhJP4mVbG8jlijGEWT09fdDdZ0JKLTwg82tvEG0 5wlxqDM5SbZmW8j0WPVRtFYPb7LNq+EHHqGy0c7rn5hT1P4X/nyPvHUMIcJkdKOCUP EiH+7kXsybmg7OcXHkTrQc2M2kBxHakwHQd1sJP7WSY5kna8C3/4MvR9RBJZTqJQqI Krd0FidnRXPqZovxj8R2wMlxugMrXL/GkTvLu7/pH27RjJPWah2TdrYrYp78uOemxf Wj3eaztKIh+oQ== Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:42:51 -0000 This seems reasonable to me. Thanks, Paul On 8/23/13 6:39 AM, Christer Holmberg wrote: > Hi, > > One of the open issues related to BUNDLE presented in Berlin (Q5 in my > slides) was whether, once a BUNDLE address is re-negotiated (i.e. the > usage of BUNDLE etc has already been negotiated), it is allowed to > assign the new suggested BUNDLE address to all “m=” lines immediately, > instead of doing the 2-step Offer/Answer procedure. The outcome was that > it shall be allowed. > > So, based on that, I am suggesting the change below to section 6.1.4 of > BUNDLE. > > NOTE that this only applies to the case where a BUNDLE address is > RE-negotiated (e.g. in a re-INVITE). There is still a discussion about > the initial Offer, and that outcome of that (and the outcome of the UP > discussions) may obviously also impact the text. But, let’s keep that > separate for now, and only focus on the case when a BUNDLE address is > RE-negotiated :) > > Regards, > > Christer > > ------------------------------------------- > > OLD TEXT (BUNDLE-04): > > ==================== > > 6.4.1. SDP Offerer Bundle Address Request and Usage > > An Offerer can assign a BUNDLE address to multiple "m=" lines in a > > BUNDLE group, once the Answerer has selected the BUNDLE address for > > the Offerer. An Offerer MUST NOT assign a BUNDLE address to multiple > > "m=" lines until the Answerer has selected the BUNDLE address. > > OPEN ISSUE: Should it be allowed to assign a new BUNDLE address to > > multiple "m=" lines in a BUNDLE group, before the Answerer has > > selected the BUNDLE address? > > In order to negotiate (or, to re-negotiate) the BUNDLE address > > associated with a BUNDLE group, the Offerer, in the SDP Offer, > > assigns a unique address to each "m=" line in the BUNDLE group. In > > addition, the Offerer indicates which unique address it wishes the > > Answerer to select as the Offerer's BUNDLE address. The Offerer > > places the mid, associated with the unique address requested to be > > selected as the BUNDLE address, first in the SDP group:BUNDLE > > attribute mid list. The Answerer will then select the BUNDLE address > > for the Offerer ([ref-to-be-added]). > > If the Offerer, in a subsequent SDP Offer, wants to re-negotiate the > > BUNDLE address associated with a BUNDLE group, it MAY assign the > > previously negotiated BUNDLE address as a unique address to one of > > the "m=" lines in the BUNDLE group. > > If the Offerer assigns the previously selected BUNDLE address to more > > than one "m=" line in a BUNDLE group, the first mid in the SDP > > group:BUNDLE attribute mid list MUST represent an "m=" line to which > > the BUNDLE address is assigned. Hence, in order to re-negotiate the > > BUNDLE address, the Offerer needs to assign a unique address to each > > "m=" line in the BUNDLE group, as described above. > > An Offerer MUST NOT assign a BUNDLE address to an "m=" line that is > > not associated with a BUNDLE group. An Offerer MUST NOT assign a > > BUNDLE address, that has been negotiated for a BUNDLE group, to an > > "m=" line that is associated with another BUNDLE group. > > Section 10.1 shows an example of a Bundle Address Request. > > SUGGESTED NEW TEXT: > > =================== > > 6.4.1. SDP Offerer Bundle Address Request and Usage > > > > An Offerer can assign a BUNDLE address to multiple "m=" lines in a > > BUNDLE group, once the Answerer has selected the BUNDLE address for > > the Offerer. An Offerer MUST NOT assign a BUNDLE address to multiple > > "m=" lines until the Answerer has selected the BUNDLE address. > > > > Before the Answerer has selected a BUNDLE address for the Offerer, > > in order to negotiate the BUNDLE address associated with a BUNDLE > > group, the Offerer, in the SDP Offer, assigns a unique address to > > each "m=" line in the BUNDLE group. In addition, the Offerer indicates > > which unique address it wishes the Answerer to select as the > > Offerer's BUNDLE address. The Offerer places the mid, associated > > with the unique address requested to be selected as the BUNDLE address, > > first in the SDP group:BUNDLE attribute mid list. The Answerer will > > then select the BUNDLE address for the Offerer ([ref-to-be-added]). > > > > If an Offerer, in a subsequent SDP Offer, wants to re-negotiate the > > BUNDLE address associated with a BUNDLE group, it can either: > > > > - Assign the requested new BUNDLE address to all “m=” lines in the > > BUNDLE group; or > > - In the same way as described in the procedures above, assign a > > unique address to each “m=” line in the BUNDLE group (the previously > > negotiated BUNDLE address can also be assigned as a unique address > > to one of the “m=” lines in the BUNDLE group). > > > > In both cases, the Offerer places the mid, associated with the unique > > address requested to be selected as the BUNDLE address, first in the > > SDP group:BUNDLE attribute mid list (if the requested new BUNDLE address > > is assigned to all “m=” lines in the BUNDLE group, all mids in the SDP > > group:BUNDLE attribute mid list will represent that same address). > > > > An Offerer MUST NOT assign a BUNDLE address to an "m=" line that is > > not associated with a BUNDLE group. An Offerer MUST NOT assign a > > BUNDLE address, that has been negotiated for a BUNDLE group, to an > > "m=" line that is associated with another BUNDLE group. > > > > Section 10.1 shows an example of a Bundle Address Request. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From magnus.westerlund@ericsson.com Wed Aug 28 02:46:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063FF21F9A4C for ; Wed, 28 Aug 2013 02:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0chX+pqTqohE for ; Wed, 28 Aug 2013 02:46:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0485611E8119 for ; Wed, 28 Aug 2013 02:46:29 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-cb-521dc6a12cef Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6B.5D.22048.1A6CD125; Wed, 28 Aug 2013 11:45:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.328.9; Wed, 28 Aug 2013 11:45:05 +0200 Message-ID: <521DC6B5.6020801@ericsson.com> Date: Wed, 28 Aug 2013 11:45:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Elwyn Davies , "mmusic (E-mail)" References: <1370477514.4596.9052.camel@mightyatom> <51B1A95B.2030208@ericsson.com> <1370607960.4596.9114.camel@mightyatom> <51B1E8BD.80901@ericsson.com> <1370619602.4596.9175.camel@mightyatom> <51B585A7.7060109@ericsson.com> In-Reply-To: <51B585A7.7060109@ericsson.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje7nY7JBBhdn8llc2z2FyeL4gR3s FlOXP2ZxYPb4erKdxWPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgypjVfp+14HlFxaVZrg2M E2O7GDk5JARMJOY++soGYYtJXLi3Hsjm4hASOMwo8bPpJCuEs5xR4s6qFrAqXgFtidcfnjKB 2CwCqhJH3jcwg9hsAhYSN380gtWICgRLtG//ClUvKHFy5hMWEFtEwFti74cVYHFmgUSJE+ef AtkcHMICWhJztvtB7HrMKLGxfQc7SA2ngI7Ei6O3mSCuk5TYtugYO0SvnsSUqy2MELa8RPPW 2WA3CAHd1tDUwTqBUWgWktWzkLTMQtKygJF5FSN7bmJmTnq5+SZGYPge3PLbYAfjpvtihxil OViUxHk3650JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBozBuY6tPru9x7y9szM4tUlVVc ebulJE8EW0+P3dXyK//pwmPLXAJffD/H7TLRNzj34ZGcjZst/76xP6yycuJe25DZDBPPRoi9 29K+xMMof/XjbkXj9/ziusU7lRXEvV+F/zm/5FC5x9NTTHYWa+6c2rdTwzJmArfHhDsdmW+6 9Y52bxTf+W+qEktxRqKhFnNRcSIAmw3FuC0CAAA= Cc: "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" Subject: [MMUSIC] RTSP 2.0: Body format negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 09:46:40 -0000 WG, As a result of the below quoted discussion I have created a proposed text change to make the format negotiation more explicit and clear and linked to the RTSP methods that have need for it. The changes I have done in an attempt to address this can be summarized as: - Create a general negotiation description in a sub-section to the Message Body section - Updated GET_PARAMETER and SET_PARAMETER methods to reference this and be more explicit about handling request formats and returning the same format. - Mandate that anyone capable of responding to a GET_PARAMETER and SET_PARAMETER request MUST support text/parameters - Updating the Accept header to actually contain description of how you use it. Missed import from HTTP spec when removing reference. Please review these changes and provide comments. Actual text proposal below including whole sections: 9.3. Message Body Format Negotiation The content format of the message body is provided using the Content- Type header (Section 18.18). To enable the responder of a request to determine which media type it should use, the requestor may include the Accept header (Section 18.1) in a request to identify supported media types or media type ranges suitable to the response. In cases the responder is not supporting any of the specified formats, then the request response will be a 406 (Not Acceptable) error code. The media types that may be used on requests with message bodies needs to be determined through the use of feature-tags, specification requirement or trial and error. Trial and error works in the regards that in case the responder is not supporting the media type of the message body it will respond with a 415 (Unsupported Media Type). The formats supported and their negotiation is done individually on a per method and direction (request or response body) direction. Requirements on supporting particular media types for use as message bodies in requests and response SHALL also be specified on per method and direction basis. 13.8. GET_PARAMETER The GET_PARAMETER request retrieves the value of any specified parameter or parameters for a presentation or stream specified in the URI. If the Session header is present in a request, the value of a parameter MUST be retrieved in the specified session context. There are two ways of specifying the parameters to be retrieved. The first is by including headers which have been defined such that you can use them for this purpose. Headers for this purpose should allow empty, or stripped value parts to avoid having to specify bogus data when indicating the desire to retrieve a value. The successful completion of the request should also be evident from any filled out values in the response. The headers in this specification that MAY be used for retrieving their current value using GET_PARAMETER below. Additional headers MAY be specified in the future: o Accept-Ranges o Media-Range o Media-Properties o Range o RTP-Info The other way is to specify a message body that lists the parameter(s) that are desired to be retrieved. The Content-Type header (Section 18.18) is used to specify which format the message body has. If the receiver of the request is not supporting the media type used for the message body, it SHALL respond using the error code 415 (Unsupported Media Type). The responder to a GET_PARAMETER request MUST use the media type of the request for the response. For additional considerations regarding message body negotiation see Section 9.3. RTSP Agents implementing support for responding to GET_PARAMETER requests SHALL implement the text/parameters format (Appendix F). This to ensure that at least one known format for parameter are implemented and thus prevent parameter format negotiation failure. Parameters specified within the body of the message must all be understood by the request receiving agent. If one or more parameters are not understood a 451 (Parameter Not Understood) MUST be sent including a body listing these parameters that weren't understood. If all parameters are understood their values are filled in and returned in the response message body. The method MAY also be used without a message body or any header that requests parameters for keep-alive purpose. The keep-alive timer has been updated for any request that is successful, i.e., a 200 OK response is received. Any non-required header present in such a request may or may not have been processed. Normally the presence of filled out values in the header will be indication that the header has been processed. However, for cases when this is difficult to determine, it is recommended to use a feature-tag and the Require header. For this reason it is usually easier if any parameters to be retrieved are sent in the body, rather than using any header. Example: S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 431 User-Agent: PhonyClient/1.2 Session: 12345678 Content-Length: 26 Content-Type: text/parameters packets_received jitter C->S: RTSP/2.0 200 OK CSeq: 431 Session: 12345678 Server: PhonyServer/1.1 Date: Mon, 08 Mar 2010 13:43:23 GMT Content-Length: 38 Content-Type: text/parameters packets_received: 10 jitter: 0.3838 13.9. SET_PARAMETER This method requests to set the value of a parameter or a set of parameters for a presentation or stream specified by the URI. The method MAY also be used without a message body. It is the RECOMMENDED method to be used in a request sent for the sole purpose of updating the keep-alive timer. If this request is successful, i.e., a 200 OK response is received, then the keep-alive timer has been updated. Any non-required header present in such a request may or may not have been processed. To allow a client to determine if any such header has been processed, it is necessary to use a feature tag and the Require header. Due to this reason it is RECOMMENDED that any parameters are sent in the body, rather than using any header. When using a message body to list the parameter(s) that are desired to be set the Content-Type header (Section 18.18) is used to specify which format the message body has. If the receiver of the request is not supporting the media type used for the message body, it SHALL respond using the error code 415 (Unsupported Media Type). For additional considerations regarding message body negotiation see Section 9.3. RTSP Agents implementing support for responding to SET_PARAMETER requests SHALL implement the text/parameters format (Appendix F). This to ensure that at least one known format for parameters are implemented and thus prevent parameter format negotiation failure. A request is RECOMMENDED to only contain a single parameter to allow the client to determine why a particular request failed. If the request contains several parameters, the server MUST only act on the request if all of the parameters can be set successfully. A server MUST allow a parameter to be set repeatedly to the same value, but it MAY disallow changing parameter values. If the receiver of the request does not understand or cannot locate a parameter, error 451 (Parameter Not Understood) MUST be used. When a parameter is not allowed to change, the error code is 458 (Parameter Is Read-Only). The response body MUST contain only the parameters that have errors. Otherwise no body MUST be returned. The response body MUST use the media type of the request for the response. Note: transport parameters for the media stream MUST only be set with the SETUP command. Restricting setting transport parameters to SETUP is for the benefit of firewalls. The parameters are split in a fine-grained fashion so that there can be more meaningful error indications. However, it may make sense to allow the setting of several parameters if an atomic setting is desirable. Imagine device control where the client does not want the camera to pan unless it can also tilt to the right angle at the same time. Example: C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 421 User-Agent: PhonyClient/1.2 Session: iixT43KLc Date: Mon, 08 Mar 2010 14:45:04 GMT Content-length: 20 Content-type: text/parameters barparam: barstuff S->C: RTSP/2.0 451 Parameter Not Understood CSeq: 421 Session: iixT43KLc Server: PhonyServer/1.0 Date: Mon, 08 Mar 2010 14:44:56 GMT Content-length: 20 Content-type: text/parameters barparam: barstuff 18.1. Accept The Accept request-header field can be used to specify certain presentation description and parameter media types [RFC6838] which are acceptable for the response to DESCRIBE and GET_PARAMETER requests. See Section 20.2.3 for the syntax. The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The media-range MAY include media type parameters that are applicable to that range. Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1. Example of use: Accept: application/example ;q=0.7, application/sdp Indicates that the requesting agent prefers the media type application/sdp through the default 1.0 rating but also accepts the application/example media type with 0.7 quality rating. If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response. On 2013-06-10 09:52, Magnus Westerlund wrote: > On 2013-06-07 17:40, Elwyn Davies wrote: >> On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote: >> >>>> Appendix F: I missed that the text/parameter format appeared in the >>>> examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the >>>> definitions of these methods what encodings are acceptable for the >>>> message bodies that may go with these methods and their responses. >>> >>> Exactly, that is intentional. These methods can use anything that has a >>> MIME type. Also it has HTTP's mechanisms for determining what formats >>> one supports. >>> >>>> Clearly the new text/parameter MIME format is one. Is it the only one? >>> >>> It is the only one defined by IETF for this purpose. That is why it is >>> in the appendix so that RTSP users shall have something to define the >>> parameters they want in. However, they have to accept the limitations of >>> a basic text format. >>> >>>> I guess you could use a application/json or an XML format but I guess >>>> these would also either have to be called out explicitly in the method >>>> descriptions or put in as feature extensions. This needs to be >>>> clarified in the method descriptions (s13). The upshot of all this is >>>> that I think Appendix F needs to be pulled back into Section 20 as >>>> currently it is the only way to encode the message bodies. >>> >>> I can agree that the format negotiation for the bodies of >>> GET/SET_PARAMETER is not clear. I will look at proposing some >>> improvements of the text related to the handling of method bodies and >>> their format negotiation. >> Good. I don't see where the server tells what formats it accepts for >> either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say >> anything about SET_PARAMETER. AFAICS the client could tell the server >> what formats it accepts as a side-effect of DESCRIBE but that's a bit >> arcane - and it is not clear how you would separate the formats for >> DESCRIBE from those for GET_PARAM and SET_PARAM. > > Yes, I think this negotiation should happen on per methods basis. >>> >>> However, I am not pulling in Appendix F. It is an optional to use format >>> for parameter value pairs that can be used in these methods, it is not >>> required. Nor, does the specification define any parameters that are >>> transferred using this interface. The things that are in the appendix >>> are not core protocol, they represent either informational things, like >>> the examples and the state machine. The other appendices are normative >>> definitions of particular choices for things that can be combined or >>> used with RTSP, like RTP as media transport. >>> >> OK, it is possible to use GET_PARAM for basic requirements without using >> message bodies, so you can get away without defining a lowest common >> denominator format. However, the use of message bodies for SET_PARAM is >> RECOMMENDED so it seems a little odd not to ensure that server and >> client will have at least one format in common. (And its not as if we >> are dealing with a hugely complicated bit of spec for >> text/parameters! :-) ). Then, given the example in GET_PARAMETER it >> seems sensible to advise implementing text/parameters as the default for >> GET_PARAM also. > > Sure, I personally don't have any issue with making it at least SHOULD > implement text/parameters. But from my horizon a forward pointer with > the normative requirements is sufficient to accomplish that. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dwing@cisco.com Wed Aug 28 10:41:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDAA11E8210 for ; Wed, 28 Aug 2013 10:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrrvT1VLMacf for ; Wed, 28 Aug 2013 10:41:15 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 45B1511E8196 for ; Wed, 28 Aug 2013 10:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3930; q=dns/txt; s=iport; t=1377711675; x=1378921275; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fHDMLyzfGFNvuYKYEwxbueHgR8/grh2/U9djsGngju0=; b=EUgLg21RIsrWEBWaHbmcl/f92nhMengl1opAAU56w59MvgixWGL610P5 9ZKZRDKZfCvec+kCLzGw1eGGM2TMWpwL0PBgkG/LVB5V9LzTsNOQtuZXk RY5BMegfVWTvW0RzUk1FPGtNUFWicn2e7abc+dQaMso2qv0uT7aaS8z+B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAEY1HlKrRDoH/2dsb2JhbABbgwc1wHuBIBZ0giQBAQEDAQEBATctBwsFBwQLEQQBAQEnBycfCQgGE4d7BQ25To44eTMHBoMWfQOJM4pkg1qBLZA0g0AcgS4 X-IronPort-AV: E=Sophos;i="4.89,976,1367971200"; d="scan'208";a="87889523" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 28 Aug 2013 17:41:09 +0000 Received: from sjc-vpn7-327.cisco.com (sjc-vpn7-327.cisco.com [10.21.145.71]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7SHf7Nu032466; Wed, 28 Aug 2013 17:41:07 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4754A3@ESESSMB209.ericsson.se> Date: Wed, 28 Aug 2013 10:41:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <361F2B18-D0B3-487B-A534-8E8D4604561D@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1C46787F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4754A3@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) Cc: mmusic WG Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:41:20 -0000 On Aug 22, 2013, at 2:37 AM, Christer Holmberg = wrote: > Hi Dan, >=20 > Regarding the 3GPP SA3 study, the information I gave was a little = misleading. =46rom a security perspective SRTP would be fine. >=20 > The focus of the SA3 study was on how to provide security for the = existing fax transmission mechanism, which uses UDPTL/UDP. >=20 > 3GPP already mandates IMS terminals to support UDPTL/UDP for unsecure = fax. And, new terminals (supporting secure fax) are still required to = also support unsecure fax, in order to communicate with legacy terminals = when unsecure fax is sufficient.=20 >=20 > So, using UDPTL/DTLS/UDP for secure fax makes more sense, as it avoids = implementing different mechanisms for secure and unsecure fax - = UDPTL/DTLS/UDP only requires a new layer between UDPTL and UDP, it does = not require changing the upper layers (UDPTL and above). >=20 > Hopefully this clarifies :) (Sorry for my delay. I was on vacation.) Thanks for the clarification. Back to your document, it says: Since the DTLS record layer "application_data" packet does not indicate whether it carries UDPTL, or some other protocol, the usage of a dedicated DTLS association for transport of UDPTL needs to be negotiated, e.g. using the Session Description Protocol (SDP) [RFC4566] and the SDP offer/answer mechanism [RFC3264]. Therefore, this document specifies a new value [RFC4566] for the SDP "m=3D" line [RFC3264], in order to indicate UDPTL over DTLS = in SDP messages [RFC4566]. Have you considered doing UDPTL negotiation in the DTLS handshake = itself, using = http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg? That seems = ideally suited for indicating the application layer protocol, perhaps in = addition to the SDP signaling described in your I-D. -d >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: 19. elokuuta 2013 20:43 > To: Christer Holmberg > Cc: mmusic; mmusic-chairs@tools.ietf.org > Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 >=20 >=20 > On Aug 19, 2013, at 6:03 AM, Christer Holmberg = wrote: >=20 >> Hi, >>=20 >> We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, = which defines usage of UDPTL over DTLS, in order to provide secure fax. >>=20 >> The draft was previously submitted to DISPATCH. Based on discussions = with the ADs and chairs, it was decided that it shall be submitted to = MMUSIC (note that no DTLS extensions are needed). >>=20 >> As is indicated in the draft, 3GPP has performed a study on how to=20 >> provide secure fax in the IMS, and the outcome was that secure fax = shall be transported using UDPTL over DTLS. >=20 > Got a pointer to that study? Seems easier to carry UDPTL over RTP, = which would allow the RTP to be secured using SRTP (and thus the UDPTL = would be secured using SRTP). There is a spec floating around to do = exactly that (carry fax over RTP so that SRTP can secure it). Advantage = of using SRTP to secure fax is it separates the keying mechanism from = security, so that Security Descriptions / MIKEY / DTLS-SRTP / = whatever-is-invented-in-2020 will work just as effectively for voice as = for fax. And also that upgrading from a voice call to a "fax" call has = no additional complexities due to security ("please press START to begin = the fax transmission"). >=20 > -d >=20 >=20 >> However, there is nothing "3GPP/IMS specific" about the mechanism, as = UDPTL is commonly used for fax also elsewhere. >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 From christer.holmberg@ericsson.com Thu Aug 29 01:17:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3523C21E8098 for ; Thu, 29 Aug 2013 01:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rliB6BL0L9h0 for ; Thu, 29 Aug 2013 01:17:29 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8173321E8064 for ; Thu, 29 Aug 2013 01:17:17 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-07-521f038926c0 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 78.48.22048.9830F125; Thu, 29 Aug 2013 10:17:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 10:17:13 +0200 From: Christer Holmberg To: Dan Wing Thread-Topic: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 Thread-Index: Ac6c2+8uzokCW2xnSQeYLTwy0EHdvQAFtGOAAIoTZrABOnz8AAAiwW4g Date: Thu, 29 Aug 2013 08:17:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C47F98F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C46787F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4754A3@ESESSMB209.ericsson.se> <361F2B18-D0B3-487B-A534-8E8D4604561D@cisco.com> In-Reply-To: <361F2B18-D0B3-487B-A534-8E8D4604561D@cisco.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvjW4Xs3yQwck7AhYXrz1kspi6/DGL A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJUxoXUvU8F3pYpP076xNjDOkeli5OSQEDCR WPeyjRXCFpO4cG89WxcjF4eQwGFGibcLb7JCOEsYJc6u/AjkcHCwCVhIdP/TBmkQEZCTuDt/ AjOIzSwgL3FhyRomEFtYwEViwq197BA1rhK9m1azQthuEhNerwWrZxFQlZgxs4kRxOYV8JV4 uPc3C8Su74wSb9Z1MYPs4hSwlVj8WQ+khhHouO+nIOYzC4hL3HoynwniaAGJJXvOM0PYohIv H/+DekZRov1pAyNEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYxsucmZuakl5tvYgTGyMEtvw12MG66L3aIUZqDRUmcd7PemUAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjMunMfYttfCdlB5SNUdB/WWs6J9lih9sXY95MGurN76Vfb3y4s21zh90LEU3 bOGYd0GZe1fN1sm/NohZhF7a2fL77YbroqKSjef3hfeqxf6+3BOze5au2jLfpWEBNxIWb4ze xPXcWvqh8XF5Cya2FXZ7j5yYqsAU/vNI1/qvndWPjR0Ca29M7FFiKc5INNRiLipOBACQ5hMK XwIAAA== Cc: mmusic WG Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 08:17:38 -0000 Hi Dan, The protocols listed in draft-ietf-tls-applayerprotoneg-01 are used without= SIP/SDP, so using such mechanism makes sense for those protocols. In SIP, SDP is used to negotiate the media (including nonsecure fax), and I= see no reason why we should introduce a new mechanism for secure fax.=20 Regards, Christer -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: 28. elokuuta 2013 20:41 To: Christer Holmberg Cc: mmusic WG Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 On Aug 22, 2013, at 2:37 AM, Christer Holmberg wrote: > Hi Dan, >=20 > Regarding the 3GPP SA3 study, the information I gave was a little mislead= ing. From a security perspective SRTP would be fine. >=20 > The focus of the SA3 study was on how to provide security for the existin= g fax transmission mechanism, which uses UDPTL/UDP. >=20 > 3GPP already mandates IMS terminals to support UDPTL/UDP for unsecure fax= . And, new terminals (supporting secure fax) are still required to also sup= port unsecure fax, in order to communicate with legacy terminals when unsec= ure fax is sufficient.=20 >=20 > So, using UDPTL/DTLS/UDP for secure fax makes more sense, as it avoids im= plementing different mechanisms for secure and unsecure fax - UDPTL/DTLS/UD= P only requires a new layer between UDPTL and UDP, it does not require chan= ging the upper layers (UDPTL and above). >=20 > Hopefully this clarifies :) (Sorry for my delay. I was on vacation.) Thanks for the clarification. Back to your document, it says: Since the DTLS record layer "application_data" packet does not indicate whether it carries UDPTL, or some other protocol, the usage of a dedicated DTLS association for transport of UDPTL needs to be negotiated, e.g. using the Session Description Protocol (SDP) [RFC4566] and the SDP offer/answer mechanism [RFC3264]. Therefore, this document specifies a new value [RFC4566] for the SDP "m=3D" line [RFC3264], in order to indicate UDPTL over DTLS in SDP messages [RFC4566]. Have you considered doing UDPTL negotiation in the DTLS handshake itself, u= sing http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg? That seem= s ideally suited for indicating the application layer protocol, perhaps in = addition to the SDP signaling described in your I-D. -d >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: 19. elokuuta 2013 20:43 > To: Christer Holmberg > Cc: mmusic; mmusic-chairs@tools.ietf.org > Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-udptl-dtls-00 >=20 >=20 > On Aug 19, 2013, at 6:03 AM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> We have submitted a new draft, draft-holmberg-mmusic-udptl-dtls-00, whic= h defines usage of UDPTL over DTLS, in order to provide secure fax. >>=20 >> The draft was previously submitted to DISPATCH. Based on discussions wit= h the ADs and chairs, it was decided that it shall be submitted to MMUSIC (= note that no DTLS extensions are needed). >>=20 >> As is indicated in the draft, 3GPP has performed a study on how to=20 >> provide secure fax in the IMS, and the outcome was that secure fax shall= be transported using UDPTL over DTLS. >=20 > Got a pointer to that study? Seems easier to carry UDPTL over RTP, which= would allow the RTP to be secured using SRTP (and thus the UDPTL would be = secured using SRTP). There is a spec floating around to do exactly that (c= arry fax over RTP so that SRTP can secure it). Advantage of using SRTP to = secure fax is it separates the keying mechanism from security, so that Secu= rity Descriptions / MIKEY / DTLS-SRTP / whatever-is-invented-in-2020 will w= ork just as effectively for voice as for fax. And also that upgrading from= a voice call to a "fax" call has no additional complexities due to securit= y ("please press START to begin the fax transmission"). >=20 > -d >=20 >=20 >> However, there is nothing "3GPP/IMS specific" about the mechanism, as UD= PTL is commonly used for fax also elsewhere. >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 From christer.holmberg@ericsson.com Fri Aug 30 05:44:21 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A8C21F99BF for ; Fri, 30 Aug 2013 05:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.82 X-Spam-Level: X-Spam-Status: No, score=-3.82 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4uLv5AYKqPk for ; Fri, 30 Aug 2013 05:44:12 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E460B21F9967 for ; Fri, 30 Aug 2013 05:44:08 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-e0-52209394622c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D5.2C.25272.49390225; Fri, 30 Aug 2013 14:44:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Fri, 30 Aug 2013 14:43:57 +0200 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. Thread-Index: Ac6f7OG1P0YUwhF6Remol1dqLcLlOQDLal4AAJiyiVA= Date: Fri, 30 Aug 2013 12:43:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4809D7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C47762C@ESESSMB209.ericsson.se> <521CACD4.6060904@alum.mit.edu> In-Reply-To: <521CACD4.6060904@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje6UyQpBBhObZCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj7dtnzAVHvSo+zPjE3MDYZdnFyMkhIWAi 8fv8Q3YIW0ziwr31bF2MXBxCAkcZJU5vW8QO4SxhlFi17QVTFyMHB5uAhUT3P22QBhEBX4ln j2+zgdjCAucZJX41F4HUiwhcYJS4sechC0SRlcTs9QvAbBYBVYlJPyczg9i8QM3vpuxmAZkp JJAv8XyBD0iYU0BHYvOj/WDljEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwph K0q0PwV6DaxeR2LB7k9sELa2xLKFr6HWCkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGDmK U4uTctONDDYxAqPh4JbfFjsYL/+1OcQozcGiJM67Re9MoJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGKyr3t79b9HJRta3bdZ1rfH0zknZwHFS8nXo0jOEO04PwkDjlOKvmSTEtvBZ/eH7Y P8uuzdgUY+lSKh5gkNps/CZN0FlmzvntC8+8CSnuUn9lbLRx8eRTrccncx05ZTAl5xl/X+rB TU9TYiRO8cVMqUxgCZ3Q7LSnnOXvQoWGldbHp05065+nxFKckWioxVxUnAgA/J0tg1QCAAA= Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 12:44:22 -0000 Hi, We also need to decide whether that change also applies to when new media d= escriptions (m- line) are added to a previously negotiated BUNDLE group. Currently the text says that, when an m- line is added, it must contain eit= her a unique address, or a previously negotiated BUNDLE address. But, since we now allow to assign a new, yet not confirmed, BUNDLE address = to multiple m- lines, I guess that applies also to a new m- line. If so, we can make the text in Section 6.4.3, because it more or less uses = the procedures defined in Section 6.4.1. Regards, Christer ------------------------------------------ OLD TEXT (-04): --------------------- 6.4.3. Adding a media description to a BUNDLE group When an Offerer adds an "m=3D" line to a BUNDLE group, the Offerer MUST assign either a unique address, or the BUNDLE address associated with the BUNDLE group, to the added "m=3D" line. In addition, the Offerer MUST assign a mid value to the "m=3D" line, and place the mid in the SDP group:BUNDLE attribute mid list associated with the BUNDLE group, in order to group the "m=3D" line to the BUNDLE group. NOTE: If the Offerer assigns a unique address to the added "m=3D" line, it allows the Answerer to move the "m=3D" line out of the BUNDLE group without having to reject the "m=3D" line ([ref-to-be-added]). To the previously added "m=3D" lines in the BUNDLE group, the Offerer assigns either unique addresses or the BUNDLE address associated with the BUNDLE group, according to the procedures in Section 6.4.1. Section 10.3 shows an example of an SDP Offer used to add an "m=3D" line to a BUNDLE group. NEW SUGGESTED TEXT (-04): -------------------------------------- 6.4.3. Adding a media description to a BUNDLE group When an Offerer adds a new "m=3D" line to a previously negotiated BUNDLE= group, the Offerer assigns an address to the new "m=3D" line according to the proce= dures in Section=20 6.4.1. If the Offerer assigns a BUNDLE address (previously negotiated, o= r a suggested=20 new Address) to the previously negotiated "m=3D" lines in the BUNDLE gro= up, the Offerer=20 can assign the same address to the new "m=3D" line. Alternatively, the O= fferer can assign=20 a unique address to the new "m=3D" line. NOTE: If the Offerer assigns a unique address to the added "m=3D" line, it allows the Answerer to move the "m=3D" line out of the BUNDLE group without having to reject the "m=3D" line ([ref-to-be-added]). Section 10.3 shows an example of an SDP Offer used to add an "m=3D" line to a BUNDLE group. -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: 27. elokuuta 2013 16:43 To: mmusic@ietf.org Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-n= egotiated, the Offerer can assign the requsted new address to all m- lines = immediately, without first offering unique addresses. This seems reasonable to me. Thanks, Paul On 8/23/13 6:39 AM, Christer Holmberg wrote: > Hi, > > One of the open issues related to BUNDLE presented in Berlin (Q5 in my > slides) was whether, once a BUNDLE address is re-negotiated (i.e. the=20 > usage of BUNDLE etc has already been negotiated), it is allowed to=20 > assign the new suggested BUNDLE address to all "m=3D" lines immediately,= =20 > instead of doing the 2-step Offer/Answer procedure. The outcome was=20 > that it shall be allowed. > > So, based on that, I am suggesting the change below to section 6.1.4=20 > of BUNDLE. > > NOTE that this only applies to the case where a BUNDLE address is=20 > RE-negotiated (e.g. in a re-INVITE). There is still a discussion about=20 > the initial Offer, and that outcome of that (and the outcome of the UP > discussions) may obviously also impact the text. But, let's keep that=20 > separate for now, and only focus on the case when a BUNDLE address is=20 > RE-negotiated :) > > Regards, > > Christer > > ------------------------------------------- > > OLD TEXT (BUNDLE-04): > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 6.4.1. SDP Offerer Bundle Address Request and Usage > > An Offerer can assign a BUNDLE address to multiple "m=3D" lines in a > > BUNDLE group, once the Answerer has selected the BUNDLE address=20 > for > > the Offerer. An Offerer MUST NOT assign a BUNDLE address to=20 > multiple > > "m=3D" lines until the Answerer has selected the BUNDLE address. > > OPEN ISSUE: Should it be allowed to assign a new BUNDLE address to > > multiple "m=3D" lines in a BUNDLE group, before the Answerer has > > selected the BUNDLE address? > > In order to negotiate (or, to re-negotiate) the BUNDLE address > > associated with a BUNDLE group, the Offerer, in the SDP Offer, > > assigns a unique address to each "m=3D" line in the BUNDLE group. =20 > In > > addition, the Offerer indicates which unique address it wishes the > > Answerer to select as the Offerer's BUNDLE address. The Offerer > > places the mid, associated with the unique address requested to be > > selected as the BUNDLE address, first in the SDP group:BUNDLE > > attribute mid list. The Answerer will then select the BUNDLE=20 > address > > for the Offerer ([ref-to-be-added]). > > If the Offerer, in a subsequent SDP Offer, wants to re-negotiate=20 > the > > BUNDLE address associated with a BUNDLE group, it MAY assign the > > previously negotiated BUNDLE address as a unique address to one of > > the "m=3D" lines in the BUNDLE group. > > If the Offerer assigns the previously selected BUNDLE address to=20 > more > > than one "m=3D" line in a BUNDLE group, the first mid in the SDP > > group:BUNDLE attribute mid list MUST represent an "m=3D" line to=20 > which > > the BUNDLE address is assigned. Hence, in order to re-negotiate=20 > the > > BUNDLE address, the Offerer needs to assign a unique address to=20 > each > > "m=3D" line in the BUNDLE group, as described above. > > An Offerer MUST NOT assign a BUNDLE address to an "m=3D" line that=20 > is > > not associated with a BUNDLE group. An Offerer MUST NOT assign a > > BUNDLE address, that has been negotiated for a BUNDLE group, to an > > "m=3D" line that is associated with another BUNDLE group. > > Section 10.1 shows an example of a Bundle Address Request. > > SUGGESTED NEW TEXT: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 6.4.1. SDP Offerer Bundle Address Request and Usage > > > > An Offerer can assign a BUNDLE address to multiple "m=3D" lines in a > > BUNDLE group, once the Answerer has selected the BUNDLE address=20 > for > > the Offerer. An Offerer MUST NOT assign a BUNDLE address to=20 > multiple > > "m=3D" lines until the Answerer has selected the BUNDLE address. > > > > Before the Answerer has selected a BUNDLE address for the Offerer, > > in order to negotiate the BUNDLE address associated with a BUNDLE > > group, the Offerer, in the SDP Offer, assigns a unique address to > > each "m=3D" line in the BUNDLE group. In addition, the Offerer=20 > indicates > > which unique address it wishes the Answerer to select as the > > Offerer's BUNDLE address. The Offerer places the mid, associated > > with the unique address requested to be selected as the BUNDLE=20 > address, > > first in the SDP group:BUNDLE attribute mid list. The Answerer=20 > will > > then select the BUNDLE address for the Offerer ([ref-to-be-added]). > > > > If an Offerer, in a subsequent SDP Offer, wants to re-negotiate=20 > the > > BUNDLE address associated with a BUNDLE group, it can either: > > > > - Assign the requested new BUNDLE address to all "m=3D" lines in the > > BUNDLE group; or > > - In the same way as described in the procedures above, assign a > > unique address to each "m=3D" line in the BUNDLE group (the previously > > negotiated BUNDLE address can also be assigned as a unique address > > to one of the "m=3D" lines in the BUNDLE group). > > > > In both cases, the Offerer places the mid, associated with the=20 > unique > > address requested to be selected as the BUNDLE address, first in=20 > the > > SDP group:BUNDLE attribute mid list (if the requested new BUNDLE=20 > address > > is assigned to all "m=3D" lines in the BUNDLE group, all mids in the= =20 > SDP > > group:BUNDLE attribute mid list will represent that same address). > > > > An Offerer MUST NOT assign a BUNDLE address to an "m=3D" line that=20 > is > > not associated with a BUNDLE group. An Offerer MUST NOT assign a > > BUNDLE address, that has been negotiated for a BUNDLE group, to an > > "m=3D" line that is associated with another BUNDLE group. > > > > Section 10.1 shows an example of a Bundle Address Request. > > > > _______________________________________________ > 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 hadriel.kaplan@oracle.com Fri Aug 30 06:10:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A62921F9B5B for ; Fri, 30 Aug 2013 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcPihVitdf4X for ; Fri, 30 Aug 2013 06:10:43 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB621F9B11 for ; Fri, 30 Aug 2013 06:10:39 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7UDATdB010470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 13:10:30 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UDASQJ001853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 13:10:29 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UDARXs021043; Fri, 30 Aug 2013 13:10:28 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 06:10:27 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4809D7@ESESSMB209.ericsson.se> Date: Fri, 30 Aug 2013 09:10:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <968A751E-C145-4799-9479-417D850F50A6@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C47762C@ESESSMB209.ericsson.se> <521CACD4.6060904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4809D7@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 13:10:50 -0000 On Aug 30, 2013, at 8:43 AM, Christer Holmberg = wrote: > Hi, >=20 > We also need to decide whether that change also applies to when new = media descriptions (m- line) are added to a previously negotiated BUNDLE = group. > Currently the text says that, when an m- line is added, it must = contain either a unique address, or a previously negotiated BUNDLE = address. > But, since we now allow to assign a new, yet not confirmed, BUNDLE = address to multiple m- lines, I guess that applies also to a new m- = line. But then if the far-end answered with accepting it for the same bundle, = then you'd have to send another offer with the m-line using the correct = port of the bundle group, right? -hadriel From christer.holmberg@ericsson.com Fri Aug 30 06:39:19 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9C11E8179 for ; Fri, 30 Aug 2013 06:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9X4J8e5W+W3 for ; Fri, 30 Aug 2013 06:39:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3F69811E817A for ; Fri, 30 Aug 2013 06:39:04 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-76-5220a0779164 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 76.17.22048.770A0225; Fri, 30 Aug 2013 15:39:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Fri, 30 Aug 2013 15:39:03 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. Thread-Index: Ac6f7OG1P0YUwhF6Remol1dqLcLlOQDLal4AAJiyiVD//+hjAP//16UQ Date: Fri, 30 Aug 2013 13:39:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C480A75@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C47762C@ESESSMB209.ericsson.se> <521CACD4.6060904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4809D7@ESESSMB209.ericsson.se> <968A751E-C145-4799-9479-417D850F50A6@oracle.com> In-Reply-To: <968A751E-C145-4799-9479-417D850F50A6@oracle.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW75AoUgg/dbDCw+bfrEbDF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHh+f3mIJYI7isklJzcksSy3St0vgyjhzYTVbwUHOij0XlzM3 MO5j72Lk5JAQMJE4eqYdyhaTuHBvPVsXIxeHkMBhRol5EzuhnCWMEpu+XmPpYuTgYBOwkOj+ pw1iigjoSRy9xwnSyyzgK/FywRdmEFtY4DyjxK/mIpBWEYELjBI39jxkAUmICLhJHHr+ignE ZhFQldj75gPYYl6g5n1T3rNA7HrOKPHk1l42kASngJ1E99fPYM2MQNd9P7WGCWKbuMStJ/OZ IK4WkFiy5zwzhC0q8fLxP1YIW1Gi/WkDI0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZ SMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXm29iBEbOwS2/DXYwbrovdohRmoNFSZx3s96ZQCGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mx7M5o3evDP52bdOD/yeYgzcy7TtbxnD7hKfpH0eu l1t8pL+6JH2R+fvo6rWWvSoGZ08ztKp9/735/rnErD4zmdizOwWOf+V5fi36v9l53b8Wp2O7 GtcYdb2t+FvMz7Rt1f28NfJxE/fmr7E1MYoJVp4u9FG248fka92xAS2tIhwXJhuwtugdUGIp zkg01GIuKk4EAG2HpVtqAgAA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 13:39:19 -0000 Hi, >> We also need to decide whether that change also applies to when new medi= a descriptions (m- line) are added to a previously negotiated BUNDLE group. >> Currently the text says that, when an m- line is added, it must contain = either a unique address, or a previously negotiated BUNDLE address. >> But, since we now allow to assign a new, yet not confirmed, BUNDLE addre= ss to multiple m- lines, I guess that applies also to a new m- line. > > But then if the far-end answered with accepting it for the same bundle, t= hen you'd have to send another offer with the m-line using the correct port= of the bundle group, right? The change is that an Offerer is now allowed to assign the same address (th= e requested BUNDLE address) to all m- lines in the BUNDLE group BEFORE the = Answerer has "confirmed" the address=20 to become the Offerer's BUNDLE address. So, if the requested BUNDLE address was assigned to all m- lines in the BUN= DLE group, and the Answerer accepts it, there is obviously no need to send = a second offer. But, if any of the m- lines in the offer did NOT contain the selected BUNDL= E address, a second Offer is still required :) Regards, Christer From christer.holmberg@ericsson.com Fri Aug 30 06:48:23 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314E611E8111 for ; Fri, 30 Aug 2013 06:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQGKSLy22QmC for ; Fri, 30 Aug 2013 06:48:17 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4401421F9FBA for ; Fri, 30 Aug 2013 06:48:16 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-41-5220a29fe1d0 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 52.58.22048.F92A0225; Fri, 30 Aug 2013 15:48:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Fri, 30 Aug 2013 15:48:15 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE DISCUSION Q8 (NEW): SDP 'bundle-only' attribute Thread-Index: Ac6lhqFY3iKihKwVS+CtvL9fvUs1Jw== Date: Fri, 30 Aug 2013 13:48:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C480AB8@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_7594FB04B1934943A5C02806D1A2204B1C480AB8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvje78RQpBBqeni1hMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGVObygoWlVYsW9/C2sA4KaOLkZNDQsBEovPjVSYIW0ziwr31 bF2MXBxCAocZJbrmtTJBOEsYJU6camPvYuTgYBOwkOj+pw3SICKgLvF1bw8ziC0sYC/x4PEe Foi4i8Tdc6sYIWw9iaanj8EWsAioSuy/ugmsnlfAV+LXvRVgcUagxd9PrQGzmQXEJW49mQ91 kIDEkj3nmSFsUYmXj/+xQtiKEu1PGxgh6vMlfkz7wwgxU1Di5MwnLBMYhWYhGTULSdksJGUQ cR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSN7bmJmTnq5+SZGYNAf3PLbYAfjpvtihxil OViUxHk3650JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC41v3F75sr7p/TXuH9o1bwwrVH WmZbLRu5HLzTrHbGeWae1Rbk2fZvRWq13xKuOT6FPo7+ezdqzHuXEPYhcuLS9pkmt31fCv6d N4XntXsUm+LZW4xn+6X2XSlXdVye+uGVKauF4JUl1dv2Nu93uyZx4ehLkzt5d7Yabn2for1N cX7FzJ2/am7fV2Ipzkg01GIuKk4EAKdb2a1IAgAA Subject: [MMUSIC] BUNDLE DISCUSION Q8 (NEW): SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 13:48:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C480AB8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I started to draft some text for the definition of the SDP 'bundle-only' at= tribute (my assumption is that it will be defined in draft-bundle). Note that, at this point, I don't suggest any normative text regarding the = usage of port zero in the SDP Offer, as we are still discussing that (the o= utcome of that discussion may affect at least the last paragraph in section= x.2.1.). Also note that I don't say anything about in which "scope/context" (webrtc = etc) the usage of the attribute is allowed. So, leaving the usage of port zero, and the scope question, aside for the m= oment, please take a look and indicate whether you have any issues (at this= point, I ask you to focus on the technical stuff - and stuff which is uncl= ear) with the text :) Regards, Christer -------------------------- X. SDP 'bundle-only' attribute X.1. General This section defines a new SDP media-level attribute, 'bundle-only'. The at= tribute is used, in an SDP Offer, to indicate that an "m=3D" line, to which the att= ribute has been assigned, is only to be accepted by the Answerer if the Answerer k= eeps the "m=3D" line within the BUNDLE group to which the "m=3D" line is associa= ted in the SDP Offer. X.2. SDP Offer/Answer Procedures X.2.1. SDP Offer Procedures When an Offerer sends an SDP Offer, which contains a BUNDLE group, it can a= ssign the SDP 'bundle-only' attribute to an "m=3D" line associated with the BUNDLE gr= oup, in order to request that the Answerer only accepts the "m=3D" line if is ke= pt within the BUNDLE group to which the "m=3D" line is associated in the SDP Offer. An Offerer MUST NOT assign the SDP 'bundle-only' attribute to an "m=3D" lin= e that is not associated with a BUNDLE group. If an Offerer receives an SDP Answer where an "m=3D" line, to which it assi= gned an 'bundle-only' attribute in the associated Offer, has been removed from a BU= NDLE group, but has not been rejected ([ref-to-section- 6.5.2.]), the Offerer MUST send a n= ew Offer, in which it assigns a zero port value to the "m=3D" line. X.2.2. SDP Answerer Procedures When an Answerer receives an SDP Offer ([ref-to-section- 6.5.]), the Answer= er MAY choose to remove an "m=3D" line out of a BUNDLE group ([ref-to-section- 6.5.2.]). = If an SDP 'bundle-only' attribute has been assigned to such "m=3D" line, the Answerer= MUST reject the "m=3D" line, according to the procedures in Section 6.5.3. An Answerer MUST NOT insert an SDP 'bundle-only' attribute in an SDP Answer= . --_000_7594FB04B1934943A5C02806D1A2204B1C480AB8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I started to draft some text for the definition of the SDP= 'bundle-only' attribute (my assumption is that it will be defined in draft= -bundle).

 

Note that, at this point, I don’t suggest any normat= ive text regarding the usage of port zero in the SDP Offer, as we are still= discussing that (the outcome of that discussion may affect at least the last paragraph in section x.2.1.).

 

Also note that I don’t say anything about in which &= #8220;scope/context” (webrtc etc) the usage of the attribute is allow= ed.

 

So, leaving the usage of port zero, and the scope question= , aside for the moment, please take a look and indicate whether you have an= y issues (at this point, I ask you to focus on the technical stuff – and stuff which is unclear) with the text :)

 

Regards,

 

Christer

 

 

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

 

 

X.  SDP 'bundle-only' attribute

 

X.1.  General

 

This section defines a new SDP media-level attribute, 'bun= dle-only'. The attribute

is used, in an SDP Offer, to indicate that an "m=3D&q= uot; line, to which the attribute

has been assigned, is only to be accepted by the Answerer = if the Answerer keeps

the "m=3D" line within the BUNDLE group to which= the "m=3D" line is associated in the

SDP Offer.

 

 

X.2.  SDP Offer/Answer Procedures

 

X.2.1.  SDP Offer Procedures

 

When an Offerer sends an SDP Offer, which contains a BUNDL= E group, it can assign the

SDP 'bundle-only' attribute to an "m=3D" line as= sociated with the BUNDLE group,

in order to request that the Answerer only accepts the &qu= ot;m=3D" line if is kept within

the BUNDLE group to which the "m=3D" line is ass= ociated in the SDP Offer.

 

An Offerer MUST NOT assign the SDP 'bundle-only' attribute= to an "m=3D" line that is not

associated with a BUNDLE group.

 

If an Offerer receives an SDP Answer where an "m=3D&q= uot; line, to which it assigned an

'bundle-only' attribute in the associated Offer, has been = removed from a BUNDLE group, but

has not been rejected ([ref-to-section- 6.5.2.= ]), the Offerer MUST send a new Offer, in which

it assigns a zero port value to the "m=3D" line.=

 

 

X.2.2.  SDP Answerer Procedures

 

When an Answerer receives an SDP Offer ([ref-to-section- 6.5.])= , the Answerer MAY choose

to remove an "m=3D" line out of a BUNDLE group (= [ref-to-section- 6.5.2.= ]). If an SDP

'bundle-only' attribute has been assigned to such "m= =3D" line, the Answerer MUST reject

the "m=3D" line, according to the procedures in = Section 6.5.3.

 

An Answerer MUST NOT insert an SDP 'bundle-only' attribute= in an SDP Answer.

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C480AB8ESESSMB209erics_-- From magnus.westerlund@ericsson.com Fri Aug 30 08:37:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7AC21F9FCA for ; Fri, 30 Aug 2013 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.701 X-Spam-Level: X-Spam-Status: No, score=-105.701 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySC+oDlKTUcD for ; Fri, 30 Aug 2013 08:37:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5667021F9C40 for ; Fri, 30 Aug 2013 08:36:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-4d-5220bc1962bd Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 98.04.16099.91CB0225; Fri, 30 Aug 2013 17:36:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.17) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Fri, 30 Aug 2013 17:36:57 +0200 Message-ID: <5220BC3A.6040205@ericsson.com> Date: Fri, 30 Aug 2013 17:37:30 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mmusic (E-mail)" , Robert Sparks X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvja7UHoUggyPvuSymLn/MYnFtTiOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXRt3kKS8G7DsaK5q/fWBoYp8d3MXJySAiY SPy9eZQZwhaTuHBvPRuILSRwmFFiySJrCHsZo8S/98EgNq+AtsStpxfBalgEVCUe3+lhAbHZ BCwkbv5oBIuLCgRLtG//ygZRLyhxcuYTsBoRAV+Jrbf2soPYwgIaElfPNDBC7JWU2LboGFic WUBPYsrVFkYIW16ieetsZogbtCUamjpYJzDyz0IydhaSlllIWhYwMq9iZM9NzMxJLzfcxAgM sYNbfuvuYDx1TuQQozQHi5I47ya9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGIN/T1Cz 3s+lv5v/D2+ItPirusXtvFv6SzdN+dIaserUcpd7T0RPqMwtUnmywkrz1IUJ++fqii/S8/p5 tW3RKYlLOcrivFsV1ycqCc1xXn6/3/V29ZlTNmELOMoaLvBknT5WN/0e38XArI/+Zbt+7g1i vrrE9JWjd6ul9Y9zl1tEioumdPkUdCmxFGckGmoxFxUnAgC6OWA4/wEAAA== Subject: [MMUSIC] RTSP 2.0: Client Authentication X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 15:37:07 -0000 WG, As part of Robert's comments is this minor comment: > >> As written, a client and server can use HTTP Basic authentication over >> TCP that is not protected with TLS. Consider restricting it's use to TLS >> only. Are you sure you don't need to say anything RTSP specific about >> DIGEST computations (I don't think you need to go as far as SIP did >> talking about DIGEST, but I'm surprised you haven't run into issues >> relying only on 2617 literally. > Are you referring to Section 19.1 here? Yes > > Yes, I would not have any issue with requiring Basic to be combined with > TLS. I think that is appropriate. > > When it comes to DIGEST, are you referring to section 22.4 in RFC 3261? Yes > > That section indicates that some clarifications are likely needed. This actually resulted in finding a bit more shortcomings around the client authentication. The high level summary of what my proposal for fixing this is: - Mandate TLS for basic authentication. - Added the missing Authentication-Info and Proxy-Authentication-Info - Corrected ABNF that was missing basic - Written an equivalent of the RFC 2617 clarification section of RFC 3261. - Tried to press on the hop-by-hop nature of proxy-authorization - Put up a warning flag for server to client requests lack authentication. This massive amount obviously needs review. The resulting relevant text sections are: 18 Header tables: +------------------+-------+-----+----+-----+-----+-----+-----+-----+ | Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD | | | | xy | S | | | | | | +------------------+-------+-----+----+-----+-----+-----+-----+-----+ | Authentication-I | r | | o | o | o | o | o | o/- | | nfo | | | | | | | | | | Authorization | R | | o | o | o | o | o | o | | Proxy- | 407 | amr | m | m | m | m | m | m | | Authenticate | | | | | | | | | | | | | | | | | | | | Proxy-Authentica | r | amd | o | o | o | o | o | o/- | | tion-Info | | r | | | | | | | | | | | | | | | | | | Proxy- | R | rd | o | o | o | o | o | o | | Authorization | | | | | | | | | | | | | | | | | | | | WWW- | 401 | | m | m | m | m | m | m | | Authenticate | | | | | | | | | +------------------+---------+-----+----+----+----+-----+-----+-----+ +-------------------------+---------+-------+-----+-----+-----+-----+ | Header | Where | Proxy | GPR | SPR | RDR | PNY | +-------------------------+---------+-------+-----+-----+-----+-----+ | Authentication-Info | r | | o/- | o/- | - | - | | | | | | | | | | Authorization | R | | o | o | o | - | | | | | | | | | | Proxy-Authenticate | 407 | amdr | m | m | m | - | | | | | | | | | | Proxy-Authentication-In | r | amdr | o/- | o/- | - | - | | fo | | | | | | | | | | | | | | | | Proxy-Authorization | R | amdr | o | o | o | - | +------------------+---------+-------+-----+-----+-----+-----+ | Header | Where | Proxy | GPR | SPR | RDR | PNY | +------------------+---------+-------+-----+-----+-----+-----+ | | | | | | | | | WWW-Authenticate | 401 | | m | m | m | - | +------------------+---------+-------+-----+-----+-----+-----+ 18.7. Authentication-Info The Authentication-Info header is used by the server to communicate some information regarding the successful authentication in the response message. This usage of this header is specified in [RFC2617] with some RTSP clarification in Section 19.1. This header MUST only be used in response messages related to client to server requests. 18.8. Authorization An RTSP client that wishes to authenticate itself with a server using authentication mechanism from HTTP [RFC2617] , usually, but not necessarily, after receiving a 401 response, does so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. This header MUST only be used in client to server requests. If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks). When a shared cache (see Section 16) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds: 1. If the response includes the "max-age" cache-control directive, the cache MAY use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. (This is the defined behavior for max-age.) If the response includes "max-age=0", the proxy MUST always revalidate it before re-using it. 2. If the response includes the "must-revalidate" cache-control directive, the cache MAY use that response in replying to a subsequent request. But if the response is stale, all caches MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. 3. If the response includes the "public" cache-control directive, it MAY be returned in reply to any subsequent request. 18.34. Proxy-Authenticate The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI. The HTTP access authentication process is described in [RFC2617]. Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and SHOULD NOT be passed on to downstream agents. This header MUST only be used in response messages related to client to server requests. 18.35. Proxy-Authentication-Info The Proxy-Authentication-Info header is used by the proxy to communicate some information regarding the successful authentication to the proxy in the message response. The content and usage of this header is described in the HTTP access authentication [RFC2617] that is also used by RTSP and clarified in Section 19.1. This header MUST only be used in response messages related to client to server requests. This header has hop by hop scope. 18.36. Proxy-Authorization The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. The HTTP access authentication process is described in [RFC2617]. Unlike Authorization, the Proxy-Authorization header field applies only to the next hop proxy. This header MUST only be used in client to server requests. 18.58. WWW-Authenticate The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. This header MUST only be used in response messages related to client to server requests. The HTTP access authentication process is described in [RFC2617] with some clarification in Section 19.1. User agents are advised to take special care in parsing the WWW- Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters. 19.1. RTSP and HTTP Authentication RTSP and HTTP share common authentication schemes, and thus follow the same usage guidelines as specified in [RFC2617] with the additions for digest specified below in Section 19.1.1. Servers SHOULD implement both basic and digest [RFC2617] authentication. Clients MUST implement both basic and digest authentication [RFC2617] so that a server that requires the client to authenticate can trust that the capability is present. It should be stressed that using the HTTP authentication alone does not provide full control message security. Therefore, in environments requiring tighter security for the control messages, TLS SHOULD be used, see Section 19.2. Any RTSP message containing an Authorization header containg a basic authorization MUST be using a TLS connection with confidentiality protection enabled, i.e. no NULL encryption. In cases where there is a chain of proxies between the client and the server, each proxy may individually request the client or previous proxy to authenticate itself. This is done using the Proxy- Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36) and the Proxy-Authentication-Info (Section 18.35) headers. These headers are hop-by-hop headers and have only scope for the current connection. Thus if a chain exist, the proxy connecting to another proxy will have to act as a client to authorize itself towards the next proxy. The WWW-Authenticate (Section 18.58), Authorization (Section 18.8) and Authentication-Info (Section 18.7) headers are end-to-end and must not be modified by proxies. This authentication mechanism works only for client to server requests as currently defined. This leaves server to client request outside of the context of TLS based communication more vulnerable to message injection attacks on the client. Based on the server to client methods that exist, the potential risks are various; hijacking (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY) or attacks with uncertain results (SET_PARAMETER). 19.1.1. Digest Authentication This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to RTSP. The RTSP scheme usage is almost completely identical to that for HTTP [RFC2617]. These are based on the procedures defined for SIP 2.0 [RFC3261]. The rules for Digest authentication follow those defined in [RFC2617], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the following differences: 1. Use the ABNF specified in this document, rather than the one in [RFC2617]. That way the following is assured: * Using the right RTSP URIs allowed in the challenge as well as in the digest. * Resolved the error in the "uri" parameter of the Authorization header in [RFC2617]. 2. If MTags are used then the example procedure for choosing a nonce based on Etag can work based on replacing ETag with the MTag. 3. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when the RTSP messages have no message body) that the hash of the message-body resolves to the MD5 hash of an empty string, or: H(entity-body) = MD5("") = "d41d8cd98f00b204e9800998ecf8427e". 4. RFC 2617 notes that a cnonce value MUST NOT be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent. Therefore, any algorithms that have a dependency on the cnonce (including "MD5-Sess") require that the qop directive be sent. Use of the "qop" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since this specification defines RTSP 2.0 there is no backwards compatibilit issue with mandating. Thus, all RTSP agents MUST implement qop-options. Authentication-Info = "Authentication-Info" HCOLON auth-info auth-info = auth-info-entry *(COMMA auth-info-entry) auth-info-entry = nextnonce / message-qop / response-auth / cnonce / nonce-count nextnonce = "nextnonce" "=" nonce-value response-auth = "rspauth" "=" response-digest response-digest = DQ *LHEX DQ Authorization = "Authorization" HCOLON credentials credentials = basic-credential / digest-credential / other-response basic-credential = "Basic" LWS basic-credentials basic-credentials = base64 ; Base64 encoding of user-password user-password = basic-username ":" password basic-username = *CF-TEXT CF-TEXT = %x20-39 / %x3B-7E / %x80-FF ; TEXT without : password = *TEXT digest-credential = ("Digest" LWS digest-response) digest-response = dig-resp *(COMMA dig-resp) dig-resp = username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username = "username" EQUAL username-value username-value = quoted-string digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT digest-uri-value = RTSP-REQ-URI message-qop = "qop" EQUAL qop-value cnonce = "cnonce" EQUAL cnonce-value cnonce-value = nonce-value nonce-count = "nc" EQUAL nc-value nc-value = 8LHEX dresponse = "response" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT auth-param = auth-param-name EQUAL ( token / quoted-string ) auth-param-name = token other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list challenge-list = challenge *(COMMA challenge) challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / ("Basic" LWS realm) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = "realm" EQUAL realm-value realm-value = quoted-string domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref *(1*SP RTSP-REQ-Ref ) RDQUOT nonce = "nonce" EQUAL nonce-value nonce-value = quoted-string opaque = "opaque" EQUAL quoted-string stale = "stale" EQUAL ( "true" / "false" ) algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT qop-value = "auth" / "auth-int" / token Proxy-Auth-Info = "Proxy-Authentication-Info" HCOLON auth-info Proxy-Authorization = "Proxy-Authorization" HCOLON credentials WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From martin.thomson@gmail.com Fri Aug 30 09:29:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B221F9EDA for ; Fri, 30 Aug 2013 09:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwwzLxy0FFke for ; Fri, 30 Aug 2013 09:29:59 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9E45021F9D95 for ; Fri, 30 Aug 2013 09:29:58 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so610390wgh.3 for ; Fri, 30 Aug 2013 09:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uZ3McS0SmigVXbuLbXuGBFSu5k1POlkH9I7KEzR4UbM=; b=diWmurZQxqB8WJLwQfHhoVysWfjerdSQ7ZopFjcXFw/k+kGSeBdgAGJlB4R4y75zlF ABa7GlSjN9mexXcNoU6mSHYQG1NkPUsfcwx5QT3KaUJp9O7tRe2GdSlHqOobTnkcoPTm G0js08PwuhTFY+ruyCVif21QBdcGTT6VbcKuiMxdO1Gmsb7C2rZ8+aTj97wG1c8FY4UB rIHWbeVgMaR/hzQt7o5+2zPyU1Wk1yPvM/88al9/w01wVifPQ5MWhBxNxA3H8otqaPqR xS1gaLPfOBSs6TtgdaORM404rkZkfpLQAYPk5xl3stmftdp5OeVI94Ykq52uDpearXP7 BzZw== MIME-Version: 1.0 X-Received: by 10.180.90.106 with SMTP id bv10mr3091981wib.65.1377880197792; Fri, 30 Aug 2013 09:29:57 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Fri, 30 Aug 2013 09:29:57 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C480AB8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C480AB8@ESESSMB209.ericsson.se> Date: Fri, 30 Aug 2013 09:29:57 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION Q8 (NEW): SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:29:59 -0000 I think that you need to include in X.2.2 what the answerer puts in port for the "m=3D" line if it intends to accept a bundle-only line. On 30 August 2013 06:48, Christer Holmberg wrote: > > > Hi, > > > > I started to draft some text for the definition of the SDP 'bundle-only' > attribute (my assumption is that it will be defined in draft-bundle). > > > > Note that, at this point, I don=E2=80=99t suggest any normative text rega= rding the > usage of port zero in the SDP Offer, as we are still discussing that (the > outcome of that discussion may affect at least the last paragraph in sect= ion > x.2.1.). > > > > Also note that I don=E2=80=99t say anything about in which =E2=80=9Cscope= /context=E2=80=9D (webrtc > etc) the usage of the attribute is allowed. > > > > So, leaving the usage of port zero, and the scope question, aside for the > moment, please take a look and indicate whether you have any issues (at t= his > point, I ask you to focus on the technical stuff =E2=80=93 and stuff whic= h is > unclear) with the text :) > > > > Regards, > > > > Christer > > > > > > -------------------------- > > > > > > X. SDP 'bundle-only' attribute > > > > X.1. General > > > > This section defines a new SDP media-level attribute, 'bundle-only'. The > attribute > > is used, in an SDP Offer, to indicate that an "m=3D" line, to which the > attribute > > has been assigned, is only to be accepted by the Answerer if the Answerer > keeps > > the "m=3D" line within the BUNDLE group to which the "m=3D" line is assoc= iated > in the > > SDP Offer. > > > > > > X.2. SDP Offer/Answer Procedures > > > > X.2.1. SDP Offer Procedures > > > > When an Offerer sends an SDP Offer, which contains a BUNDLE group, it can > assign the > > SDP 'bundle-only' attribute to an "m=3D" line associated with the BUNDLE > group, > > in order to request that the Answerer only accepts the "m=3D" line if is = kept > within > > the BUNDLE group to which the "m=3D" line is associated in the SDP Offer. > > > > An Offerer MUST NOT assign the SDP 'bundle-only' attribute to an "m=3D" l= ine > that is not > > associated with a BUNDLE group. > > > > If an Offerer receives an SDP Answer where an "m=3D" line, to which it > assigned an > > 'bundle-only' attribute in the associated Offer, has been removed from a > BUNDLE group, but > > has not been rejected ([ref-to-section- 6.5.2.]), the Offerer MUST send a > new Offer, in which > > it assigns a zero port value to the "m=3D" line. > > > > > > X.2.2. SDP Answerer Procedures > > > > When an Answerer receives an SDP Offer ([ref-to-section- 6.5.]), the > Answerer MAY choose > > to remove an "m=3D" line out of a BUNDLE group ([ref-to-section- 6.5.2.])= . If > an SDP > > 'bundle-only' attribute has been assigned to such "m=3D" line, the Answer= er > MUST reject > > the "m=3D" line, according to the procedures in Section 6.5.3. > > > > An Answerer MUST NOT insert an SDP 'bundle-only' attribute in an SDP Answ= er. > > > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From ron.even.tlv@gmail.com Fri Aug 30 09:36:01 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91BD21E8098; Fri, 30 Aug 2013 09:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfzthUyXd0-m; Fri, 30 Aug 2013 09:36:01 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC121E808F; Fri, 30 Aug 2013 09:36:00 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so1763637wgh.6 for ; Fri, 30 Aug 2013 09:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=zgdR/5dd3b5wmL44P2fugWI59K1PaWgNW6HRr/ojlUE=; b=SApZnYoqS0F2OLLL8fihtVaPkUb63nAMJYcpRXCnuE6ZKGXSCauPVTL7zZ0r0Clw+S yGhB2Sjf3ORAqq1pKafMg9D8f7xlbYnFK3jqRoMQXVRuvUzNoeTm38vLKVr066lzaC5Y reWbPysfXMGxABWA+VFO8fPlEEbJJ39IaYHGAr8kamoM4BIUpwshEZtGAZOhpHFbcTrH VwJSM6mQCqcsbXFEPjEt7D89RDnTF8KsMmW7aENjwfCOTJKF1iEWOqKH5ZPAPu5YnGs0 7zuCscdJPVm7ZlocShARWaLr6bQWmrmytdTU2rV5nK/Ykm9NWGunQXFXpPq0qDCPHV7g 95UA== X-Received: by 10.194.176.163 with SMTP id cj3mr11707091wjc.8.1377880559897; Fri, 30 Aug 2013 09:35:59 -0700 (PDT) Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id u8sm5494666wiz.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 30 Aug 2013 09:35:59 -0700 (PDT) From: "Roni Even" To: References: <20130830162909.20422.68365.idtracker@ietfa.amsl.com> In-Reply-To: <20130830162909.20422.68365.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2013 19:33:29 +0300 Message-ID: <008201cea59e$aa9fd3a0$ffdf7ae0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJijinmfWhztVhxPxTz4Z/AzXtx5ZiGIDgA Content-Language: en-us Cc: mmusic@ietf.org Subject: [MMUSIC] FW: New Version Notification for draft-wu-avtcore-dynamic-pt-usage-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:36:02 -0000 Hi, Apologize for the cross posting. Please comment only in avtcore mailing = list We have submitted a draft that clarifies the usage of dynamic payload = type numbers. This is based on email discussion in MMUSIC=20 Thanks Roni Even -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 30 August, 2013 7:29 PM To: Qin Wu; Wenson Wu; Rachel Huang; Roni Even; Rachel Huang Subject: New Version Notification for = draft-wu-avtcore-dynamic-pt-usage-00.txt A new version of I-D, draft-wu-avtcore-dynamic-pt-usage-00.txt has been successfully submitted by Qin Wu and posted to the IETF = repository. Filename: draft-wu-avtcore-dynamic-pt-usage Revision: 00 Title: Guideline for dynamic payload type number usage policy Creation date: 2013-08-30 Group: Individual Submission Number of pages: 5 URL: = http://www.ietf.org/internet-drafts/draft-wu-avtcore-dynamic-pt-usage-00.= txt Status: = http://datatracker.ietf.org/doc/draft-wu-avtcore-dynamic-pt-usage Htmlized: = http://tools.ietf.org/html/draft-wu-avtcore-dynamic-pt-usage-00 Abstract: The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates RFC 3551 and provide guidelines for payload type number usage policy. = =20 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 From christer.holmberg@ericsson.com Fri Aug 30 09:36:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61321E805F for ; Fri, 30 Aug 2013 09:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUQl20XwJjD4 for ; Fri, 30 Aug 2013 09:36:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BC08921E808F for ; Fri, 30 Aug 2013 09:36:34 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-34-5220ca116216 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EE.05.22048.11AC0225; Fri, 30 Aug 2013 18:36:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Fri, 30 Aug 2013 18:36:32 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] BUNDLE DISCUSION Q8 (NEW): SDP 'bundle-only' attribute Thread-Index: Ac6lhqFY3iKihKwVS+CtvL9fvUs1JwABsU2AAARhNnY= Date: Fri, 30 Aug 2013 16:36:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C480C4F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C480AB8@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja7gKYUgg6PPJC2unfnHaDF1+WMW ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStjy+SDjAX/pSoaVrWzNTAeEuli5OSQEDCR 2NP8jQnCFpO4cG89WxcjF4eQwGFGibfHL0E5SxglJjw+ztzFyMHBJmAh0f1PG6RBREBXYtHZ B+wgYWYBdYmri4NAwsICPhI7zp1mgyjxlZj1u4MdwraSWPz+OVicRUBV4smc94wgNi9Qzb0z rYwQqyYxSty6ArKXg4NTIFBiynEDkBpGoNu+n1oDdiezgLjErSfzoW4WkFiy5zwzhC0q8fLx P1YIW1Fi59l2Zoh6A4n35+ZD2doSyxa+ZobYKyhxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKs YmTPTczMSS8338QIjJCDW34b7GDcdF/sEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF8UWlOanF hxiZODilGhjduwzZS99/ag785Wih6nDu3jSFifzl2ue7/1plXef8q75n+/lPAlHRc6tfB5ye yV7n2N1alrzsoU7Yxqq7TsXnYzdt+bJjy+LGyC3TyuJaV38w36zR5Hexi7vebftKTfb4b863 r+r85PT/usSCWXZLoYWYYsbf22viDE5u7Re48tRrHffbqWlKLMUZiYZazEXFiQDWVFSfXgIA AA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION Q8 (NEW): SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 16:36:54 -0000 Hi, >I think that you need to include in X.2.2 what the answerer puts in >port for the "m=3D" line if it intends to accept a bundle-only line. Good point.=20 I'll write that it adds the same BUNDLE address that is assigned to any oth= er m- line within the same BUNDLE group. Regards, Christer On 30 August 2013 06:48, Christer Holmberg wrote: > > > Hi, > > > > I started to draft some text for the definition of the SDP 'bundle-only' > attribute (my assumption is that it will be defined in draft-bundle). > > > > Note that, at this point, I don=92t suggest any normative text regarding = the > usage of port zero in the SDP Offer, as we are still discussing that (the > outcome of that discussion may affect at least the last paragraph in sect= ion > x.2.1.). > > > > Also note that I don=92t say anything about in which =93scope/context=94 = (webrtc > etc) the usage of the attribute is allowed. > > > > So, leaving the usage of port zero, and the scope question, aside for the > moment, please take a look and indicate whether you have any issues (at t= his > point, I ask you to focus on the technical stuff =96 and stuff which is > unclear) with the text :) > > > > Regards, > > > > Christer > > > > > > -------------------------- > > > > > > X. SDP 'bundle-only' attribute > > > > X.1. General > > > > This section defines a new SDP media-level attribute, 'bundle-only'. The > attribute > > is used, in an SDP Offer, to indicate that an "m=3D" line, to which the > attribute > > has been assigned, is only to be accepted by the Answerer if the Answerer > keeps > > the "m=3D" line within the BUNDLE group to which the "m=3D" line is assoc= iated > in the > > SDP Offer. > > > > > > X.2. SDP Offer/Answer Procedures > > > > X.2.1. SDP Offer Procedures > > > > When an Offerer sends an SDP Offer, which contains a BUNDLE group, it can > assign the > > SDP 'bundle-only' attribute to an "m=3D" line associated with the BUNDLE > group, > > in order to request that the Answerer only accepts the "m=3D" line if is = kept > within > > the BUNDLE group to which the "m=3D" line is associated in the SDP Offer. > > > > An Offerer MUST NOT assign the SDP 'bundle-only' attribute to an "m=3D" l= ine > that is not > > associated with a BUNDLE group. > > > > If an Offerer receives an SDP Answer where an "m=3D" line, to which it > assigned an > > 'bundle-only' attribute in the associated Offer, has been removed from a > BUNDLE group, but > > has not been rejected ([ref-to-section- 6.5.2.]), the Offerer MUST send a > new Offer, in which > > it assigns a zero port value to the "m=3D" line. > > > > > > X.2.2. SDP Answerer Procedures > > > > When an Answerer receives an SDP Offer ([ref-to-section- 6.5.]), the > Answerer MAY choose > > to remove an "m=3D" line out of a BUNDLE group ([ref-to-section- 6.5.2.])= . If > an SDP > > 'bundle-only' attribute has been assigned to such "m=3D" line, the Answer= er > MUST reject > > the "m=3D" line, according to the procedures in Section 6.5.3. > > > > An Answerer MUST NOT insert an SDP 'bundle-only' attribute in an SDP Answ= er. > > > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >= From hadriel.kaplan@oracle.com Fri Aug 30 10:07:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800EE21F9FBA for ; Fri, 30 Aug 2013 10:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09xYk1Mk5Fc7 for ; Fri, 30 Aug 2013 10:07:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id AD35D21F9E48 for ; Fri, 30 Aug 2013 10:07:22 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7UH7IHM016894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 17:07:19 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UH7HoE015315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 17:07:18 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UH7HPv016442; Fri, 30 Aug 2013 17:07:17 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 10:07:17 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C480AB8@ESESSMB209.ericsson.se> Date: Fri, 30 Aug 2013 13:07:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1C480AB8@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION Q8 (NEW): SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 17:07:41 -0000 This presumes there is such a thing as "bundle-only" m-lines. I don't believe we've determined consensus or not on your previous = proposal to get rid of them, which was a long thread starting here I = think: https://www.ietf.org/mail-archive/web/mmusic/current/msg12114.html -hadriel On Aug 30, 2013, at 9:48 AM, Christer Holmberg = wrote: > =20 > Hi, > =20 > I started to draft some text for the definition of the SDP = 'bundle-only' attribute (my assumption is that it will be defined in = draft-bundle). > =20 > Note that, at this point, I don=92t suggest any normative text = regarding the usage of port zero in the SDP Offer, as we are still = discussing that (the outcome of that discussion may affect at least the = last paragraph in section x.2.1.). > =20 > Also note that I don=92t say anything about in which =93scope/context=94= (webrtc etc) the usage of the attribute is allowed. > =20 > So, leaving the usage of port zero, and the scope question, aside for = the moment, please take a look and indicate whether you have any issues = (at this point, I ask you to focus on the technical stuff =96 and stuff = which is unclear) with the text :) > =20 > Regards, > =20 > Christer > =20 From christer.holmberg@ericsson.com Fri Aug 30 11:25:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BFF11E80FA for ; Fri, 30 Aug 2013 11:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqhvcEA4K6K8 for ; Fri, 30 Aug 2013 11:25:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 80C1221F9FF9 for ; Fri, 30 Aug 2013 11:25:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-71-5220e37b9f60 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E9.EB.16099.B73E0225; Fri, 30 Aug 2013 20:24:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 30 Aug 2013 20:24:59 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] BUNDLE DISCUSION Q8 (NEW): SDP 'bundle-only' attribute Thread-Index: Ac6lhqFY3iKihKwVS+CtvL9fvUs1JwAC/vEAAAbIcTA= Date: Fri, 30 Aug 2013 18:24:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C480F2C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C480AB8@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI 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+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvjW71Y4Ugg5YuY4tPmz4xW0xd/pjF gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4Mr4/TOsYB5PxfMD+g2MVzm7GDk5JARMJNo+ zGaDsMUkLtxbD2RzcQgJHGaUOPjmBTOEs4RRYvPnDqYuRg4ONgELie5/2iCmiICexNF7nCAm s4C6xNXFQSBjhAV8JD686mEHsUUEfCVm/e5gh6i2kth+1BokzCKgKnHt3gtWEJsXqKThVwMj xKJGRokVa2eC9XIK2EmcOvgN7DRGoNO+n1rDBGIzC4hLfDh4nRniZAGJJXvOQ9miEi8f/2OF sJUkfmy4xAJRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWM 7LmJmTnp5YabGIGxcXDLb90djKfOiRxilOZgURLn3aR3JlBIID2xJDU7NbUgtSi+qDQntfgQ IxMHp1QDo3ajaIiHQn26CI9gbPHZ0vi1xVx2suEujGkmQc5/bx78ef2TekDHj7VPtdn/rN8V c/il5q+OO9Llnwu2GEmpNm0+l7RA6Hp6KN8dPps4pdlM368Yy19Pzkjd+MCh7MSW8By3xr3z Kh7W1+fe5VixNfyIywTe1qrIZP3Ls1OWluXpXrIWnBupxFKckWioxVxUnAgAOEQCtFsCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE DISCUSION Q8 (NEW): SDP 'bundle-only' attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:25:09 -0000 Hi, >This presumes there is such a thing as "bundle-only" m-lines. > >I don't believe we've determined consensus or not on your previous proposa= l to get rid of them, which was a long thread starting here I think: >https://www.ietf.org/mail-archive/web/mmusic/current/msg12114.html My issue has not been with the 'bundle-attribute', but with the usage of po= rt zero, and that e-mail was a suggestion on how to get rid of that. However, when re-reading that e-mail, if we would go ahead with my suggesti= on it might also remove the need for the attribute... Regards, Christer On Aug 30, 2013, at 9:48 AM, Christer Holmberg wrote: > =20 > Hi, > =20 > I started to draft some text for the definition of the SDP 'bundle-only' = attribute (my assumption is that it will be defined in draft-bundle). > =20 > Note that, at this point, I don't suggest any normative text regarding th= e usage of port zero in the SDP Offer, as we are still discussing that (the= outcome of that discussion may affect at least the last paragraph in secti= on x.2.1.). > =20 > Also note that I don't say anything about in which "scope/context" (webrt= c etc) the usage of the attribute is allowed. > =20 > So, leaving the usage of port zero, and the scope question, aside for the= moment, please take a look and indicate whether you have any issues (at th= is point, I ask you to focus on the technical stuff - and stuff which is un= clear) with the text :) > =20 > Regards, > =20 > Christer > =20 From hadriel.kaplan@oracle.com Fri Aug 30 13:28:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDAD11E8123 for ; Fri, 30 Aug 2013 13:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyaZK1aFAjVH for ; Fri, 30 Aug 2013 13:27:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB3F11E8122 for ; Fri, 30 Aug 2013 13:27:52 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7UKRlhp007666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Aug 2013 20:27:48 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UKRlGL021392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 20:27:47 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7UKRkiw021380; Fri, 30 Aug 2013 20:27:46 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Aug 2013 13:27:46 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C480A75@ESESSMB209.ericsson.se> Date: Fri, 30 Aug 2013 16:27:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5DE22A0F-257F-4F86-B2A8-7E8627D96D6A@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C47762C@ESESSMB209.ericsson.se> <521CACD4.6060904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4809D7@ESESSMB209.ericsson.se> <968A751E-C145-4799-9479-417D850F50A6@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C480A75@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 20:28:02 -0000 On Aug 30, 2013, at 9:39 AM, Christer Holmberg = wrote: > Hi, >=20 >>> We also need to decide whether that change also applies to when new = media descriptions (m- line) are added to a previously negotiated BUNDLE = group. >>> Currently the text says that, when an m- line is added, it must = contain either a unique address, or a previously negotiated BUNDLE = address. >>> But, since we now allow to assign a new, yet not confirmed, BUNDLE = address to multiple m- lines, I guess that applies also to a new m- = line. >>=20 >> But then if the far-end answered with accepting it for the same = bundle, then you'd have to send another offer with the m-line using the = correct port of the bundle group, right? >=20 > The change is that an Offerer is now allowed to assign the same = address (the requested BUNDLE address) to all m- lines in the BUNDLE = group BEFORE the Answerer has "confirmed" the address=20 > to become the Offerer's BUNDLE address. >=20 > So, if the requested BUNDLE address was assigned to all m- lines in = the BUNDLE group, and the Answerer accepts it, there is obviously no = need to send a second offer. >=20 > But, if any of the m- lines in the offer did NOT contain the selected = BUNDLE address, a second Offer is still required :) Actually, on reflection it doesn't need to send a new offer even if the = far-end didn't want bundle. =20 As the offerer, if you want to add an m-line with bundle, simply use the = the same port numbers as the existing bundle. If the answerer responds = with its same port number for its side of the bundle, you're done. If = the answerer decides it didn't want that new m-line to be bundled, it = will simply pick a new port number in its answer. You're still done. = Because it's not the same 5-tuple. (it happens to be the same local = source port number on the offerer, but not the same dest port)=20 If the offerer now wants a new local port number for some reason (like = it can't handle distinguishing full 5-tuples) it can send another offer = to use a new port number for that m-line. -hadriel From christer.holmberg@ericsson.com Fri Aug 30 23:55:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F24421F862B for ; Fri, 30 Aug 2013 23:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+I4Spts8HeP for ; Fri, 30 Aug 2013 23:55:35 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6622121F85B8 for ; Fri, 30 Aug 2013 23:55:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-c2-5221935a6093 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 99.73.16099.A5391225; Sat, 31 Aug 2013 08:55:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 31 Aug 2013 08:55:22 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. Thread-Index: Ac6f7OG1P0YUwhF6Remol1dqLcLlOQDLal4AAJiyiVD//+hjAP//16UQgACiigCAAM7gUw== Date: Sat, 31 Aug 2013 06:55:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4814A1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C47762C@ESESSMB209.ericsson.se> <521CACD4.6060904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4809D7@ESESSMB209.ericsson.se> <968A751E-C145-4799-9479-417D850F50A6@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C480A75@ESESSMB209.ericsson.se>, <5DE22A0F-257F-4F86-B2A8-7E8627D96D6A@oracle.com> In-Reply-To: <5DE22A0F-257F-4F86-B2A8-7E8627D96D6A@oracle.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW7UZMUgg02fLS0+bfrEbDF1+WMW ixUbDrA6MHv8ff+ByWPJkp9MHh+f3mIJYI7isklJzcksSy3St0vgyjiy5xxLwWWRiob2V0wN jIsEuhg5OSQETCS+73rPCmGLSVy4t56ti5GLQ0jgMKPEvr+zoZwljBKtz+4xdTFycLAJWEh0 /9MGMUUE9CSO3uME6WUW8JV4ueALM4gtLHCeUeJXcxFIq4jABUaJG3seskDUh0ksXl0NUsMi oCpxf9JdRhCbF6j3+tvJzBCr7jJJND66DpbgFLCTmLl4JRuIzQh03PdTa5gglolL3Hoynwni aAGJJXvOM0PYohIvH/+DekZR4uOrfYwQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExjFZiEZ OwtJyywkLbOQtCxgZFnFyJ6bmJmTXm64iREYNwe3/NbdwXjqnMghRmkOFiVx3k16ZwKFBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MNo2t5kW5xa85NVw+/kg9SnDzJ0X2iyc2q6s5HYuFvnn cXR63YNp+9Nl7gmxVsTfVXXm1rXUXf9y8/Juxv1Wx2o1GcQ5Wm6f3PhMwpE9i7//0LUHDAF+ n487hx3NsWi04V2ZfC37zpKKLPVnx1kZErhqf++Uj7kWWm3nl8XDu4BxxpVv38xnK7EUZyQa ajEXFScCACtBTuZpAgAA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 06:55:42 -0000 Hi, >>>> We also need to decide whether that change also applies to when new me= dia descriptions (m- line) are added to a previously negotiated BUNDLE grou= p. >>>> Currently the text says that, when an m- line is added, it must contai= n either a unique address, or a previously negotiated BUNDLE address. >>>> But, since we now allow to assign a new, yet not confirmed, BUNDLE add= ress to multiple m- lines, I guess that applies also to a new m- line. >>> >>> But then if the far-end answered with accepting it for the same bundle,= then you'd have to send another offer with the m-line using the correct po= rt of the bundle group, right? >> >> The change is that an Offerer is now allowed to assign the same address = (the requested BUNDLE address) to all m- lines in the BUNDLE group BEFORE t= he Answerer has "confirmed" the address >> to become the Offerer's BUNDLE address. >> >> So, if the requested BUNDLE address was assigned to all m- lines in the = BUNDLE group, and the Answerer accepts it, there is obviously no need to se= nd a second offer. >> >> But, if any of the m- lines in the offer did NOT contain the selected BU= NDLE address, a second Offer is still required :) > > Actually, on reflection it doesn't need to send a new offer even if the f= ar-end didn't want bundle. > > As the offerer, if you want to add an m-line with bundle, simply use the = the same port numbers as the existing bundle. If the answerer responds=20 > with its same port number for its side of the bundle, you're done. If th= e answerer decides it didn't want that new m-line to be bundled, it will si= mply=20 > pick a new port number in its answer. You're still done. Because it's n= ot the same 5-tuple. (it happens to be the same local source port number on= the offerer, but not the same dest port) > > If the offerer now wants a new local port number for some reason (like it= can't handle distinguishing full 5-tuples) it can send another offer to us= e a new port number for that m-line. That is a separate topic, more related to the Answerer procedures, and is n= ot alligned with the current BUNDLE text. Currently, if an m- line (no matt= er whether it is a new m- line, or a previously added one) in an Offer cont= ains a BUNDLE address, and the Answerer doesn't want it to be bundled, it M= UST be rejected with port zero. We have been discussing, and it is what my original bundle proposal describ= ed, the usage of a single address on the Offerer side even if the Answerer = uses separate ports, and I thought we decided not to go that way... Regards, Christer= From hadriel.kaplan@oracle.com Sat Aug 31 04:52:51 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0819121F9D23 for ; Sat, 31 Aug 2013 04:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmKvdQKuSntR for ; Sat, 31 Aug 2013 04:52:31 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3377111E80EC for ; Sat, 31 Aug 2013 04:52:25 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7VBqKWP020042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 31 Aug 2013 11:52:21 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7VBqI6u005436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Aug 2013 11:52:19 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7VBqIwE005432; Sat, 31 Aug 2013 11:52:18 GMT Received: from [192.168.2.10] (/69.131.62.50) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 31 Aug 2013 04:52:18 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4814A1@ESESSMB209.ericsson.se> Date: Sat, 31 Aug 2013 07:52:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <792914D0-6BF9-4D46-80C5-25D4678D707C@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C47762C@ESESSMB209.ericsson.se> <521CACD4.6060904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4809D7@ESESSMB209.ericsson.se> <968A751E-C145-4799-9479-417D850F50A6@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C480A75@ESESSMB209.ericsson.se>, <5DE22A0F-257F-4F86-B2A8-7E8627D96D6A@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C4814A1@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 11:52:51 -0000 On Aug 31, 2013, at 2:55 AM, Christer Holmberg = wrote: > That is a separate topic, more related to the Answerer procedures, and = is not alligned with the current BUNDLE text. Currently, if an m- line = (no matter whether it is a new m- line, or a previously added one) in an = Offer contains a BUNDLE address, and the Answerer doesn't want it to be = bundled, it MUST be rejected with port zero. >=20 > We have been discussing, and it is what my original bundle proposal = described, the usage of a single address on the Offerer side even if the = Answerer uses separate ports, and I thought we decided not to go that = way=85 No the issue with the Offer using the same ports is an issue for the = *initial* offer, before the offerer knows the far-end supports bundle. = In the above I was talking about the subsequent offers/answers, once the = offerer knows the far-end supports bundle. Regardless, I suppose we really do need to have the 'bundle-only' = attribute anyway, just to enable the offerer to say "I am only offering = these m-lines using the same bundle transport, and if you don't want to = do that then I want them to not be used at all". -hadriel From christer.holmberg@ericsson.com Sat Aug 31 08:36:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3121F85BB for ; Sat, 31 Aug 2013 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.945 X-Spam-Level: X-Spam-Status: No, score=-5.945 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wfZvrigrO+7 for ; Sat, 31 Aug 2013 08:36:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 977D411E8146 for ; Sat, 31 Aug 2013 08:36:13 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-5d-52220d6813bb Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F5.F3.22048.86D02225; Sat, 31 Aug 2013 17:36:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sat, 31 Aug 2013 17:36:08 +0200 From: Christer Holmberg To: Hadriel Kaplan Thread-Topic: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. Thread-Index: Ac6f7OG1P0YUwhF6Remol1dqLcLlOQDLal4AAJiyiVD//+hjAP//16UQgACiigCAAM7gU4AAM26AgABeIwo= Date: Sat, 31 Aug 2013 15:36:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C481723@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C47762C@ESESSMB209.ericsson.se> <521CACD4.6060904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4809D7@ESESSMB209.ericsson.se> <968A751E-C145-4799-9479-417D850F50A6@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C480A75@ESESSMB209.ericsson.se>, <5DE22A0F-257F-4F86-B2A8-7E8627D96D6A@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C4814A1@ESESSMB209.ericsson.se>, <792914D0-6BF9-4D46-80C5-25D4678D707C@oracle.com> In-Reply-To: <792914D0-6BF9-4D46-80C5-25D4678D707C@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW4Gr1KQwd0mPYtPmz4xW0xd/pjF YsWGA6wOzB5/339g8liy5CeTx8ent1gCmKO4bFJSczLLUov07RK4MqacPsxS8IKnYsPcRYwN jJ1cXYycHBICJhIzX0xlhrDFJC7cW8/WxcjFISRwmFHiyfvl7BDOEkaJrZf+A2U4ONgELCS6 /2mDmCICehJH73GC9DIL+Eq8XPAFbI6wwHlGiV/NRSCtIgIXGCVu7HnIApIQEUiS2HC2gRHE ZhFQlTjRthMszgvU/PPrXqjFl5kluk8cYgNJcArYSbS1fGQCsRmBrvt+ag0TxDZxiVtP5jNB XC0gsWTPeagPRCVePv7HCmErSlydvhyq3kDi/bn5zBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRj ZyFpmYWkZRaSlgWMLKsY2XMTM3PSy803MQIj5+CW3wY7GDfdFzvEKM3BoiTOu1nvTKCQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxgOssSZKNnIfkp0YP3/4GJviLXfq8x3tVAalL8scghvm F3M93aN/Y2J7x+LMvsuxq9ex7n57QnTuOh42u38zDus9t77c7cbHtCvpeFHnNQ6ZSPF3b1Vj H/+Ie7Tq+7O9IS/5bL/aLtvcqRn641Fswn4Z0QdsKzgmBtfvWKnSmvdN4tSKgiPT4pVYijMS DbWYi4oTAYEO4/FqAgAA Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] DECISION (BERLIN-Q5): When the BUNDLE address is RE-negotiated, the Offerer can assign the requsted new address to all m- lines immediately, without first offering unique addresses. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 15:36:36 -0000 Hi, >> That is a separate topic, more related to the Answerer procedures, and i= s not alligned with the current BUNDLE text. Currently, if an=20 >> m- line (no matter whether it is a new m- line, or a previously added on= e) in an Offer contains a BUNDLE address, and the Answerer=20 >> doesn't want it to be bundled, it MUST be rejected with port zero. >> >> We have been discussing, and it is what my original bundle proposal desc= ribed, the usage of a single address on the Offerer side even if the Answer= er uses separate ports, and I thought we decided not to go that way=85 > > No the issue with the Offer using the same ports is an issue for the *ini= tial* offer, before the offerer knows the far-end supports bundle. In the = above I was talking about the subsequent offers/answers, once the offerer k= nows the far-end supports bundle. Fair enough. But, it's still not specific to 'bundle-only' m- lines. > Regardless, I suppose we really do need to have the 'bundle-only' attribu= te anyway, just to enable the offerer to say "I am only offering these m-li= nes using the same bundle transport, and if you don't want to do that then = I want them to not be used at all". With the CURRENT rules you do that by assigning the BUNDLE address to those= m- lines, because the Answerer must reject them in case they are removed f= rom the BUNDLE group. But, IF we want to change that (for mid-call O/As), there might be a need f= or an explicit attribute. In any case, we can work on the text for now, and then later throw it away = if we find out it's not needed :) Regards, Christer=
I ASSUME the above is clear to everyone, including the authors of the = UP, but IF someone has a different opinion I'd like to hear about it :)
 
Regards,
 
Christer
 
 

Sent from Windows using TouchDown (www.nitrodesk.com)
--_000_7594FB04B1934943A5C02806D1A2204B1C41EC88ESESSMB209erics_-- From pkyzivat@alum.mit.edu Tue Aug 6 09:31:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3283321E808D for ; Tue, 6 Aug 2013 09:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N89ASxdo7vTo for ; Tue, 6 Aug 2013 09:31:20 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 41EC021F9A2E for ; Tue, 6 Aug 2013 09:31:18 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta06.westchester.pa.mail.comcast.net with comcast id 9PV61m0051ap0As56UXHzD; Tue, 06 Aug 2013 16:31:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 9UXH1m01C3ZTu2S3iUXHNp; Tue, 06 Aug 2013 16:31:17 +0000 Message-ID: <520124D5.50805@alum.mit.edu> Date: Tue, 06 Aug 2013 18:31:17 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41EC88@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=q20121106; t=1375806677; bh=NkgyCzDk+Y9BElZpnfEHUsFJjd/ZXnRMle0WpCDN3oU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JLe+m6Cbdn2H0aUvVQ/wKUFN75xAiLYODvGprnoAhBA7VAAcLVAcud9Vwtttqh5VV tocy3+3aEufy4Qmo84aKMDqcNJZJzUTz92IOAAK/59LPu1o6G3U9oFywRMdc++v8VT 1wtVzWdIBWSrQsKWUuCa2zpja2uq4s6PgjI6HJw3YV/6IjG9r4g606vMj4yWkM1lFd RxU9Tc5cBMFK/Yq7MDd6o/dcs8Eznxh+fa907hQKWjQZXtuI+okX40NGMBTaRGbsBi cIebJgZ60hJjZMgbOcnVQBy/8ShWOKtEZQPvvU0CoZQpd4ZqZKRLwrvKVE1iRvo0PR TnnXm9pY4ETHw== Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:31:25 -0000 I agree with Christer. I wonder if Adam is assuming that the Offers, Answers, POFs, and PANs used in WebRTC are all serialized over a reliable channel? That would simplify things because it will ensure how they relate to one another, though it doesn't prevent the glare Christer describes. If this is totally discarding 3264, then I *guess* you could define that O/A is only used once, and after that changes are made exclusively with POFs and PANs. But I don't have the sense that is being proposed. IMO it makes much more sense to analyze this as an extension to 3264. I also think these POFs and PANs should have the o-line to confirm what prior SDP the new one updates. (It is more important than it is with regular O/A.) Thanks, Paul On 8/6/13 6:14 PM, Christer Holmberg wrote: > > Hi, > It has been indicated that POFs (partial offers) and PANs (partial > answers) form a stand-alone mechanism, instead of being an extension of > RFC3264. > > Now, assuming that is true, we still need to describe the interaction > between POFs, PANs and 3264 Offer/Answers. > Because, if I send a POF, and then receive a 3264 Offer (including the > same m- line as the POF), there is a glare and I need to reject the > 3264 Offer. > In the same way, if I send a 3264 Offer, and receive a POF (including > the same m- line as the 3264 Offer), there is a glare and I need to > reject the POF. > I ASSUME the above is clear to everyone, including the authors of the > UP, but IF someone has a different opinion I'd like to hear about it :) > Regards, > Christer > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From christer.holmberg@ericsson.com Tue Aug 6 11:02:53 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228BD21F9EAA for ; Tue, 6 Aug 2013 11:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkQcl-pb3xpE for ; Tue, 6 Aug 2013 11:02:48 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DD6FB21E808D for ; Tue, 6 Aug 2013 11:02:31 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-71-52013a35b625 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 82.FF.05990.53A31025; Tue, 6 Aug 2013 20:02:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 6 Aug 2013 20:02:28 +0200 From: Christer Holmberg To: Paul Kyzivat , mmusic_ietf.org Thread-Topic: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers Thread-Index: Ac6SwAaH+8B2wVyxQFSEGu6rKTxpcf//4yuAgAA7As4= Date: Tue, 6 Aug 2013 18:02:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41F15B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se>, <520124D5.50805@alum.mit.edu> In-Reply-To: <520124D5.50805@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C41F15BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra6pFWOQwY5DghZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx+eMDtoJ5phW/DreyNDDe1+li5OSQEDCR +HqrjR3CFpO4cG89WxcjF4eQwGFGid19B6GcxYwSO462MnYxcnCwCVhIdP/TBmkQEfCW+NBw mhXEFhbwkdh8cQEzSImIgK/E+Sk1EKaVRO8ZsAoWARWJuzPOMIPYvEAVZ1uWg8WFBLIlHs/a xQhicwpoSWzouwFmMwKd8/3UGiYQm1lAXOLWk/lMEGcKSCzZc54ZwhaVePn4HytETb7EvBfr WCHmC0qcnPmEZQKj8Cwk7bOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMbLn JmbmpJcbbWIExsfBLb9VdzDeOSdyiFGag0VJnHez3plAIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYwiunnhpjyNi/a23I7/NEfqOHd/1TVVPtH1Fsuy0y/4HLYQbzuz+WPC19B1l95suvL/ mPbXn4t331i99l+too3PNMNHIbsYrFZ1S1aFHqv1yHz8blvry6K/38NmrtifYGM1ZUWFgG6+ +9SwaTZ8B++uVhLoU3Twv7biVgzjsitsC2Zd5rzPuc1KiaU4I9FQi7moOBEAmfqDjV0CAAA= Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 18:02:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C41F15BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Of course, in some cases (e.g. in JSEP) there might not even be a need to d= istinguish between POFs/PANs and 3264 Offer/Answers. Regards, Christer Sent from Windows using TouchDown (www.nitrodesk.com) -----Original Message----- From: Paul Kyzivat [pkyzivat@alum.mit.edu] To: mmusic@ietf.org [mmusic@ietf.org] Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answer= s I agree with Christer. I wonder if Adam is assuming that the Offers, Answers, POFs, and PANs used in WebRTC are all serialized over a reliable channel? That would simplify things because it will ensure how they relate to one another, though it doesn't prevent the glare Christer describes. If this is totally discarding 3264, then I *guess* you could define that O/A is only used once, and after that changes are made exclusively with POFs and PANs. But I don't have the sense that is being proposed. IMO it makes much more sense to analyze this as an extension to 3264. I also think these POFs and PANs should have the o-line to confirm what prior SDP the new one updates. (It is more important than it is with regular O/A.) Thanks, Paul On 8/6/13 6:14 PM, Christer Holmberg wrote: > > Hi, > It has been indicated that POFs (partial offers) and PANs (partial > answers) form a stand-alone mechanism, instead of being an extension of > RFC3264. > > Now, assuming that is true, we still need to describe the interaction > between POFs, PANs and 3264 Offer/Answers. > Because, if I send a POF, and then receive a 3264 Offer (including the > same m- line as the POF), there is a glare and I need to reject the > 3264 Offer. > In the same way, if I send a 3264 Offer, and receive a POF (including > the same m- line as the 3264 Offer), there is a glare and I need to > reject the POF. > I ASSUME the above is clear to everyone, including the authors of the > UP, but IF someone has a different opinion I'd like to hear about it :) > Regards, > Christer > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com) > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B1C41F15BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Of course, in some cases (e.g. in JSEP) there might n= ot even be a need to distinguish between POFs/PANs and 3264 Offer/Answers.
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [pkyzivat@alum.mit.edu]
To: mmusic@ietf.org [mmusic@ietf.org]
Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer= /Answers
I agree with Christer.

I wonder if Adam is assuming that the Offers, Answers, POFs, and PANs
used in WebRTC are all serialized over a reliable channel? That would
simplify things because it will ensure how they relate to one another,
though it doesn't prevent the glare Christer describes.

If this is totally discarding 3264, then I *guess* you could define that O/A is only used once, and after that changes are made exclusively with POFs and PANs. But I don't have the sense that is being proposed.

IMO it makes much more sense to analyze this as an extension to 3264.

I also think these POFs and PANs should have the o-line to confirm what prior SDP the new one updates. (It is more important than it is with
regular O/A.)

        Thanks,
        Paul

On 8/6/13 6:14 PM, Christer Holmberg wrote:
>
> Hi,
> It has been indicated that POFs (partial offers) and PANs (partial
> answers) form a stand-alone mechanism, instead of being an extension o= f
> RFC3264.
>
> Now, assuming that is true, we still need to describe the interaction<= br> > between POFs, PANs and 3264 Offer/Answers.
> Because, if I send a POF, and then receive a 3264 Offer (including the=
> same m- line as the POF),  there is a glare and I need to reject = the
> 3264 Offer.
> In the same way, if I send a 3264 Offer, and receive a POF (including<= br> > the same m- line as the 3264 Offer), there is a glare and I need to > reject the POF.
> I ASSUME the above is clear to everyone, including the authors of the<= br> > UP, but IF someone has a different opinion I'd like to hear about it := )
> Regards,
> Christer
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B1C41F15BESESSMB209erics_-- From adam@nostrum.com Tue Aug 6 16:30:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1226321E809B for ; Tue, 6 Aug 2013 16:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFl5HxTxMmW4 for ; Tue, 6 Aug 2013 16:30:45 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7E221E80AD for ; Tue, 6 Aug 2013 16:30:45 -0700 (PDT) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r76NUfdB097121 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 18:30:41 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5201871B.4090903@nostrum.com> Date: Tue, 06 Aug 2013 18:30:35 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------050401090107020208060904" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: mmusic Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 23:30:46 -0000 This is a multi-part message in MIME format. --------------050401090107020208060904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/6/13 11:14, Christer Holmberg wrote: > It has been indicated that POFs (partial offers) and PANs (partial > answers) form a stand-alone mechanism, instead of being an extension > of RFC3264. > > Now, assuming that is true, we still need to describe the interaction > between POFs, PANs and 3264 Offer/Answers. > Because, if I send a POF, and then receive a 3264 Offer (including the > same m- line as the POF), there is a glare and I need to reject the > 3264 Offer. > In the same way, if I send a 3264 Offer, and receive a POF (including > the same m- line as the 3264 Offer), there is a glare and I need to > reject the POF. > I ASSUME the above is clear to everyone, including the authors of the > UP, but IF someone has a different opinion I'd like to hear about it :) > That is certainly what I had been assuming. Of course, if the POF is a new m-line (that is, it doesn't appear in the offer coming the other way), then there is no glare condition. /a --------------050401090107020208060904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/6/13 11:14, Christer Holmberg wrote:
 
It has been indicated that POFs (partial offers) and PANs (partial answers) form a stand-alone mechanism, instead of being an extension of RFC3264.

Now, assuming that is true, we still need to describe the interaction between POFs, PANs and 3264 Offer/Answers.
 
Because, if I send a POF, and then receive a 3264 Offer (including the same m- line as the POF),  there is a glare and I need to reject the 3264 Offer.
 
In the same way, if I send a 3264 Offer, and receive a POF (including the same m- line as the 3264 Offer), there is a glare and I need to reject the POF.
 
I ASSUME the above is clear to everyone, including the authors of the UP, but IF someone has a different opinion I'd like to hear about it :)
 


That is certainly what I had been assuming. Of course, if the POF is a new m-line (that is, it doesn't appear in the offer coming the other way), then there is no glare condition.

/a
--------------050401090107020208060904-- From bernard_aboba@hotmail.com Tue Aug 6 16:50:30 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD96021F8F24 for ; Tue, 6 Aug 2013 16:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPxWB1N9uEN8 for ; Tue, 6 Aug 2013 16:50:22 -0700 (PDT) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id 212CC21E80C9 for ; Tue, 6 Aug 2013 16:50:21 -0700 (PDT) Received: from BLU169-W132 ([65.55.116.73]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Aug 2013 16:50:21 -0700 X-TMN: [GmmI+vtDXh3TT4nUNStPyJkULDjg7of8zoA35byIjPc=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_7e5baefb-478a-4e6e-8571-420b7a7708af_" From: Bernard Aboba To: Christer Holmberg , mmusic Date: Tue, 6 Aug 2013 16:50:20 -0700 Importance: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 06 Aug 2013 23:50:21.0040 (UTC) FILETIME=[B6233700:01CE92FF] Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 23:50:30 -0000 --_7e5baefb-478a-4e6e-8571-420b7a7708af_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer said:=20 =20 =0A= "While cleaning up my MMUSIC notes today=2C I was listening to the audio re= cording=2C in order to get a clarification regarding what "scope is WEBRTC"= really means. However=2C unless I missed something=2C I didn't get a clea= r answer.=0A= =0A= Does it only cover the browser API (JSEP) or does it also cover something t= hat can be sent out on the wire (as long as it is not SIP) by a browser?=0A= =0A= Feel free to tell me that it is a stupid question=2C and that the answer is= very clear :)" [BA] I actually think it is a good question :) One interpr= etation of "scope is WebRTC" is that the SDP in "Unified Plan" applies to= use within the JSEP API. As a result=2C one might expect the SDP used = in createOffer=2C setLocalDescription and setRemoteDescription to resemble = that in the "Unified Plan" document. Since signaling is out of scope for = WebRTC=2C applications that use the JSEP API might or might not use the "Un= ified Plan" SDP in signaling on the wire. However=2C "Unified Plan" inclu= des normative references to published SDP specifications that were develope= d for general use=2C and the adoption of "Unified Plan" (or even an applica= bility statement within the "Unified Plan" document) doesn't change the app= licability of those documents. Also=2C there may be some specifications th= at are part of the "Unified Plan" workload that may have applicability beyo= nd WebRTC (e.g. a=3Dgroup: SIMULCAST) Ultimately=2C I am expecting the wor= k involved in "Unified Plan" to span multiple documents=2C and to clarify t= he applicability=2C those individual documents will need to explain what t= hey apply to (just WebRTC use or more general use). = --_7e5baefb-478a-4e6e-8571-420b7a7708af_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Christer said:
 =3B
<= div>=0A=
"While cleaning up my MMUSIC notes today=2C I w= as listening to the audio recording=2C in order to get a clarification rega= rding what "scope is WEBRTC" really means. =3B However=2C unless I miss= ed something=2C I didn't get a clear answer.
=0A=
 =3B
=0A=
Does it only cover the browser API (JSEP) = =3Bor does it also cover something that can be sent out on the wire (as lon= g as it is not SIP) by a browser?
=0A=
 =3B
=0A=
Feel free to tell me that it is a stupid questi= on=2C and that the answer is very clear :)"
 =3B
=
[BA] =3B I actually think it is a good question :)
 = =3B
One interpretation of =3B"scope is WebRTC" =3B = =3Bis that the  =3BSDP in "Unified Plan" =3Bapplies to use within &= nbsp=3Bthe JSEP API.  =3B =3B =3BAs a result=2C one might = =3Bexpect the SDP used in createOffer=2C setLocalDescription and setRemoteD= escription to resemble that in the "Unified Plan" document. =3B =3B= Since signaling is out of scope for WebRTC=2C applications that use the JS= EP API might or might not use the =3B"Unified Plan" SDP in signaling on= the wire. =3B
 =3B
However=2C "Unified Plan"&= nbsp=3Bincludes normative references =3Bto =3Bpublished SDP specifi= cations that were developed for general use=2C and the adoption of "Unified= Plan" (or even an applicability statement =3Bwithin the =3B"Unifie= d Plan" document) doesn't change the applicability of those documents.
 =3B
Also=2C there may be some specifications that are= part of the "Unified Plan" workload that may have applicability beyond Web= RTC (e.g. a=3Dgroup: SIMULCAST)
 =3B
Ultimately=2C= I am expecting the work involved in "Unified Plan" to span multiple docume= nts=2C and to clarify the applicability=2C =3B those individual documen= ts will need to explain what they apply to (just WebRTC use or more general= use). =3B
= --_7e5baefb-478a-4e6e-8571-420b7a7708af_-- From hadriel.kaplan@oracle.com Tue Aug 6 19:55:47 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96DD21F9B86 for ; Tue, 6 Aug 2013 19:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jApO7EhsTob for ; Tue, 6 Aug 2013 19:55:41 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id C973F21F8F97 for ; Tue, 6 Aug 2013 19:55:41 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r772tb2f001999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 02:55:38 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r772ta5t004305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 02:55:37 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r772ta5u012910; Wed, 7 Aug 2013 02:55:36 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Aug 2013 19:55:36 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41DBA6@ESESSMB209.ericsson.se> Date: Tue, 6 Aug 2013 22:55:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <687A90C3-8A3F-43BC-9755-90F1CC147BB7@oracle.com> References: <7594FB04B1934943A5C02806D1A2204B1C41D191@ESESSMB209.ericsson.se> <262469F4-1F64-4FA0-91A3-102A937E0E7D@oracle.com> <51FFC541.1060406@nostrum.com> <74024C75-90B0-421C-A1A5-5A67FB02AE1C@oracle.com> <51FFCBE8.9030601@nostrum.com>, <7594FB04B1934943A5C02806D1A2204B1C41DBA6@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero usage in bundled m- lines (SDP Offers only) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 02:55:47 -0000 On Aug 5, 2013, at 1:05 PM, Christer Holmberg = wrote: > In SIP, unless you have control of each node between the endpoints, = the only way to guarantee a "consistent break" is by using = Proxy-Require. > But, as we know, that sucks, because it would mandate entities that = could not care less about SDP (yes, such entities DO still exist :) to = support bundle-only. > Regards,=20 > Christer Technically, I think you'd have to put something in both Proxy-Require = and Require. But that would make it virtually DOA, from a practical = perspective. It would fail constantly. I realize that's kinda the = point, to fail early, but failing all the time probably isn't the point. The other challenge is it's not just about SBCs, B2BUAs, app servers, = etc. It's also about the lovely "ALGs" in NATs, CGNs, and Firewalls, = and the passive inspecting things made by certain popular router vendors = - you know, all the things that ostensibly prevented us from adding two = bytes for an RTP shim header to mux/demux, even though somehow we can = now add more bytes as RTP extension headers instead - those things don't = understand or involve themselves with Proxy-Require/Require, as far as I = can tell. -hadriel > -----Original Message----- > From: Hadriel Kaplan [hadriel.kaplan@oracle.com] > To: Adam Roach [adam@nostrum.com] > CC: mmusic (E-mail) [mmusic@ietf.org] > Subject: Re: [MMUSIC] BUNDLE QUESTIONS Q10/Q11: Scope of port zero = usage in bundled m- lines (SDP Offers only) >=20 > On Aug 5, 2013, at 11:59 AM, Adam Roach wrote: >=20 > > On 8/5/13 10:39, Hadriel Kaplan wrote: > >> No, I'm concerned with usages other than WebRTC. The question was = on whether the bundle-only port-0 thing should be generically = applicable, or scoped to WebRTC. So I'm thinking of what its impact is = on SIP usage in the real world, including on things that go bump in the = night. All kinds of crap happens in the middle these days in SIP = networks. (and no, not only with SBCs) > >=20 > > I don't think I'd expect bundle-only lines to work through = extra-specification bumps in the wire. If the bumps are upgraded to work = with bundle, great, but I know that this won't happen overnight (and, = for many corners of the network, ever). But given that these bumps in = some sense serve as the "other end" of the connection, a failure to get = bundle-only lines through them is merely the design working per its = requirements. > >=20 > > Remember, we're designing these lines to be fragile on purpose. = That's the whole point of using a zero port: if we don't have end-to-end = understanding of bundle-only, we need them to break. >=20 > Sure, but the problem I'm worried about is when they break in weird = ways - like they fail in the answer phase rather than offer phase; or = they appear to succeed in SDP, but there's no media; or not enough = bandwidth is allocated in controlled pipes; or the call gets torn down = some time later by those bumps-in-the-wire. >=20 > -hadriel >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From martin.thomson@gmail.com Tue Aug 6 22:44:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD2311E8109 for ; Tue, 6 Aug 2013 22:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcABTS-6AYqm for ; Tue, 6 Aug 2013 22:44:09 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F2B7411E80FF for ; Tue, 6 Aug 2013 22:44:08 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so1155537wes.31 for ; Tue, 06 Aug 2013 22:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Tp3Fqo3L3HJ/GE1u/81khd+PEf35Htrksse8bkdBsA=; b=XCejU3t6d9G4ONGs1lhoCzq9hI/W1ckAgErbavesmGQ1kNuIXtoIQ7FzQD72oh3ML3 E9m46aEaBJNsvbUJLGadUhMR75WBE7IRq7cEKHAdKSdO7qkn3aBfSXFcb/KgOSiTO8sC C48Vk8e1sm0LpcsHSPuuY4JORhPIfk9fOD2TQGpSPhoOaHpwy6ulgjfwbMizBXatcngM UvazAUvu+DTv1OBmlRFSI/BeS61O0NxmS72CrphJGssnzAeQtpJB4Y74gsZUBNXy4HMm PM6am9xc41ppB2obGCRAjNM5sKvNpTsQHi1meyPtUbOTyEJ6Chv7BOf/pC6/+wAsgmO8 3kuA== MIME-Version: 1.0 X-Received: by 10.180.92.1 with SMTP id ci1mr1026404wib.14.1375854248027; Tue, 06 Aug 2013 22:44:08 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Tue, 6 Aug 2013 22:44:07 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41E15C@ESESSMB209.ericsson.se> References: <51F93E68.20705@alum.mit.edu> <7679150D-0BD4-4BF6-B178-64704CAD5D42@oracle.com> <52001847.3090805@alum.mit.edu> <45E41954-372E-4483-B526-1C92EF0656C8@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41E15C@ESESSMB209.ericsson.se> Date: Wed, 7 Aug 2013 07:44:07 +0200 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] unified plan glareless atomicity improvement X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 05:44:09 -0000 On 6 August 2013 00:55, Christer Holmberg wrote: > If you use separate m- lines per media direction, there MAY be a smaller risk that both endpoints try to modify the same m- line. Maybe that is what he was talking about :) That's actually all I was suggesting. But the wild speculation that ensued was quite interesting nonetheless. I believe that most of what has been said on this thread is also true. Yes, you can probably reduce glare further by defining some specific rules (reject beats any other change, etc...). Yes, you can devise rules for other stuff. Yes, it's probably not worth it for a lot of those things anyway. Yes, changing parameters that affect multiple m-lines, like transport parameters, is probably going to cause unavoidable wide-scale glare. Etc.. From christer.holmberg@ericsson.com Tue Aug 6 23:39:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F64121E80EE for ; Tue, 6 Aug 2013 23:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F32wkijT+lBo for ; Tue, 6 Aug 2013 23:39:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 62E7C21E80EF for ; Tue, 6 Aug 2013 23:39:38 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-e4-5201eba6d396 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C4.FF.19388.6ABE1025; Wed, 7 Aug 2013 08:39:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.135]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 08:39:34 +0200 From: Christer Holmberg To: Adam Roach Thread-Topic: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers Thread-Index: Ac6SwAaH+8B2wVyxQFSEGu6rKTxpcQALCkmAABMWT0A= Date: Wed, 7 Aug 2013 06:39:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C41F8D5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> <5201871B.4090903@nostrum.com> In-Reply-To: <5201871B.4090903@nostrum.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre6y14xBBqd6LC32/F3EbjF1+WMW ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvj44Y1zAV/OCo6Tz9lamBsYe9i5OSQEDCR aFj3hRXCFpO4cG89WxcjF4eQwGFGiVe/u5khnMWMEjc3/gDq4OBgE7CQ6P6nDdIgIqAo0Xb4 JjOIzSwgIzHjbCMTiC0s4CMx9dtyRpByEQFfifNTaiDKrSTapv8H28sioCLRv+8GWCsvUMnV bbPZQGwhgTyJ0zs+M4LYnALaElMm7werYQS67fupNUwQq8QlPhy8zgxxs4DEkj3noWxRiZeP /0H9oiTRuOQJK0S9nsSNqVPYIGxtiWULX0PtFZQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlW MbLnJmbmpJebb2IERsjBLb8NdjBuui92iFGag0VJnHez3plAIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYy+E6YvNtypf/3d9ymND7fVNbTNkpodGFl1SSPlxQlZzqZHE36t8vEv3VAd9Vz5 VL1myn8XM0GB1v6tTJWNM72Sz86eeND22hzbPWZOvaxCqxtvCZhfjf78m6/+UMUPf70lz32f /t2Yea5v+v4Vim+3Pl1sO2fJ5Jmc2heL7q/+qvz/hX3YU9HTSizFGYmGWsxFxYkAxivel14C AAA= Cc: mmusic Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 06:39:45 -0000 Hi, =A0 >> It has been indicated that POFs (partial offers) and PANs (partial answe= rs)=A0form a stand-alone mechanism,=A0instead of being=A0an extension of RF= C3264. >> >> Now, assuming that is true, we still need to describe the interaction be= tween POFs, PANs and 3264 Offer/Answers. >> >> Because, if I send=A0a POF, and then receive a 3264 Offer (including the= same m- line as the POF), =A0there is a glare and I need to reject the 326= 4 Offer. >> >> In the same way, if I send a 3264 Offer, and receive=A0a POF (including = the same m- line as the 3264 Offer), there is a glare and I need to reject = the POF. >> >> I ASSUME the above is clear to everyone, including the authors of the UP= , but IF someone has a different opinion I'd like to hear about it :) >=A0 > That is certainly what I had been assuming. Of course, if the POF is a ne= w m-line (that is, it doesn't appear in the offer coming the other way), th= en there is no glare condition. Correct - assuming that the addition of the new m- lines does not indirectl= y affect values etc associated with existing m- lines. Regards, Christer From keith.drage@alcatel-lucent.com Wed Aug 7 05:04:25 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F2111E812A for ; Wed, 7 Aug 2013 05:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.626 X-Spam-Level: X-Spam-Status: No, score=-110.626 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5olf9FwSqVeR for ; Wed, 7 Aug 2013 05:04:19 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECF411E8124 for ; Wed, 7 Aug 2013 05:04:19 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r77C4Eex002936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2013 07:04:15 -0500 (CDT) 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 r77C4ChL006052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 14:04:13 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 7 Aug 2013 14:04:13 +0200 From: "DRAGE, Keith (Keith)" To: Bernard Aboba , Christer Holmberg , mmusic Thread-Topic: [MMUSIC] UP: Meaning of "scope is WEBRTC" Thread-Index: Ac6R/R3kheGg3J0cRN604x+uNsUCKAA8dQUAAB20PCA= Date: Wed, 7 Aug 2013 12:04:12 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> In-Reply-To: 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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B07D89DFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 12:04:25 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B07D89DFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As one of those that used the term, my intention was that the initial decis= ion was to agree to define what RTCWEB needed. As each dependent working group looks at the extensions they need to do, th= en they need to make the decision as to whether a wider scope of possible, = desirable, or dangerous. So the BUNDLE status at the moment is that any changes for the unified plan= should work for RTCWEB usage, but not for general. It would probably make = sense to make it more generally applicable, but that is the next step in th= e decision process, and may need some other technical decisions before it h= appens. Keith ________________________________ From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: 07 August 2013 00:50 To: Christer Holmberg; mmusic Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" Christer said: "While cleaning up my MMUSIC notes today, I was listening to the audio reco= rding, in order to get a clarification regarding what "scope is WEBRTC" rea= lly means. However, unless I missed something, I didn't get a clear answer= . Does it only cover the browser API (JSEP) or does it also cover something t= hat can be sent out on the wire (as long as it is not SIP) by a browser? Feel free to tell me that it is a stupid question, and that the answer is v= ery clear :)" [BA] I actually think it is a good question :) One interpretation of "scope is WebRTC" is that the SDP in "Unified Plan"= applies to use within the JSEP API. As a result, one might expect the = SDP used in createOffer, setLocalDescription and setRemoteDescription to re= semble that in the "Unified Plan" document. Since signaling is out of sco= pe for WebRTC, applications that use the JSEP API might or might not use th= e "Unified Plan" SDP in signaling on the wire. However, "Unified Plan" includes normative references to published SDP spec= ifications that were developed for general use, and the adoption of "Unifie= d Plan" (or even an applicability statement within the "Unified Plan" docum= ent) doesn't change the applicability of those documents. Also, there may be some specifications that are part of the "Unified Plan" = workload that may have applicability beyond WebRTC (e.g. a=3Dgroup: SIMULCA= ST) Ultimately, I am expecting the work involved in "Unified Plan" to span mult= iple documents, and to clarify the applicability, those individual documen= ts will need to explain what they apply to (just WebRTC use or more general= use). --_000_949EF20990823C4C85C18D59AA11AD8B07D89DFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_949EF20990823C4C85C18D59AA11AD8B07D89DFR712WXCHMBA11zeu_-- From pkyzivat@alum.mit.edu Wed Aug 7 06:27:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153D221F997E for ; Wed, 7 Aug 2013 06:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4j9hUT3ig+r for ; Wed, 7 Aug 2013 06:27:24 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFB721E8126 for ; Wed, 7 Aug 2013 06:27:13 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id 9oTX1m0021ZXKqc56pTBuF; Wed, 07 Aug 2013 13:27:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 9pTB1m00v3ZTu2S3hpTBZc; Wed, 07 Aug 2013 13:27:11 +0000 Message-ID: <52024B2F.1030900@alum.mit.edu> Date: Wed, 07 Aug 2013 15:27:11 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41EC88@ESESSMB209.ericsson.se> <5201871B.4090903@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1C41F8D5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C41F8D5@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=q20121106; t=1375882031; bh=b2XVpVvgbdLD/K+mNVccZlqun+sdbFYsfnhwf2eVKmk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JbTZycfsLGJ43ZiQZcsVxIUfyZ3F7XoM4wHL3D+44K1IRgWpLyTtlnWi9G9PXF97Q pPiJNtVc5lvQIH9znfhIQgj6oOrFVFG4QGQ1v+yjw+VxFn+E6cySaEvFe5BptlLMqR q/gQCdbtG2yU/E7SvHhO2MNSycZ4mI1YI8PlZz4mdt3mdRRH3bkjGl6W/sWn4hq4+C f84Ih9rvACxN9Ue8E82EY06YejHK+ddK3EiYLprFsUMybolsnifcC/PqeH/I2YZh6E KVER3wkOhlMbjwlv4JpFBF4ZCjEipgpHrydeqVyDWZSylRBa93fDkoigESP5crom1X 60SXIwOaXEFyQ== Subject: Re: [MMUSIC] Interactions between POFs, PANs and 3264 Offer/Answers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:27:29 -0000 What about adding a new m-line into a bundle? IIUC this is likely to be one of the most important use cases. Can this all be done with POF and PAN? Thanks, Paul On 8/7/13 8:39 AM, Christer Holmberg wrote: > Hi, > >>> It has been indicated that POFs (partial offers) and PANs (partial answers) form a stand-alone mechanism, instead of being an extension of RFC3264. >>> >>> Now, assuming that is true, we still need to describe the interaction between POFs, PANs and 3264 Offer/Answers. >>> >>> Because, if I send a POF, and then receive a 3264 Offer (including the same m- line as the POF), there is a glare and I need to reject the 3264 Offer. >>> >>> In the same way, if I send a 3264 Offer, and receive a POF (including the same m- line as the 3264 Offer), there is a glare and I need to reject the POF. >>> >>> I ASSUME the above is clear to everyone, including the authors of the UP, but IF someone has a different opinion I'd like to hear about it :) >> >> That is certainly what I had been assuming. Of course, if the POF is a new m-line (that is, it doesn't appear in the offer coming the other way), then there is no glare condition. > > Correct - assuming that the addition of the new m- lines does not indirectly affect values etc associated with existing m- lines. > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From pkyzivat@alum.mit.edu Wed Aug 7 06:40:45 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF9321F9F20 for ; Wed, 7 Aug 2013 06:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuYToeyyPbaE for ; Wed, 7 Aug 2013 06:40:41 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 0A00721F9A64 for ; Wed, 7 Aug 2013 06:40:40 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id 9nUs1m0011ap0As55pggRt; Wed, 07 Aug 2013 13:40:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 9pgg1m00h3ZTu2S3ipggdz; Wed, 07 Aug 2013 13:40:40 +0000 Message-ID: <52024E57.9070602@alum.mit.edu> Date: Wed, 07 Aug 2013 15:40:39 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07D89D@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=q20121106; t=1375882840; bh=KMUZU6KYokmO6k8is60HNM+wXr7ia3znYVYz0/Nphig=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mlB9FDrvxwAFG9wJ4HRzSt2tJSxwW5vUOdwo3/Z4LeVO4pibLHI/qyXeeCPsORv6u KllS1ZqPS8LvtMPnX9bTRTR/0W1AN4cXcsmh0L89IA3ct54iwwhyTg8sZuPy78SnTt NHmLGVDqUM8edDDV4Fa87CGBfpP2ACd4gBY6HGJ/0r//NC8BNEEo7ktylh/SA6+Gqa d6cbFuQXwMSVAmokP6mCbZZk945sSpWrEo6p49h/nlsdLsmRFRmXYa+NGp8n5Rb+zv vTyhuhJb5y3r+PluzquE7NVYga6esV+ABpUZ+LvKhpbUSHNk+w5xqZisYmFDj+ZcYj 1v6XimALENxcw== Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:40:45 -0000 On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote: > As one of those that used the term, my intention was that the initial > decision was to agree to define what RTCWEB needed. > > As each dependent working group looks at the extensions they need to do, > then they need to make the decision as to whether a wider scope of > possible, desirable, or dangerous. > > So the BUNDLE status at the moment is that any changes for the unified > plan should work for RTCWEB usage, but not for general. It would > probably make sense to make it more generally applicable, but that is > the next step in the decision process, and may need some other technical > decisions before it happens. I don't know how you intend the above to be parsed. Specifically, when you say: "any changes for the unified plan should work for RTCWEB usage" Do you mean: 1) that the changes should be designed solely with RTCWEB usage in mind? (But are still applicable in other environments that find them useful and choose to adopt them.) Or do you mean: 2) that those changes should not be used in any environment other than RTCWEB? I might be able to accept (1), but not (2). Thanks, Paul > Keith > > ------------------------------------------------------------------------ > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Bernard Aboba > *Sent:* 07 August 2013 00:50 > *To:* Christer Holmberg; mmusic > *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" > > Christer said: > > "While cleaning up my MMUSIC notes today, I was listening to the audio > recording, in order to get a clarification regarding what "scope is > WEBRTC" really means. However, unless I missed something, I didn't get > a clear answer. > > Does it only cover the browser API (JSEP) or does it also cover > something that can be sent out on the wire (as long as it is not SIP) by > a browser? > > Feel free to tell me that it is a stupid question, and that the answer > is very clear :)" > > [BA] I actually think it is a good question :) > > One interpretation of "scope is WebRTC" is that the SDP in "Unified > Plan" applies to use within the JSEP API. As a result, one > might expect the SDP used in createOffer, setLocalDescription and > setRemoteDescription to resemble that in the "Unified Plan" document. > Since signaling is out of scope for WebRTC, applications that use the > JSEP API might or might not use the "Unified Plan" SDP in signaling on > the wire. > > However, "Unified Plan" includes normative references to published SDP > specifications that were developed for general use, and the adoption of > "Unified Plan" (or even an applicability statement within the "Unified > Plan" document) doesn't change the applicability of those documents. > > Also, there may be some specifications that are part of the "Unified > Plan" workload that may have applicability beyond WebRTC (e.g. a=group: > SIMULCAST) > > Ultimately, I am expecting the work involved in "Unified Plan" to span > multiple documents, and to clarify the applicability, those individual > documents will need to explain what they apply to (just WebRTC use or > more general use). > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From mary.ietf.barnes@gmail.com Wed Aug 7 07:56:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C1F11E8141 for ; Wed, 7 Aug 2013 07:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.509 X-Spam-Level: X-Spam-Status: No, score=-101.509 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrKYPeZTdsez for ; Wed, 7 Aug 2013 07:56:05 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB0921F9EF5 for ; Wed, 7 Aug 2013 07:56:04 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id e11so933631qcx.36 for ; Wed, 07 Aug 2013 07:56:03 -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=+QdkeHhrVtTbOqufHZDsPL30L9pvhpKdAJIgEMrs+FU=; b=XFHUikuZt/B2aI0PvBmbT/Y/axi6dpYq7o5Ppr8DLE55Uav56oI/LrlbM/kgGViIzC QAjEMoA0wheH4IkKJ5NjqVy471TRBPuPI/qbDmWb4wPgIezTasQxBPdFRHSVxxP3bda7 zXrno9YuGvzfIJaAcspwcwk1mCtvLfixpPMVI75LTIsBQ0Js08ItJLs/TrUX6DdqvyF/ 5TenSN1c0IjrqYWbDhzstpOEb9VFTQH9wviJnghsxYbUjC7LOjA7UwUYPEb6a1233HYW IGeVfvCrC9nBAUHKUhp7Oysx/2LsZBycoACNUj7uEBw0NkthCx63RPGNMfPWpZOwM4WU Y4lA== MIME-Version: 1.0 X-Received: by 10.224.12.81 with SMTP id w17mr1119794qaw.37.1375887363704; Wed, 07 Aug 2013 07:56:03 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Wed, 7 Aug 2013 07:56:03 -0700 (PDT) In-Reply-To: <52024E57.9070602@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B1C41DB40@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B07D89D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52024E57.9070602@alum.mit.edu> Date: Wed, 7 Aug 2013 09:56:03 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e013cb7cc9098cb04e35cbd71 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:56:06 -0000 --089e013cb7cc9098cb04e35cbd71 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat wrote: > On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote: > >> As one of those that used the term, my intention was that the initial >> decision was to agree to define what RTCWEB needed. >> >> As each dependent working group looks at the extensions they need to do, >> then they need to make the decision as to whether a wider scope of >> possible, desirable, or dangerous. >> >> So the BUNDLE status at the moment is that any changes for the unified >> plan should work for RTCWEB usage, but not for general. It would >> probably make sense to make it more generally applicable, but that is >> the next step in the decision process, and may need some other technical >> decisions before it happens. >> > > I don't know how you intend the above to be parsed. Specifically, when you > say: > > "any changes for the unified plan should work for RTCWEB usage" > > Do you mean: > > 1) that the changes should be designed solely with RTCWEB usage in mind? > (But are still applicable in other environments that find them useful and > choose to adopt them.) > > Or do you mean: > > 2) that those changes should not be used in any environment other than > RTCWEB? > > I might be able to accept (1), but not (2). > [MB] I would agree with your (1), however, not with the parenthetical part. I would suggest that be "But MAY still be applicable in other environments... " My concern is that at this point in time, you can't say that the changes ARE applicable to other environments .... [/MB] > > Thanks, > Paul > > > Keith >> >> ------------------------------**------------------------------** >> ------------ >> >> *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.**org] >> *On >> Behalf Of *Bernard Aboba >> *Sent:* 07 August 2013 00:50 >> *To:* Christer Holmberg; mmusic >> *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC" >> >> >> Christer said: >> >> "While cleaning up my MMUSIC notes today, I was listening to the audio >> recording, in order to get a clarification regarding what "scope is >> WEBRTC" really means. However, unless I missed something, I didn't get >> a clear answer. >> >> Does it only cover the browser API (JSEP) or does it also cover >> something that can be sent out on the wire (as long as it is not SIP) by >> a browser? >> >> Feel free to tell me that it is a stupid question, and that the answer >> is very clear :)" >> >> [BA] I actually think it is a good question :) >> >> One interpretation of "scope is WebRTC" is that the SDP in "Unified >> Plan" applies to use within the JSEP API. As a result, one >> might expect the SDP used in createOffer, setLocalDescription and >> setRemoteDescription to resemble that in the "Unified Plan" document. >> Since signaling is out of scope for WebRTC, applications that use the >> JSEP API might or might not use the "Unified Plan" SDP in signaling on >> the wire. >> >> However, "Unified Plan" includes normative references to published SDP >> specifications that were developed for general use, and the adoption of >> "Unified Plan" (or even an applicability statement within the "Unified >> Plan" document) doesn't change the applicability of those documents. >> >> Also, there may be some specifications that are part of the "Unified >> Plan" workload that may have applicability beyond WebRTC (e.g. a=group: >> SIMULCAST) >> >> Ultimately, I am expecting the work involved in "Unified Plan" to span >> multiple documents, and to clarify the applicability, those individual >> documents will need to explain what they apply to (just WebRTC use or >> more general use). >> >> >> >> ______________________________**_________________ >> 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 > --089e013cb7cc9098cb04e35cbd71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 7, 2013 at 8:40 AM,= Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 8/7/13 2:04 PM, DRAGE, = Keith (Keith) wrote:
As one of those that used the term, my intention was that the initial
decision was to agree to define what RTCWEB needed.

As each dependent working group looks at the extensions they need to do, then they need to make the decision as to whether a wider scope of
possible, desirable, or dangerous.

So the BUNDLE status at the moment is that any changes for the unified
plan should work for RTCWEB usage, but not for general. It would
probably make sense to make it more generally applicable, but that is
the next step in the decision process, and may need some other technical decisions before it happens.

I don't know how you intend the above to be parsed. Specifically, when = you say:

=A0 "any changes for the unified plan should work for RTCWEB usage&quo= t;

Do you mean:

1) that the changes should be designed solely with RTCWEB usage in mind? (B= ut are still applicable in other environments that find them useful and cho= ose to adopt them.)

Or do you mean:

2) that those changes should not be used in any environment other than RTCW= EB?

I might be able to accept (1), but not (2).
[MB] I wou= ld agree with your (1), however, not with the parenthetical part. =A0I woul= d suggest that be "But MAY still be applicable in other environments..= . " =A0 My concern is that at this point in time, you can't say th= at the changes ARE applicable to other environments .... =A0[/MB]
=A0

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


Keith

-------------------------------------------------------------= -----------

*From:*mmusic-= bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On
Behalf Of *Bernard Aboba
*Sent:* 07 August 2013 00:50
*To:* Christer Holmberg; mmusic
*Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"


Christer said:

"While cleaning up my MMUSIC notes today, I was listening to the audio=
recording, in order to get a clarification regarding what "scope is WEBRTC" really means. =A0However, unless I missed something, I didn= 9;t get
a clear answer.

Does it only cover the browser API (JSEP) or does it also cover
something that can be sent out on the wire (as long as it is not SIP) by a browser?

Feel free to tell me that it is a stupid question, and that the answer
is very clear :)"

[BA] =A0I actually think it is a good question :)

One interpretation of "scope is WebRTC" =A0is that the =A0SDP in = "Unified
Plan" applies to use within =A0the JSEP API. =A0 =A0As a result, one might expect the SDP used in createOffer, setLocalDescription and
setRemoteDescription to resemble that in the "Unified Plan" docum= ent.
Since signaling is out of scope for WebRTC, applications that use the
JSEP API might or might not use the "Unified Plan" SDP in signali= ng on
the wire.

However, "Unified Plan" includes normative references to publishe= d SDP
specifications that were developed for general use, and the adoption of
"Unified Plan" (or even an applicability statement within the &qu= ot;Unified
Plan" document) doesn't change the applicability of those document= s.

Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=3Dgro= up:
SIMULCAST)

Ultimately, I am expecting the work involved in "Unified Plan" to= span
multiple documents, and to clarify the applicability, =A0those individual documents will need to explain what they apply to (just WebRTC use or
more general use).



_______________________________________________
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

As one of those that used the term, my= intention was that the initial decision was to agree to define what RTCWEB= needed.

 

As each dependent working group looks = at the extensions they need to do, then they need to make the decision as t= o whether a wider scope of possible, desirable, or dangerous.

 

So the BUNDLE status at the moment is = that any changes for the unified plan should work for RTCWEB usage, but not= for general. It would probably make sense to make it more generally applicable, but that is the = next step in the decision process, and may need some other technical decisi= ons before it happens.

 

Keith

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Be= half Of Bernard Aboba
Sent: 07 August 2013 00:50 To: Christer Holmberg; mmusi= c
Subject: Re: [MMUSIC] UP: Me= aning of "scope is WEBRTC"

 

Christer said:
 

"While cleaning up my MMUSIC notes today, I was l= istening to the audio recording, in order to get a clarification regarding = what "scope is WEBRTC" really means.  However, unless I missed something, I didn't get a clear answ= er.

 

Does it only cover the browser API (JSEP) or does it a= lso cover something that can be sent out on the wire (as long as it is not = SIP) by a browser?

 

Feel free to tell me that it is a stupid question, and= that the answer is very clear :)"

 

[BA]  I actually think it is a good question :)

 

One interpretation of "scope is WebRTC"=   is that the  SDP in "Unified Plan" applies = to use within  the JSEP API.    As a = result, one might expect the SDP used in createOffer, setLocalDescript= ion and setRemoteDescription to resemble that in the "Unified Plan&quo= t; document.   Since signaling is out of scope for WebRTC, applic= ations that use the JSEP API might= or might not use the "Unified Plan" SDP in signaling on the= wire. 

 

However, "Unified Plan" includes normat= ive references to published SDP specifications that were develope= d for general use, and the adoption of "Unified Plan" (or even an applicability statement within the "Unified Pla= n" document) doesn't change the applicability of those documents.

 

Also, there may be some specifications that are part o= f the "Unified Plan" workload that may have applicability beyond = WebRTC (e.g. a=3Dgroup: SIMULCAST)

 

Ultimately, I am expecting the work involved in "= Unified Plan" to span multiple documents, and to clarify the applicabi= lity,  those individual documents will need to explain what they apply to (just WebRTC use or more general u= se).